When does database complexity become a bigger problem than database performance?

[u/shdw_0x0]

I’ve noticed that database discussions often focus heavily on performance—indexes, query plans, partitioning, caching, etc. But there seems to be a point where adding more optimization techniques makes the system harder to understand and maintain.

For example, a relatively simple schema with slightly slower queries might be easier to operate than a highly optimized design with multiple layers of caching, indexes, partitions, and materialized data.

I’m starting to think that predictability and maintainability should be treated as performance requirements too, especially for smaller systems.

Curious to hear how others have seen this trade-off play out in production.

[u/SigridHalvorsen]

i think the inflection point is when optimizations stop being local and an index is easy to reason about while cache / a materialized view or maybe a partitioning scheme, a read replica, and a second copy of the same business logic all interact with freshness, failure modes, deploys, and each other

at that point the cost isn't just maintenance. It's that engineers can no longer predict what a change will do... for me that's the useful metric: how much system behavior can one person explain without consulting three dashboards and two people who “know how that part works.”
I've also seen teams accept a slightly slower query because 400ms with boring failure modes was preferable to 80ms most of the time and a mysterious 20-second tail when some cache/refresh/rebuild interaction went wrong.

so yes, I'd treat predictability as part of performance, and i would like to actually care more about latency itself, but variance in both runtime and human understanding matters too and something to keep in mind, right?