Adding a Database Server Doubled Capacity. One Index Multiplied It by 2,600.

The API is slow.

The dashboard takes two seconds to load. Someone opens the database graph and sees CPU at 100%.

Then the meeting starts.

“We need a read replica.”

“Should we add Redis?”

“Maybe it’s time to shard.”

All three sound like serious engineering. All three cost money, add moving parts, and stay with you for years.

You can read this article for free via this link ( my newsletter ): Click Here 👈

But nobody in that meeting has asked the first question: what is the database actually doing?

Nikki Siapno’s recent Level Up Coding piece on scaling databases lays out a sensible order: measure the bottleneck, reduce the work, optimize queries, then add replicas, and shard last.

So this article puts that order to the test. One table, one slow query, one load test, and real measurements at each step.

The Test

The setup is a small PostgreSQL lab that you can run yourself. The full script is at the end of this article.