RDS Read Replicas and the Reserved Instance Trap (2026)

A read replica roughly doubles your RDS compute bill, and your primary’s Reserved Instance discount does not carry over to it. Reserved Instances in RDS are scoped per instance class, per region — so a replica runs at full on-demand price unless you buy a second RI to cover it. For a small team, that means a db.t4g.medium primary you reserved for ~$45/month suddenly grows a ~$90/month on-demand twin the moment you add a replica, and most people only notice on the next invoice. Before you provision one, decide whether you need a replica at all or whether a bigger primary plus a cache is cheaper.

Why the replica surprises people #

The mental model that trips teams up is treating a read replica like a feature toggle on an existing database. It isn’t. A replica is a fully separate RDS instance with its own compute, its own storage, and its own hourly rate. If you reserved the primary — the right move for anything running 24/7 — the discount applies only to one running instance of that class in that region at a time. The replica is a second instance, so it bills at on-demand unless you reserve it too. AWS also charges for the storage the replica carries, since it mirrors the primary’s allocated storage, and, if the replica lives in a different Availability Zone, for the cross-AZ data transfer feeding it. None of that shows up in the ’add replica’ click-through.

Concretely, in us-east-1 as of early 2026, a db.t4g.medium on-demand is roughly $0.125/hour, about $90/month. A one-year no-upfront Reserved Instance brings that to roughly $0.063/hour, about $45/month — a ~50% cut. Add a replica and you’re back to paying the full ~$90/month for the replica on top of your reserved ~$45 primary, so the pair costs ~$135/month, not the ~$90 you might have budgeted by doubling the discounted number. Reserve the replica too and the pair drops to ~$90/month. The difference between reserving and forgetting to reserve the replica is $45/month, or $540/year, on a single small database. Prices drift and vary by region, so confirm current rates before you commit.

Do you actually need the replica? #

For most small teams the honest answer is ’not yet.’ Read replicas earn their cost when you have genuine read-heavy traffic that a single instance can’t absorb, or when you want analytics queries isolated from transactional load. If your reason is ’my database feels slow,’ the cheaper first move is usually a cache in front of hot reads or a right-sized primary. We walk through that trade-off in ElastiCache vs Memcached for startups — an ~$8/month cache often removes more read pressure than a ~$90/month replica, because it absorbs the repeated queries a replica would still have to execute. The replica is the answer when you need read throughput or read isolation, not merely lower latency on repeated queries.

The other common replica motivation — availability — is usually better served by Multi-AZ, which is a different billing line and a different failover story. A read replica is not a failover target in the automatic sense a Multi-AZ standby is; promoting a replica is a manual operation that can lose data under replication lag. If high availability is the goal, cost it as Multi-AZ. If cheap durable recovery is the goal, start with a solid backup posture instead. Our RDS backup strategy for teams without a DBA covers that path, which costs cents per GB rather than a doubled compute bill.

How Vylara keeps the replica decision explicit #

When you connect the Vylara GitHub App and the agent engine analyzes your repository, it detects a PostgreSQL or MySQL dependency — through ORMs like Prisma, TypeORM, or psycopg2 — and surfaces a plain ’Your app needs’ card with an estimated monthly cost. A managed database shows as roughly ~$15/mo on the smaller end before you’ve picked a class. You choose ’Create a managed database’ or point at one you already run. Nothing is provisioned from that screen and nothing lands in your cloud account until your first deploy, so the cost estimate is something you reason about before any instance exists. A read replica is a deliberate add-on in your own AWS account, not a default Vylara spins up for you.

Because everything Vylara creates lives in your AWS account, the RDS instances, their Reserved Instance coverage, and the bill all stay yours end to end — Vylara charges for the orchestration layer, not compute. That matters for the RI question specifically: you buy and manage Reserved Instances directly through AWS, the same way you would if you’d clicked it all by hand, and the discount applies to whatever matching instances are running, replica or not. If you later add a replica and the primary’s RI was sized for one instance, you’ll see the on-demand charge appear exactly as described above. After launch, the in-app infrastructure chat can read your service status, logs, and cost data, so you can ask whether a replica is actually carrying read load before you commit to reserving a second instance for it.

The bottom line for 2026 #

Treat a read replica as a second full database, because that’s what the bill calls it. Reserve both instances if the replica is permanent, size the primary and reach for a cache before you reach for a replica, and use Multi-AZ rather than a replica when the real goal is availability. For broader context on sizing AWS databases without overpaying, start from the AWS pillar and work down to the specific services your repo actually needs. The cheapest replica is still the one you proved you needed before you provisioned it.