Shipping CRUD to production means changing schemas on a live database without downtime or data loss.
1npx prisma migrate dev --name add_due_date # create + apply locally
2npx prisma migrate deploy # apply in production (CI/CD)Each migration is a checked-in SQL file. Your database schema becomes reproducible and reviewable, just like code.
Never make a breaking change in one step. Split it:
1. EXPAND — add the new column (nullable), deploy. Old code still works.
2. MIGRATE — backfill data; deploy code that writes BOTH old and new.
3. CONTRACT — switch reads to the new column; later drop the old one.
Renaming a column directly will break the running old version mid-deploy. Expand/contract keeps old and new code compatible at every moment.
| Change | Risk | Safer approach |
|---|---|---|
| Drop a column | Old code breaks | Stop using it first, drop later |
| Add NOT NULL | Fails if nulls exist | Add nullable → backfill → set NOT NULL |
| Add an index on a huge table | Locks writes | CREATE INDEX CONCURRENTLY |
| Rename | Breaks in-flight code | Add new, copy, remove old |
A migration that goes wrong on production data is a very bad day. Take a backup (or a snapshot) immediately before migrate deploy, and rehearse the migration on a copy first.
You can now model data, write SQL, design a REST API, build production CRUD endpoints with validation, authorization, pagination and search, wire up an optimistic frontend, and ship it all safely with transactions, tests, and migrations. That's the full stack of CRUD — the foundation under almost every application you'll ever build.