Learn
Database sizing: which RDS instance, how many replicas, and when to shard
A database is usually the most expensive part of a system to scale and the first to break. Sizing it comes down to three questions: does the hot data fit in memory, can one primary keep up with the writes, and how many replicas do the reads need?
· 4 min read
Size your database
Cheapest fit: db.r7g.xlarge, primary + 3 replicas (4 instances) for about $1,396/month. With a cache answering 90% of reads, it drops to db.r7g.xlarge, primary only for about $349/month. Size the cache.
| Size | vCPU · RAM | Layout | Hot data fits RAM | Per month |
|---|---|---|---|---|
| db.m7g.large | 2 · 8 GiB | primary + 5 replicas | no (needs 27 GiB) | $736 |
| db.r7g.large | 2 · 16 GiB | primary + 5 replicas | no (needs 27 GiB) | $1,047 |
| db.r7g.xlarge | 4 · 32 GiB | primary + 3 replicas | yes | $1,396 |
| db.r7g.2xlarge | 8 · 64 GiB | primary + 2 replicas | yes | $2,094 |
| db.r7g.4xlarge | 16 · 128 GiB | primary only | yes | $1,396 |
Approximate AWS on-demand prices for us-east-1, read once in October 2026, before free tiers. They may be out of date; check the AWS pricing pages before you budget.
Start with memory: the working set
A database is fast when the data it reads often is already in memory, and slow when it has to fetch it from disk. AWS's ownRDS best practicesput it plainly: "allocate enough RAM so that your working set resides almost completely in memory. The working set is the data and indexes that are frequently in use on your instance."
The working set is usually much smaller than the whole database: last month's orders, not ten years of them. Estimate it, then pick a size whose memory comfortably holds it. PostgreSQL on RDS gives about a quarter of instance memory to its own buffer cache by default (shared_buffers is {DBInstanceClassMemory/32768} in 8 KB pages), and the operating system's file cache uses much of the rest. To check, AWS suggests watching ReadIOPS under load: it should be small and stable.
Then CPU: queries per second
Throughput depends on the queries. Read-only primary-key lookups are cheap: pgbench reaches around 20,000 per second from a single client on one core. Real workloads mix joins and writes; one benchmark of a write-heavy workload on RDS measured about4,900 transactions/s on 4 vCPUs. For planning, this site assumes about 500 queries/s per vCPU while the working set fits in memory, so a 2-vCPUdb.r7g.large handles about 1,000.
Too many reads: add read replicas
A read replica is a copy of the database that serves reads. RDS for PostgreSQL supports up to15 per primary by default. Two things to know:
- Replication is asynchronous. AWS: "the data on the read replica might be stale." A user who writes and immediately reads from a replica may not see their own change.
- Replicas don't help writes. Every write still goes to the primary, and every replica has to apply it too.
Too many writes: scale up, then shard
Writes all land on one primary, so the first fix is a bigger primary. When the biggest sensible size can't keep up, split the data across several primaries, each owning part of the keys. That's sharding: it scales writes and storage, at the cost of cross-shard queries and rebalancing. Most teams put it off as long as they can, and they should.
Before any of this: put a cache in front
The cheapest database capacity is the read that never reaches the database. With a 90% cache hit ratio, 3,000 reads/s becomes 300. With the calculator's rules, 3,000 reads/s and 200 writes/s against a 20 GiB working set needs4 × db.r7g.xlarge ($1,396/month); with a cache in front taking it to 300 reads/s, 1 × db.r7g.xlarge ($349/month)is enough. See how big that cache needs to be.
RDS for PostgreSQL sizes
| Size | vCPU · RAM | Handles about | Per month | In plain words |
|---|---|---|---|---|
db.t4g.micro | 2 · 1 GiB | 100 queries/s | $12 | Free-tier sized. Development only: 1 GiB of RAM can't cache much of any real dataset. |
db.t4g.small | 2 · 2 GiB | 200 queries/s | $23 | Burstable, 2 GiB. A small side project with light, uneven traffic. |
db.t4g.medium | 2 · 4 GiB | 200 queries/s | $47 | Burstable, 4 GiB. Staging environments and early products. |
db.m7g.large | 2 · 8 GiB | 1,000 queries/s | $123 | Fixed performance, 8 GiB. The smallest size worth putting steady production traffic on. |
db.r7g.large | 2 · 16 GiB | 1,000 queries/s | $174 | Memory-optimized, 16 GiB. The usual production database: RAM keeps hot rows and indexes off disk. |
db.r7g.xlarge | 4 · 32 GiB | 2,000 queries/s | $349 | 4 vCPU, 32 GiB. The next step when CPU or the working set outgrows a large. |
db.r7g.2xlarge | 8 · 64 GiB | 4,000 queries/s | $698 | 8 vCPU, 64 GiB. Every size up doubles the price; check whether a cache or a replica is cheaper. |
db.r7g.4xlarge | 16 · 128 GiB | 8,000 queries/s | $1,396 | 16 vCPU, 128 GiB. Big enough that most teams shard or add replicas before going further. |
These are Single-AZ prices. A Multi-AZ deployment, with a synchronous standby that takes over if the primary fails, costs twice as much, and the standby can't serve reads. Burstable db.t4g sizes sustain only part of their CPU, so they suit development, not steady production load.
Watch a database fall over and fix it in The Stampede, or see replicas, shards and a cache work together in the URL shortener challenge.
Frequently asked questions
How do I choose an RDS instance size?
Start with memory: AWS's own best practice is to have enough RAM that your working set, the data and indexes in frequent use, sits almost entirely in memory. Then check CPU against your peak queries. Memory-optimized db.r7g sizes are the usual choice for production PostgreSQL.
Should I add a read replica or move to a bigger instance?
Read replicas add read capacity; they don't help writes, and because replication is asynchronous a replica can return slightly stale data. A bigger instance adds both CPU and memory. If writes are the bottleneck, you eventually need to shard: split the data across several primaries.
How many read replicas can an RDS PostgreSQL database have?
By default up to 15 read replicas per primary instance; the quota can be raised.
Do read replicas help with write traffic?
No. Every write still goes to the primary, and each replica has to apply it too. Replicas scale reads only.