A schema is the structural blueprint of a database — table names, column names and types, and the constraints between them — without any of the actual data.
Why This Matters
- Schema vs. Instance (next chapter) is one of the cleanest ways to separate "the design" from "the data".
- This distinction comes up constantly once you start doing migrations, versioning, and reasoning about what actually needs to change when a requirement changes.
Core Concept
- A Schema is the definition of a database's structure — what tables exist, what columns each has, what types those columns are, and how tables relate to each other.
- A schema describes the shape data must take, not any particular data itself — an empty, freshly-created database with zero rows still has a complete schema.
Deep Dive
- Changing a schema (adding a table, adding a column, changing a type) is a deliberate, relatively rare operation — you'll meet the formal tools for this (DDL, and later, migrations) in dedicated sections of this course.
- A schema is what a database designer draws on a whiteboard before any real data exists — everything after that whiteboard is instance, not schema.
Common Mistakes
Treating a schema change and a data change as the same kind of operation.
Why: Schema changes affect every row in a table (present and future) and often require careful migration planning; data changes affect only the specific rows touched.
Fix: Always ask which one you're actually doing — "am I changing what the table can hold, or just what it currently does hold" — before touching a production database.
Interview Questions
What is a database schema?
The structural definition of a database — its tables, their columns and types, and the relationships between them — independent of any actual data stored in it.
Chapter Summary
A schema is a database's structural blueprint — tables, columns, types, relationships — with no data attached. It's the design; the next chapter covers what fills it.