Schema evolution compatibility rule | DevPrompt Lab

A rollout rule for making database evolution observable and compatible across application versions.

Reusable content

For live schema changes, prefer an expand-and-contract rollout. Add compatible structures first, deploy code that tolerates old and new shapes, backfill with deterministic and resumable batches, reconcile counts and constraints, switch reads and writes, then remove legacy structures only in a separately approved phase. Measure locks and long-running work. Keep a verified restore path and document which rollback stages remain possible after writes switch.

Database: {{DATABASE}}

Deployment style: {{DEPLOYMENT_STYLE}}

Legacy clients or workers: {{LEGACY_CLIENTS}}

How to use it

This staged pattern may be unnecessary for a fresh empty database; confirm the live deployment context.

Example

Do not rename a live column in one deploy while old workers still query it; introduce the new column and dual compatibility first.