The best fix I’ve seen recently: delete the table causing the latency. Task done. ✅
Something similar happened when I tried to reduce API read latency.
I asked AI—Codex—to optimize a slow query. It did well. Read latency dropped by 70%.
But two other endpoints became slower the same day.

What actually happened:
- It created three unique indexes.
- It removed one “redundant” index.
- The new indexes made writes more expensive because every
CREATEandUPDATEhad more index structures to maintain. - The removed index had served another update query. Its replacement covered the same columns, but not in the order that query needed.
Our create and update endpoints went from roughly 400 ms to 900 ms.
Optimization is always a trade-off. Do we optimize reads, writes, or both? That depends on the read-to-write ratio and the overall workload.
Before touching indexes:
- Check which queries use each index.
- Check how long the new index will take to build and its impact during the build.
- Understand the overall workload on the table.
Reducing latency isn’t just adding indexes. It means optimizing the whole system.