The most common mistake when starting a feature or a service: having heard the task, the engineer immediately opens an editor and draws tables. It feels like modeling. In reality a whole stage has been skipped — and the skip is paid for later with schema rework, awkward APIs, and arguments about "what did we actually mean." Let's unpack what a conceptual model is and why it is not the same thing as a DB structure.

Two different questions

A conceptual model answers: which concepts exist in the task and how are they related? Order, line item, customer, payment; an order consists of line items; a payment belongs to exactly one order; a cancelled order cannot be paid. Not a word here about tables, indexes, or JSON.

A DB schema answers a different question: how do we store these concepts? In which tables, with which keys, what to denormalize for speed, what to put into JSONB, what to move to another service.

These are two different decisions, and mixing them means making both at once and both blindly. The same conceptual model maps onto dozens of schemas: relational normalized, read-optimized denormalized, document, event-based. The schema choice is an engineering trade-off for load and queries; the concept choice is an agreement about meaning. When you jump straight to tables, the agreement about meaning is made silently and accidentally — as a side effect of the storage structure.

An object is not a table

An untraining exercise: stop assuming a concept maps to a table.

  • One concept — several tables. An "order" may live in orders, order_lines, order_status_history — three tables, one concept.
  • One table — several concepts. A users table often blends an "account" (login, password, roles) with a "person" (name, contacts) — two concepts with different lifecycles glued together by storage. This is exactly where pains like "deleted a user — lost the author of orders" come from.
  • A concept without a table. An "overdue payment" is a full-fledged concept with rules, but in the DB it's just a WHERE condition, not a table.

If the concept model isn't written down separately, the DB schema becomes the concept model — with all its trade-offs. A year later nobody remembers that gluing "account" and "person" was an accident — and new features are built on top of it as if it were a deliberate decision.

What breaks without a conceptual model

  • The API mirrors the tables. user_ids and joins stick out instead of domain concepts — API clients are forced to know your storage layout.
  • Schema changes hurt more. Schemas get changed for load regularly; if the schema is also your only model of meaning, every migration turns into a renegotiation of concepts.
  • The team argues "about tables" while actually arguing about concepts. "Do we need a separate table for X" often masks the unresolved question "is X a separate concept at all, or an attribute of Y?"
  • The agent builds from the schema. Give an AI agent only the DDL — and it will honestly take the storage structure for the domain model, glue and accidents included (it won't ask).

How to model before tables

You don't need a heavy tool — you need an hour of honest work:

  1. Write out the concepts as nouns from the business language: order, line item, customer, payment, refund.
  2. Relate them: "consists of," "belongs to," "refers to" — with arrows and cardinalities (an order has one customer; a customer has many orders).
  3. Record rules and states: which statuses an order can have, which transitions are allowed, what is forbidden ("you can't pay a cancelled one").
  4. Check with the business: show the model to whoever owns the task — at this level (unlike DDL) they can actually spot a mistake.

The result is a page of text or a simple diagram. It will later become the shared vocabulary and the foundation of the spec for the agent; the DB schema is then designed consciously from it, for queries and load.

In short

  • A conceptual model = which concepts and how they relate; a DB schema = how to store them. Two different decisions — don't make them in one jump.
  • One model maps to dozens of schemas; an object ≠ a table: a concept can live in three tables, and one table can glue two concepts together.
  • Without a written model, the DB schema silently becomes the model of meaning — and its accidental trade-offs freeze into "by design."
  • An hour of work: concepts → relations with cardinalities → states and rules → check with the business. Then tables.
  • For an AI agent this is doubly critical: give it only DDL and you'll get code built on storage trade-offs.

Next — the ubiquitous language: how to turn the concept model into a vocabulary used identically by the business, the team, and the agent.