Schema
SKEE-muh
The structure and organization of a database, defining tables, columns, types, and relationships.
A schema defines the structure of a database: what tables exist, what columns each table has, what types each column accepts, and how tables relate to each other. It is the blueprint of the data model.
A well-designed schema makes the application easier to build, query, and maintain. A poorly designed schema creates performance problems, data inconsistencies, and endless workarounds. Schema design is one of the highest-leverage activities in software engineering.
Schema changes in production are risky because the database is live and contains real data. Adding a column is easy. Removing a column requires confirming nothing depends on it. Changing a column's type requires migrating existing data. This is why schema design deserves careful thought upfront.
Examples
A developer designs a schema for an e-commerce app.
The schema has tables for users, products, orders, and order_items. The orders table has a user_id foreign key linking to users. The order_items table has order_id and product_id foreign keys. These relationships enforce data integrity: you cannot create an order for a user that does not exist.
A schema change breaks the application.
A developer renames a column from userName to user_name without updating the application code. Every query referencing userName fails. The fix is to either update all code references or use a database alias. In production, this causes a 15-minute outage.
A schema review catches a design problem.
A developer stores order addresses as part of the orders table. A reviewer points out that if a user updates their address, historical orders will show the new address instead of the address at time of purchase. The fix: a separate addresses table with snapshots per order.
In practice
Read more on the blog
Frequently asked questions
What is schema-on-read vs. schema-on-write?
Schema-on-write (SQL databases) enforces structure when data is written. If a column expects an integer and you send a string, the write fails. Schema-on-read (many NoSQL databases) accepts any data and enforces structure when reading. Schema-on-write catches errors early. Schema-on-read offers flexibility.
How do you change a schema in production?
Through migrations: scripted, versioned changes that alter the database structure. Add columns (safe), rename columns (risky, requires code changes), delete columns (risky, requires confirming nothing uses them). Always back up before schema changes and test migrations on staging first.
Related terms
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.