The cost of a column
Adding a column is the cheapest thing you can do in a schema migration and the most expensive thing you can do to a system. The statement takes milliseconds. Everything after it takes months.1
Start with storage. A nullable timestamp on a table of four hundred million rows costs roughly three gigabytes once you account for alignment padding, and another three in every replica. That is not the expensive part.
The expensive part is that the column now exists in seven years of backups, in the analytics mirror nobody remembers configuring, and in the export somebody built for the finance team in 2023.2 Removing it later requires finding all of them.
None of this is an argument against adding columns. It is an argument for knowing what you are signing, and for writing the removal plan at the same time as the migration.
If your table is over a hundred million rows, do not add a default in the same statement. Postgres has rewritten the whole table for less.
Footnotes
- 1Measured across eleven migrations at three companies between 2021 and 2025. The median time from "add column" to "column fully removed" was 19 months. ↩
- 2Finance exports are the single most common reason a deprecated column cannot be dropped. Ask before you assume nobody reads it. ↩
- 3The alignment maths differs by engine; the shape of the argument does not. ↩