Every index speeds up reads that use it, but slows down writes — every INSERT, UPDATE (of an indexed column), and DELETE has to update every index touching the affected columns, not just the underlying table. Each additional index is one more B-tree that has to be kept balanced and sorted on every write.
| Operation | Cost with no indexes | Cost with N indexes on the affected columns |
|---|---|---|
INSERT | Write one row | Write the row, plus insert into each of the N index structures |
UPDATE (indexed column) | Update one row | Update the row, plus remove/re-insert in each affected index |
DELETE | Remove one row | Remove the row, plus remove the entry from each index |
Indexing every column "just in case" is a common anti-pattern that quietly degrades write throughput without a corresponding read benefit, since most of those indexes never actually get used by any real query — every table's indexes should be a deliberate, reviewed set, not a reflexive default.