A senior engineer at a well-funded startup once dropped a column from a production database on a Tuesday afternoon. The column stored a legacy flag that hadn’t been written to in months. The tests passed. The deploy went smoothly. By Wednesday morning, a background job that nobody had touched in two years was silently failing, producing no errors, just wrong data flowing into invoices that would take three weeks to reconcile.
This is not an unusual story. It is, in fact, a genre.
The Problem Is What You Cannot See
Database columns exist in a peculiar epistemic position. Every piece of code that reads from or writes to a column is a dependency, but almost none of those dependencies are declared anywhere. A foreign key constraint enforces a relationship between tables. A NOT NULL constraint enforces presence. But there is no schema-level mechanism that says “this column is read by the billing worker, the analytics pipeline, two internal admin tools, and a CSV export that the operations team runs every quarter.”
This is why deleting a column is fundamentally different from deleting a function or a class. When you remove a function, most compiled languages will refuse to build. Statically-typed languages force the dependency graph into the open. Databases don’t. The schema changes. The application code that referenced the column continues to exist, untouched, blissfully unaware. Whether it crashes, silently misbehaves, or returns nulls masquerading as valid data depends entirely on how the query was written and how the application handles unexpected absence.
The silent failure is the worst outcome. A hard crash is recoverable. You see it, you respond, you roll back. Silent data corruption compounds invisibly until someone notices that the numbers don’t add up, which, depending on your observability setup, could be days or months later.
The Deployment Gap Is Real and Underestimated
Modern deployment practices make this worse in a specific way. Blue-green deployments, rolling restarts, and canary releases are excellent practices for reducing downtime. They also mean that multiple versions of your application code run simultaneously against the same database. If you drop a column and deploy in the same release, you will briefly have old application instances querying for a column that no longer exists.
The standard advice is correct: deprecate first, then remove. Stop writing to the column, then stop reading from it, then remove it from your ORM models, then wait a full deployment cycle (at minimum), then drop it from the schema. This process is tedious. It takes weeks when the underlying desire is to just clean up a messy schema in an afternoon. Most teams skip steps, especially under deadline pressure, especially when the column genuinely looks unused.
“Looks unused” is doing a lot of work in that sentence. Code search is not a substitute for runtime dependency analysis. A column that appears nowhere in your main application repository might appear in your data warehouse ETL, in a vendor’s read replica integration, in a monitoring query your infrastructure team wrote directly against the database, or in the kind of one-off script that never quite gets filed as a known dependency.
Why Engineers Keep Getting This Wrong
The incentive structure around schema cleanup is misaligned in a predictable way. Technical debt is visible to engineers and nearly invisible to everyone else. A column that shouldn’t exist is annoying to the people who read the schema regularly, which is a small group. The work of safely removing it, done properly, is slow, multi-stage, and produces no visible feature. The risk of removing it carelessly is probabilistic and future-dated.
This creates the same pressure that produces most infrastructure incidents: the cost of doing the right thing is immediate and certain, while the cost of cutting corners is deferred and uncertain. Humans are not well-calibrated for that tradeoff. The engineer who eventually fixes the breakage rarely understands why the column existed, which means the institutional knowledge that might have prevented the incident is already gone by the time it’s needed.
There’s also a tooling gap. Most teams have sophisticated controls around code changes: pull request reviews, CI pipelines, test coverage requirements. Database migrations frequently receive less scrutiny. A migration file gets reviewed once, by whoever happens to look at the PR, without the benefit of automated analysis that maps the column to all its consumers. The asymmetry is striking. The riskiest operation in many systems gets the least tooling.
How to Do It Right
The practical framework is straightforward, even if the discipline required to follow it is not. Before touching a column, query your application logs for any SELECT or reference to that column name over a meaningful time window (thirty days minimum, ninety is better for anything that might run on a quarterly basis). Check your data warehouse pipelines explicitly, since they often lag application deploys and query production databases directly. Search your codebase across every repository your organization maintains, not just the main one.
Then: stop writing. Deploy. Verify. Stop reading. Deploy. Verify. Remove from models. Deploy. Verify. Drop from schema. Each step is its own deployment cycle with its own verification period. If this feels like overkill for a single column, consider what it would cost in engineering hours and customer trust to untangle corrupted billing data.
Some teams add column-level usage tracking: a simple wrapper that logs whenever a column is read or written, giving you runtime visibility that static analysis cannot provide. It’s additional overhead, but for columns you suspect are unused, the data is invaluable.
The underlying principle is that database schemas are public contracts, not internal implementation details. Every column is an implicit promise to every consumer of that data. Breaking that promise quietly, without notice, is not cleanup. It’s a liability that gets deferred, not eliminated.
The column that looks useless probably isn’t. And the one that genuinely is useless is still worth removing carefully, precisely because careless removal is how you find out you were wrong.
