AWS Has 15 Databases. You Probably Need Two.

Every few months another RDS-vs-Aurora-vs-DynamoDB-vs-ElastiCache decision guide makes the rounds, and the core advice is always the same: start from your access patterns, not the database's feature list. That advice is correct. It's been correct since roughly 2018. What the flowcharts keep missing is that AWS spent late 2024 and 2025 quietly knocking the legs out from under the old decision tree — two price cuts, one scale-to-zero release, and one genuinely new database later, the choice in front of you looks different than the diagrams suggest.

The defaults moved while nobody was looking

Four changes matter, and they landed close together.

In November 2024, Aurora Serverless v2 gained the ability to scale to zero ACUs. That killed the single best argument for putting a small or spiky workload on DynamoDB: "relational costs money while it's idle." A paused Aurora Postgres cluster now bills for storage only, and resumes on first connection in about fifteen seconds — fine for dev environments, internal tools, and anything that sleeps nights and weekends; not fine for a production endpoint with a latency SLO.

That same month, AWS cut DynamoDB on-demand throughput pricing by 50% (to $1.25 per million writes and $0.25 per million reads in us-east-1) and global tables by up to 67%. If you last did the provisioned-versus-on-demand spreadsheet before then, your math is stale. On-demand is now the sane default unless your load is genuinely flat and heavily utilized — the price cut ate most of provisioned capacity's advantage, and it never had on-demand's forgiveness for traffic you didn't predict.

A month earlier, ElastiCache picked up Valkey, the open-source Redis fork, at roughly 20% below Redis OSS pricing for node-based clusters and about 33% below for serverless, which now starts around $6 a month at 100 MB.

And in May 2025, Aurora DSQL went GA — a serverless, Postgres-compatible distributed SQL database with active-active multi-region writes. More on why that's the only genuinely new fork in the road below.

Default to Postgres, and mean it

"Start with access patterns" hides a trap: it assumes you know your access patterns. Early-stage products don't, and this is exactly where DynamoDB punishes you. Single-table design is a commitment — a new query shape means a new global secondary index (each one billed separately, tripling costs is not unheard of) or a backfill migration. A relational database lets you defer those decisions indefinitely; that's what the query planner is for. The freedom to add CREATE INDEX and a JOIN next quarter is worth real money when the product is still finding its shape.

So the honest default is Postgres, and the only real question is which trim level. Plain RDS Postgres is the budget answer: it tops out at 64 TiB and fails over in a minute or two, but the instance-hour price runs roughly 20% below Aurora's. Aurora buys you failover in about half the time, storage that auto-grows to 128 TiB, up to 15 low-lag read replicas on shared storage, and — the recent unlock — serverless that scales to zero. For anything customer-facing, Aurora's premium is cheap insurance. For the fifth internal dashboard database, it isn't.

DynamoDB still wins a real and large category: access patterns that are known, stable, and key-shaped. Session state, user profiles by ID, IoT and event firehoses, multi-tenant SaaS metadata, anything bolted to Lambda where per-request billing on both layers keeps costs aligned with traffic. At post-cut prices, ten million reads and a million writes a day lands in the low hundreds of dollars a month on-demand, with zero capacity planning. If that's your workload, nothing relational competes on ops burden. The mistake isn't choosing DynamoDB — it's choosing it before your query shapes have stopped moving.

ElastiCache was never on this menu

Putting ElastiCache in a four-way database comparison is a category error that these guides keep repeating. It's not an alternative to any of the above; it's a layer you bolt onto one of them once you've measured a latency or cost problem, not before. The only decision it actually presents in 2026 is Valkey versus Redis OSS, and that one's easy: Valkey is API-compatible, supports in-place upgrades from existing Redis clusters, and is permanently cheaper. Barring a dependency on something Redis-Inc-proprietary, there's no reason to start a new cluster on Redis OSS today.

DSQL is the interesting fork — but read the asterisks

Aurora DSQL is AWS's answer to the gap this whole debate orbits: people who want relational semantics with DynamoDB's operational model. Serverless, no capacity planning, active-active writes across regions with strong consistency, 99.999% multi-region availability, Postgres wire compatibility. It's aimed squarely at Spanner and CockroachDB, and architecturally it's the most interesting database AWS has shipped in a decade.

But "Postgres-compatible" is doing heavy lifting. No foreign keys. No triggers. No temporary tables. Most extensions — including PostGIS and the vector tooling everyone suddenly needs — are absent. Transactions are capped at thousands of modified rows, which rules out bulk loads and casual ETL. That's not Postgres; it's the Postgres wire format over a Dynamo-shaped engine, with referential integrity pushed into your application code. For a greenfield multi-region service whose team accepts app-enforced integrity, it's worth a serious spike. As a default OLTP store, it's not there yet — and porting an existing Postgres app to it is a rewrite wearing a migration's clothes.

The short version

AWS's story is fifteen-plus purpose-built databases, one for every workload. The practitioner's story is shorter: one relational default (Aurora Postgres, serverless if it's small or spiky), one key-value escape hatch for when scale is real and query shapes are frozen, a Valkey cache when you've measured the need, and DSQL on a watchlist. The proliferation mostly serves keynote slides. Your architecture review only needs the four lines above — and the discipline to not reach for the exotic option before the boring one has actually failed you.