Field Notes · 12 June 2026
When to Expand–Contract Instead of Renaming a Table Overnight
A practical decision guide for teams tempted to rename or split a hot table in a single maintenance window.
Overnight renames feel clean on a whiteboard. In production they collide with ORMs, cached query plans, read replicas that lag, and reports someone forgot to mention.
Signals that expand–contract is safer
- The table is written by more than one service
- You cannot freeze deploys for both application and database in the same hour
- Replicas or analytics copies trail the primary by minutes
Expand–contract means adding the new structure beside the old one, dual-writing or backfilling, switching reads, then removing the old path. It takes more calendar time. It usually costs less than a failed cutover.
A minimal sequence
- Add new columns or tables without removing the old ones
- Backfill in controlled batches with progress metrics
- Dual-write from the application or a trigger, depending on your stack
- Move reads after verifying row counts and spot checks
- Stop dual-write and drop the legacy objects only when monitoring is quiet
If you are mid-refactor and unsure where you sit on this spectrum, a Database Refactoring engagement starts by mapping writers before touching names.