Learn the Standard
Migration Safety
Prepare migrations for production data, locks, failure, retries and recoverability.
Every material migration needs an operational header
-- Purpose: Add private documents owned by one authenticated user.
-- Authorization: Owner-only read/write; no anonymous access.
-- Data impact: Additive; no existing rows changed.
-- Lock/availability: Creates new objects only.
-- Rollback: Drop only before application use; afterward forward-fix.Expand, migrate, contract
Live systems should usually add compatible structures first, migrate or backfill deliberately, and remove old contracts only after deployed code no longer depends on them. Do not combine destructive cleanup with an initial feature deploy unless the system is verified empty or the accepted downtime/data loss is recorded.
Do not paste an unbounded production backfill
A single update may be acceptable only for a verified small or inactive table. For material production data, require a resumable, stable-key-bounded batch plan with recorded progress, correctness during concurrent writes, monitoring between batches, and clear stop/resume behavior.
Plan locks and non-transactional operations
- Set transaction-local lock and statement timeouts only with understood per-statement semantics and an execution plan.
- Consider not valid plus later validation for supported large-table constraints.
- Consider create index concurrently for actively written tables, understanding that it cannot run inside a transaction block.
- After a concurrent index build, verify the index is ready and valid; failed builds can leave invalid indexes behind.
- For destructive work, confirm backup, restore, or compensating recovery before application.