Every database starts as an idea. By the time it’s running in production, that idea has passed through three distinct stages, each one adding detail the last one didn’t have. Skipping straight to the last stage is how projects end up with schemas that technically work but don’t actually reflect how the business thinks. Understanding all three and treating them as separate steps makes the whole process a lot less painful.

---

It’s tempting to jump straight from an idea to a physical schema, especially when you already know the database engine you’re using. But collapsing all three stages into one skips the conversations that catch problems early. A conceptual model gets business stakeholders and engineers agreeing on vocabulary before a single table exists. A logical model catches structural issues, missing links, and ambiguous relationships before they’re expensive to fix. Only then does the physical model lock in the specifics that are hardest to change later: column names, data types, indexes, storage.

Idea, plan, build. Three levels of the same story, each one earning the next.

Conceptual Model: the big picture

The conceptual model is where you talk about ideas, not tables or code. At this stage, you’re identifying the main “things” a business cares about and how they connect, nothing more. For a simple order system, that means naming the core entities: Customer, Order, and OrderLine, and drawing lines between them to show they relate.

There’s no structure yet, no columns, no data types. Just an agreement on what matters and what to call it.

This stage focuses on:

• What the business cares about
• People, things, and key ideas
• Clear, shared meanings across both business and technical people

The questions it answers are foundational ones: What is our business about? What main things do we track? How do these things connect? What words should we all use?

Logical Model: the detailed plan

Once everyone agrees on the big picture, the logical model adds detail while still not tying anything to a specific database technology. This is where you start grouping data into tables and deciding what each one stores.

Continuing the order example, CUSTOMER gets fields like Customer ID, Name, and Email. ORDER gets Customer ID, Order Date, and Order ID, establishing its link back to the customer. ORDER_LINE gets Order Line ID, Order ID, and Amount, linking each line item back to its order.

This is the “start with the story, add detail, then build” stage. It’s meant to be clear enough for both business and technical people to follow, since it’s still just a plan, not an implementation.

This stage focuses on:

• How to group data into tables
• What details each table stores
• How tables link to each other

The questions it answers get more specific: What tables do we need? What details do we store in each table? How do we link customers, orders, and order lines? What data is optional or required?

Physical Model: how it’s actually built

The physical model is where the plan becomes real. This is the stage where the logical design gets translated into an actual working system: exact column names, data types, and storage settings in a real database engine.

customer becomes a real table with customer_id as a number, email as text, created_at as a date and time. order and order_line become real tables connected by foreign keys, sitting inside an actual database, with decisions made about how and where the data is stored, whether on disk or in the cloud.

This stage focuses on:

• Exact table and column names
• Data types (number, text, date, and so on)
• How data is stored, secured, and kept fast

The questions it answers are implementation questions: How is this built in a real database? Where exactly is each piece of data stored? What is the name and type of each column? How do we keep it fast, safe, and reliable?