The migration finished, but the wrong numbers still appeared. A new column was needed—fast, precise, no downtime.
Adding a new column to a production database can feel routine, but it’s a point where performance, reliability, and design decisions converge. Schema changes are simple in isolation, but in a live system, every second counts. Missteps can cascade into outages, inconsistent data, or broken services.
Start with the reason. A new column should serve a clear purpose: capturing required data, supporting new features, or replacing legacy fields. Avoid speculative additions. Each column increases storage, indexing costs, and query complexity.
Plan the migration path. For smaller datasets, a simple ALTER TABLE ... ADD COLUMN may be enough. For high-traffic, large tables, consider online schema change tools like gh-ost or pt-online-schema-change to avoid locking writes. Always measure the impact on replication lag and query latencies.
Set defaults deliberately. Adding a column with a non-null default can rewrite the entire table, causing massive write amplification. When performance matters, add the column as nullable first, backfill data incrementally, and then set constraints once the table is synchronized.