At the database level, the ALTER TABLE ... ADD COLUMN command is direct, but its consequences ripple. If the table has millions of rows, adding a column with a default value can lock writes for seconds or minutes. On some systems, non-null constraints and indexes increase that cost. In large deployments, you may need to use a rolling migration. Add the column as nullable, backfill asynchronously, then enforce constraints later.
Application code must be in sync. If you deploy a schema change before code that handles the new column, you risk null errors or ignored data. If you deploy the code first but the column doesn’t exist yet, queries can fail. The safest pattern is forward- and backward-compatible releases: deploy schema changes that won’t break old code, deploy code that works with both versions, then remove backward-compatibility later.
New columns impact query plans. Even if the application doesn’t use them yet, some queries that use SELECT * will pull more data over the wire. That can degrade performance at scale. Always update queries to reference explicit columns and ensure indexes are tuned. For text or JSON columns, watch storage bloat and I/O load.