What is a schema migration?
How a database changes shape without losing anyone's data, and why every change should be a file, not a click.
In short
A schema migration is a versioned script that changes the structure of a database, such as adding a table, a column or an index, kept in the code repository and applied in order to every environment. Because each change is a file, the database can be rebuilt, reviewed and rolled forward the same way on staging and in production.
Also called: Database migration, Migration script
Why it matters when your prototype goes to production
In a prototype, the database changes whenever a prompt needs it to, often directly on the live project. That works while there is no data worth keeping. Once there is, a change made by hand on production cannot be tested first, cannot be repeated on staging, and cannot be reviewed by anyone.
Migrations fix all three. Every change is written as SQL, committed next to the code that needs it, run on staging by the same pipeline that will run it in production, and recorded in the database so it is never applied twice.
What a safe migration looks like
- Additive first: add the new column, backfill it, switch the code, remove the old one later.
- Tested on a copy with realistic data before it touches production.
- Backed by a recent backup, with a known way back.
- Row-level security policies written in the same migration as the table they protect.
At scale it looks like Looph: 253 migrations, 110 pgTAP suites testing the access rules inside a real database, and a release rule of staging first, with migrations never riding along with a deploy.
Common questions
Is a schema migration the same as a data migration?
No. A schema migration changes structure; a data migration moves or transforms the rows. Real changes often need both, in that order.
Related terms
Read next
Sources
More on this: Production architecture & security · All glossary terms
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.