Database Schema

Origin & evolution

The schema is rooted in Edgar Codd's relational model, set out in A Relational Model of Data for Large Shared Data Banks (1970), and formalised through the SQL standard, where the schema is the named container for tables and their constraints. From the start the discipline separated the logical from the physical: what the data means against how it is laid out, indexed, and typed on disk.

For years the schema was treated as something designed up front and frozen, which made it the part of a system most resistant to change. Pramod Sadalage and Martin Fowler challenged that. Sadalage developed evolutionary database design at ThoughtWorks around 2000, and the approach is documented in Fowler's Evolutionary Database Design and in Scott Ambler and Sadalage's Refactoring Databases (Addison-Wesley, 2006). The core move was to break every schema change into a small, version-controlled migration that runs in sequence, so a schema can evolve in step with the code that depends on it.

Microservices pushed the boundary further. Chris Richardson's Database per Service pattern argues that each service should own its data privately, and notes that this is often a logical separation: a shared server where each service holds its own schema, with credentials scoped to it. The schema became a unit of ownership and a boundary between services, not just a storage layout.

How it works in practice

A payments service stores transactions in a payments schema: a transactions table with a UUID primary key, a Money-style pair of amount and currency columns, a status enum constrained to a fixed set, a foreign key to accounts, and an index on (account_id, created_at) for statement queries. The constraints are doing real work, the enum refuses an unknown status at write time, the foreign key refuses an orphan.

A new feature⭐FeatureProduct SpecificationA product capability or featureView reference → needs🫀NeedUserA user need, pain, desire, or constraintView reference → partial refunds, which the original schema cannot express. The team writes a migration: add a refunded_amount column defaulting to zero, backfill existing rows, add a check that the refunded amount never exceeds the original. The migration is one numbered, reversible step committed alongside the code, applied to staging, then to production while traffic continues. The schema evolved without a rewrite, and the change is recorded in the same version history as the application.

Database schema vs. its neighbours

• Data model: a data model is the logical description of entities and their relationships, independent of any engine; a schema is its physical realisation in a specific database, with concrete types, indexes, and storage choices. One data model can be expressed as several schemas.
• Service: a service is a deployable unit of behaviour; a schema is where its state persists. Under database-per-service, a service owns its schema privately, and other services reach that data only through the service's interface.
• Bounded context🔲Bounded ContextEngineeringA DDD bounded context defining a service boundaryView reference →: a context is a model boundary in the domain; a schema is one way that boundary is enforced in storage. Aligning a schema to a context keeps a model's vocabulary from bleeding into another's tables.

In the graph

In the Unified Product Graph, a database schema is an engineering-region entity for the physical structure of stored data. A data_model_persisted_in_database_schemaData Modelpersisted inDatabase Schemacross-domain edge connects the logical model to its concrete realisation, and service_persisted_in_database_schemaServicepersisted inDatabase Schemahierarchy records which service owns the schema, which is how database-per-service ownership becomes explicit. Modelling the schema as its own node keeps the logical-and-physical split queryable: a reader can trace a domain concept from its data model down to the tables that store it, and see which service is allowed to touch them.