The Gravity of Data
Think of your application code like a whiteboard. If you write something wrong, you erase it and write the correct version. The whiteboard doesn't care — it has no memory of what was there before. Databases are the opposite: they're more like a legal ledger. Every entry matters, and you can't just tear out a page without consequences.
In the world of CI/CD, application code is stateless and disposable. If you deploy a buggy version of your web server, you kill the container and start the old one. It takes seconds and nothing is lost. Databases are fundamentally different because they carry state — your customer records, transaction history, user accounts. This state is the actual product. Losing it, even partially, is a business catastrophe.
This creates a set of constraints that don't exist anywhere else in software delivery:
- You cannot delete and recreate. Dropping a database to "start fresh" means losing all customer data.
- You cannot simply revert. If you run
DROP COLUMN address, that data is gone. Git can revert the migration file, but it cannot restore the deleted rows. Getting the data back requires restoring from a backup — a process that can take hours and causes downtime. - Schema and data are coupled. A schema change (adding a column, changing a type) must be compatible with both the old application code (still running during a rolling deploy) and the new application code. This is the dual-write problem that trips up many teams.
Database CI/CD is the discipline of automating schema changes in a way that is safe, version-controlled, auditable, and testable — treating your database schema with the same rigor you apply to application code.