Scaling PostgreSQL: From Single Instance to RDS

PostgreSQL is the database most developers reach for, and for good reason. It handles JSONB, full-text search, geospatial queries, and complex joins with remarkable efficiency. But the default single-instance setup that works beautifully for a few hundred concurrent users starts showing cracks as you scale. Understanding where those cracks appear — and which tools address each one — is the difference between a smooth scaling story and a 3 AM outage.

The first bottleneck is almost always connections. Each PostgreSQL connection consumes roughly 10 MB of memory and a kernel thread. At 200 concurrent connections, you are using 2 GB of RAM just for connection overhead — memory that could be serving queries. The fix is connection pooling. PgBouncer , running as a sidecar in your Docker container or as a standalone service, multiplexes hundreds of application connections into a handful of database connections. In transaction pooling mode, a connection is assigned to a client only for the duration of a transaction, then returned to the pool. This single change can increase your effective connection capacity by 10x without touching the database configuration.

The second bottleneck is read throughput. If your application is read-heavy — dashboards, reporting, search — a single primary instance eventually cannot keep up. RDS makes adding read replicas trivial: a few clicks or a single Terraform resource, and you have a replica that streams WAL records from the primary with sub-second lag. Point your read queries at the replica endpoint and your writes at the primary. For frameworks that support it, use a connection routing middleware that directs queries based on whether they are inside a write transaction. The RDS proxy service can handle this routing automatically, reducing application-level complexity.

The third tool in the scaling arsenal is Redis . Not every query needs to hit the database. User sessions, feature flags, computed aggregations, and frequently accessed reference data are ideal candidates for caching. A well-placed Redis cache in front of your most expensive queries can reduce database load by 80% or more. The pattern is straightforward: check Redis first, return the cached value if it exists, otherwise query PostgreSQL , store the result in Redis with a TTL, and return it. Cache invalidation is the hard part — prefer short TTLs over complex invalidation logic unless your data changes rarely.

For local development, keep your Docker Compose setup mirroring production as closely as possible. Run PostgreSQL and Redis as containers, use the same major version as your RDS instance, and seed the database with realistic data volumes. Performance problems that only appear at scale are painful to debug — catching them early in a local environment that approximates production saves enormous time. Run EXPLAIN ANALYZE on your critical queries regularly, and treat a sequential scan on a large table as a bug, not a quirk.