Why is a GraphQL schema usually designed from client demand rather than from database tables?

## Two ways to arrive at a schema There are only two honest starting points for a GraphQL schema. You can start at the bottom — take the tables, views or documents you already store, and derive a type per table and a field per column. Or you can start at the top — take the surfaces that will consume the graph, write down the operations each one needs to send, and design the smallest set of types that answers all of them. The first is cheap on the day and expensive forever after; the second costs a design conversation up front and buys a contract that survives the storage underneath it. Nothing in the GraphQL specification prefers either. The specification defines a type system, a document syntax, validation rules and an execution algorithm. It has no opinion about where a type comes from, and it never mentions databases. So when an interviewer asks this question, they are not testing spec recall — they are testing whether you understand what a schema *is*: a published contract, and therefore a design artefact with a long life, not a projection of an implementation detail. ## What demand-oriented actually means Take a job-board graph. A candidate's saved-search results view needs, per result: the job title, the employer's display name and logo, a salary range presented as a range rather than two integers, the posting's status, and whether this candidate has already applied. That is one screen's demand, and it describes one type: A `JobPosting` with an `employer` field, a `salaryRange` field, a `status` field, and a `viewerApplication` field that is null when the viewer has not applied. Four of those five come from different places underneath — the employer from a directory service, the salary from two integer columns and a currency, the status from a state machine, the application from a table keyed by candidate and posting. The client never learns that, and does not need to. Now run the second surface through it. The employer's applicant-review view needs a job posting too, but with an applicant count and a hiring stage breakdown. Demand-oriented does not mean a new type; it means adding the two fields the second surface needs to the same concept. The test that you got it right is that the second consumer could be served by *selecting differently* from types that already exist, rather than by adding a new entry point. ## What a mirrored schema costs A schema derived from tables looks superficially similar and behaves very differently. **It exports foreign keys instead of relationships.** Clients receive `employerId` and must issue a second operation to turn it into an employer, which is precisely the round-tripping GraphQL exists to avoid. **It exports storage vocabulary.** `statusCode: Int`, `stageId: Int`, `isDeleted: Boolean`, `createdAt` on every type — enumerations that live in a lookup table arrive as integers, and every client hardcodes the same mapping from `3` to "closed". The knowledge that should have been in the schema, as an enum, ends up copied into every consumer. **It exports decisions that were never meant to be public.** Normalisation, soft-delete flags, audit columns, sharding keys and the compromises of a five-year-old migration all become fields somebody might select. Once selected, they are load-bearing. **It turns storage work into contract work.** This is the expensive one. A column rename, a split into a lookup table, a type widening for a backfill — each regenerates a different schema, and a different schema is a client-visible event. The team that owns the database discovers that they can no longer refactor it without a compatibility conversation, which is exactly backwards: the whole point of an API layer is that it absorbs that churn. **It leaves nowhere for the mapping to live.** In a demand-oriented design there are two shapes — the contract and the storage — and a translation between them that you own and can change. In a mirrored design there is one shape playing both roles, so there is no translation to change, and the only way to absorb a storage change is to break someone. ## The honest caveats Demand-oriented does not mean "whatever the current design mock says" — a schema shaped screen-by-screen has its own failure mode, where every new page adds a root field and a redesign becomes a schema migration. Demand is *evidence* of what concepts the domain has; it is not a specification of them. The craft is reading several surfaces' demands together and extracting the concept they share. It also does not mean generated schemas are never appropriate. A short-lived internal admin surface with one known consumer may be perfectly well served by generation, because the coupling it creates never has time to hurt. The judgement is about lifetime, consumer count and who pays the cost later — and a junior is expected to know the default, which is: design the contract, then map it to storage.