Version control for database schema
Day 127 of 149
👉 Full deep-dive with code examples
The Recipe Card Analogy
Your grandma's recipe evolves:
- Version 1: Original recipe
- Version 2: Add a pinch of salt
- Version 3: Use brown sugar instead of white
- Each change is recorded and reversible
Database migrations track changes to your database structure!
Why Migrations Matter
Without migrations:
- "Did we add that column?"
- "What does the database look like in production?"
- "How do I set up a new developer's database?"
Everyone's database might be different!
How They Work
Each migration is a file:
Migration 1: Create users table
Migration 2: Add email column to users
Migration 3: Create orders table
Migration 4: Add index on email
Run in order, your database evolves consistently.
Key Features
Forward (up):
- Apply changes: add column, create table
Backward (down):
- Undo changes: remove column, drop table
Version tracking:
- Database knows which migrations have run
- Only applies new ones
Benefits
- Consistent → All databases match
- Repeatable → New developer runs migrations, instant setup
- Reversible → Mistake? Roll back
- Auditable → History of all changes
The Workflow
- Write migration (add column, change type)
- Test locally
- Commit to version control
- Deploy runs migrations automatically
- Production updated safely!
In One Sentence
Database Migrations are versioned scripts that track and apply changes to your database structure, so every environment stays in sync.
🔗 Enjoying these? Follow for daily ELI5 explanations!
Making complex tech concepts simple, one day at a time.
Top comments (0)