We added an index to fix one slow query. Every write got 3x slower for a year before anyone connected the two.

Problem

A dashboard query was timing out, so we added an index on the column it filtered by. The query got fast. Nobody checked what else that table did.

That table took writes constantly: every order update touched it. Adding the index meant every one of those writes now had to update the index too. Write latency crept up for a year. We blamed the database instance, then the ORM, then “scale.” We never blamed the index, because the index was the thing that had fixed a problem.

Why it happens

Indexes are sold as a free win: read query slow, add index, read query fast. The cost is invisible because it doesn’t show up in the same query: it shows up as a slow drift across every write to that table, weeks later, in a completely different part of the codebase. Nobody profiles writes the way they profile reads, so the regression has no fingerprints.

Better approach

Before adding an index, check the table’s read/write ratio, not just the slow query. On write-heavy tables, prefer a narrower composite index over several single-column ones, and measure write latency before and after the change, not just the query you were trying to fix. If you’re not sure how hot the table is, log it for a week first.

Example

Orders table, ~200 writes/minute, one new index added to speed up a support dashboard used twice a day. The dashboard got faster. Checkout got slower. Nobody made the connection until a query planner review a year later showed four indexes on a table that only needed two.