A PostgreSQL database that has handled production traffic for years starts missing its latency targets.

The immediate suggestions are predictable:

Add read replicas.

Put Redis in front of the database.

Partition the largest tables.

Start planning for sharding.

Any of those might eventually be the right decision.

But choosing one before understanding the bottleneck is how a manageable performance problem becomes an expensive architecture migration.

The first question isn't "How do we scale PostgreSQL?" It's "What is PostgreSQL actually waiting on?"

The scenario

Imagine a commerce API running on a single PostgreSQL primary.

The application has been stable for three years. During the evening traffic peak, checkout latency rises sharply, but outside that window everything looks normal.

The team suspects that the database has outgrown its architecture.

One engineer proposes a read replica. Another suggests Redis.…