How it works
See the Migration Apply SOP for the full workflow. In brief:
drizzle/schema.ts— source of truthdrizzle/NNNN_description.sql— forwardALTER TABLEmigrationdrizzle/0070_drizzle_baseline_schema_recovery.sql— full baseline (drift guard)drizzle/meta/_journal.json— ordered application log
Pending migrations (demo booking feature)
These migrations must be applied before the demo booking pipeline goes live:
| Migration | What it adds |
|---|---|
0162 |
demo_bookings table |
0163 |
follow_up_sent_at |
0164 |
meeting_url, recording_url, disposition, notes |
0165 |
end_time, duration_minutes |
0166 |
RSVP + lifecycle columns (confirmation_status, attended_at, etc.) |
Apply with:
DATABASE_URL="..." pnpm db:migrate:dry # preview
DATABASE_URL="..." pnpm db:migrate # apply
See the Migration Apply SOP for verification and rollback.
Drift guards
- CI
migrate-canaryapplies every migration to a freshmysql:8.4and asserts the count matches the SQL files — blocks merge on journal drift. - Runtime
server/schemaDriftGuard.tslogs any live schema vs.schema.tsmismatch at startup (non-fatal).
Journal
drizzle/meta/_journal.json is the authoritative list of what's been applied. The migration runner checks this before applying each file — it's idempotent and safe to re-run.