A release that changes both application behavior and stored data needs more than a green build. The application and database can move at different speeds, and an older process may continue serving requests during deployment. Before choosing a migration command, establish which versions can read and write each data shape. This guide offers an original review workflow, not a report of a client delivery or a promise of uninterrupted deployment.
Start with a compatibility table
List the application versions that may run at the same time, the schema states they can encounter and the read/write behavior each combination requires. Include background jobs, reporting consumers and administrative tools where they touch the same data. A consumer outside the main repository can make an apparently isolated change a coordinated release.
Use the table to identify the first incompatible combination. Name the owner who can confirm that an old consumer has stopped before a contract is removed. A successful deployment of the new application does not, by itself, establish that every old worker has gone away.
Separate introducing a shape from depending on it
For a hypothetical field replacement, a team could first introduce the new representation while retaining the old one, deploy compatible application behavior, move existing data in controlled work and only later remove the old contract. Whether this sequence is appropriate depends on the database, write paths and consistency requirements. Dual writes add their own failure modes and need explicit reconciliation; they are not a universal safe default.
Agree how progress will be observed and what should stop the transition. Define how to handle a partially completed data operation before starting it. Keep the example in a representative non-production environment until the relevant assumptions have been exercised.
Review the database operation itself
Application compatibility and database execution are separate checks. The PostgreSQL ALTER TABLE documentation describes operation-specific locking and validation behavior. Consult the documentation for the actual deployed database version and inspect the planned operation rather than treating all schema changes as equivalent. Measure a representative rehearsal; this guide does not prescribe a production command or assert that a migration is lock-free.