A schema is the structure you define before putting data in. Think of it as the column headers in a spreadsheet — you decide what goes in each column before entering any rows.
Note: The word "schema" also shows up in validation — a validation schema defines what valid user input looks like (e.g. "email must be a real address"). A database schema defines the structure of your tables. Same word, different job.
Without a schema, anyone could save anything — a form without a title, a submission without any data. The schema acts as a contract: the database rejects data that doesn't fit.
| With a schema | Without a schema |
|---|---|
| Every form has a title | Title might be missing |
| Age is always a number | Text could sneak in |
| The database enforces the rules | Your code has to check everything |
Schemas aren't permanent. If you need to add a column, rename one, or create a whole new table, you write a migration — a small change to your database structure. It's like adding a new column header to a spreadsheet that already has data in it. The existing rows stay, and new rows follow the updated rules.
That's what Atlas does in your project. It reads the schema you defined in code, compares it to the current database, and generates a migration that applies only what changed. You don't write migrations by hand — Atlas figures out the difference for you.