CI/CD - Safe DB Changes/Migrations

Safe DB Migrations means updating your database schema without breaking the running application and without downtime.

In real systems (AWS, Docker, microservices, CI/CD), DB changes are riskier than code changes because data is permanent and shared by multiple services.

Why This Matters in CI/CD & Microservices

• Multiple services share DB
• Rolling deployments mean old + new versions run together
• Containers auto-scale
• Instant rollback must be possible

Unsafe DB change = system outage.

“Safe DB migrations involve backward-compatible schema updates, using the expand-migrate-contract pattern, enabling changes through feature flags, and executing migrations before application rollout to avoid downtime and ensure old and new versions can run simultaneously.”

DB Migration(Keep old schema + new schema both, this will keep old and newly deployed app both working)→ Deploy new App -> Test new app → Enable Feature flag to take new app in effect to users-> delete old schema

1. Backward-Compatible Schema Changes

Goal: Old app version + New app version should both work during deployment.

Bad Example 

DROP COLUMN FirstName;

Old app still expects FirstName → crash.

Good Example 

ALTER TABLE Users ADD COLUMN FullName;

Old app still works, new app starts using new column.

Rule:
Never delete or rename columns immediately.

---

2. Feature Flags

A feature flag lets you deploy DB + code but activate behavior later.

Example flow:

• Add new column FullName
• Deploy code that can use it
• Keep feature OFF
• Turn feature ON after validation

This reduces risk and allows instant rollback without DB rollback.

---

3. Expand → Migrate → Contract Pattern

This is the gold standard for safe DB migrations.

Phase 1 — Expand

Add new schema without removing old.

ALTER TABLE Users ADD COLUMN FullName;

Both old and new apps still work.

---

Phase 2 — Migrate

Move data gradually.

UPDATE Users SET FullName = FirstName + ' ' + LastName;

Background job, no downtime.

---

Phase 3 — Contract

After all services use new column:

DROP COLUMN FirstName;
DROP COLUMN LastName;

Now safe because nothing depends on them.

---

4. Run Migrations Before App Rollout

Correct order:

DB Migration → Deploy App → Enable Feature

Wrong order:

Deploy App → Migration Later → Crash Risk

If app expects a column that doesn’t exist yet → production failure.

---

Ideal Safe Migration Checklist

Practice	Why
Backward compatible schema	Prevent crashes
Expand-Migrate-Contract	Zero downtime
Feature flags	Safe activation
Pre-deployment migrations	Avoid missing schema
Data backfill jobs	Non-blocking
Rollback plan	Disaster recovery