Dropping things safely

The consumer you did not know about is always the one that matters.

Removing a column or a table is blocked by uncertainty about who reads it, and the uncertainty is legitimate: reporting tools, exports, integrations and scripts written by people who have left are all consumers that do not appear in the application code.

The safe sequence is to stop writing, observe, then drop. Renaming the object first, or revoking access, produces errors from any remaining consumer while the object still exists and can be restored in minutes. Dropping first produces the same errors with no recovery.

Observation needs long enough to cover the slowest cycle. A monthly report will not fail until month end, and a quarterly one until the quarter, so a fortnight of silence proves considerably less than it appears to.

Where the database can log access to an object, that is the strongest available evidence and it is worth turning on for the period rather than reasoning about who might be using it.

It is worth noting that a dropped object is not recoverable from a backup without restoring the whole thing, which for a large database is a long operation on a system already under stress. That asymmetry is the real argument for the rename-first sequence, since renaming back takes a second.