Database migration safety
Remove the old column in a later release
Keeping an unused field briefly can preserve rollback. Drop it only after readers, writers and recovery tools have stopped depending on it.
In this article
Make the first release compatible
Add the new representation and deploy code that can operate during the transition. Specify how values stay consistent while both forms exist.
If new code writes only the new column while old code still reads the old one, the overlap is not safe. Either maintain the required compatibility or prevent that deployment combination through an explicit release boundary.
Backfill historical rows with a resumable process and verify the conversion. Keep exceptions visible rather than assigning placeholder values merely to make the new column complete.
Switch reads with comparison evidence
Where practical, compare the old and new read results without changing user-visible behaviour first. Investigate differences that the migration did not intend.
Then switch a controlled scope to the new representation. Observe normal workflows, scheduled jobs and support tools. A healthy main page does not prove that every reader moved.
Keep a clear rollback action for this phase. The previous code must still understand data written by the new version, or rollback requires more than changing an application image.
Establish that the dependency is gone
Search code and query telemetry for the old column, but account for infrequent processes. Reporting jobs, exports and restore scripts may not run during the observation period.
Require owners of those paths to verify their updated behaviour. Record the last supported rollback version and the date or condition after which it will no longer be used.
A lack of recent reads is useful evidence, not proof by itself. An annual process can remain a valid dependency despite months of silence.
Perform the destructive step separately
Review the column removal as its own change with its own lock and dependency effects. Avoid broad cascading removal unless every affected object is understood and intended.
Confirm the recovery approach for data that will no longer be available in the active schema. Restoring an old backup into production may discard newer writes, so it is not a casual undo button.
After removal, exercise the supported application and recovery paths again. The later release makes the irreversible boundary explicit and gives the team time to discover hidden consumers before the data is gone.
Primary sources
PostgreSQL: ALTER TABLEReferences checked 11 September 2026.