The logs showed a missing index. You needed a fix without breaking production. The answer was simple: add a new column.
A new column can unlock performance, extend functionality, and future-proof your schema. But the operation is not a throwaway. Schema changes touch live data, transactional integrity, and downstream systems. Done wrong, they cause lock contention, replication lag, and failed deployments. Done right, they are invisible to users and developers alike.
When you add a new column in SQL, think about impact before execution. Check row counts. Identify indexes. Evaluate triggers and defaults. Avoid non-null constraints with no defaults on large tables—they rewrite every row. Use nullable or default-backed columns to minimize writes. Consider rolling changes: add the column first, backfill in batches, then enforce constraints in a later migration.
In PostgreSQL, ALTER TABLE ADD COLUMN is fast for nullables because it only updates metadata. For MySQL and MariaDB, the engine may rebuild the table depending on column position, datatype, and server version. On large production datasets, each of these details can be the difference between a two-second change and an all-night outage.