The database was slow, and the error logs were getting longer. You saw the pattern right away: the schema was missing a field the new feature depended on. The answer was clear. Add a new column.
Adding a new column sounds simple, but in live production systems it can cause more damage than any bug in your code. Schema changes touch the core of your data model. They can lock tables, block queries, and break downstream services. The way you add that column determines whether your next deploy is a success or a rollback.
First, never run ALTER TABLE ... ADD COLUMN blindly in production. On large tables, this can trigger a full table rewrite and cause downtime. The safer path is an online schema change. Most modern databases support methods to add a column without locking reads or writes. In PostgreSQL, adding a new nullable column without a default is instant. In MySQL, tools like pt-online-schema-change or gh-ost help modify tables without blocking.
When planning the new column, define the data type and nullability with precision. Avoid defaults on large tables unless absolutely necessary. If you must store computed or derived values, consider generating them in application code until the column is live and populated.