The query finished running, but the numbers don’t match. You need a new column.
Adding a new column should be simple, fast, and safe. Yet in many systems, it’s a source of downtime, data loss, or creeping performance issues. Schema changes are easy to overlook until they hit production traffic. By approaching the problem with the right process, you can eliminate risks and keep your data consistent.
When you add a new column in a relational database, you change the table definition. The database has to store this new field across every row. In small tables, this is almost instant. In large ones, the ALTER TABLE command can lock writes and trigger long-running background operations. If your system handles live requests, that lock can back up queues or cause user-visible errors.
Best practice: always run schema migrations in a controlled deployment pipeline. Plan for backward compatibility. First, add the column with a null default so existing code keeps running. Then, deploy application changes that can write to the new column. Only after confirming writes succeed should you begin migrating and backfilling data.