That argument settles architecture decisions all the time, and it’s the wrong argument. Both services return a primary-key lookup faster than your network hop and your ORM overhead. What hurts six months later is the query nobody wrote down at the start, and no benchmark will warn you about it.

So this post skips the latency charts. It covers the access pattern inventory you write before picking anything, where each service genuinely wins and genuinely hurts, a decision procedure you can run in an afternoon, and the arguments on both sides that fall apart on contact with a real workload.

Why the benchmark answers a question you don’t have

A benchmark measures a fixed operation under fixed conditions. Your application is not a fixed operation. It’s a set of reads and writes that grows every time somebody asks a new question about the data.

The failure mode that decides RDS vs DynamoDB is almost never throughput. It’s a product manager asking, eight months in, for every account that hasn’t logged in this quarter, broken down by plan tier. On Postgres that’s an awkward query and maybe an index. On DynamoDB, if you didn’t model for it, it’s a full table scan, a new global secondary index, a backfill, and a standing write-capacity tax to keep it in sync.

That asymmetry is the whole decision. A relational database defers the modeling cost and charges a little on every query for the flexibility. DynamoDB front-loads it: design keys around known patterns, get cheap predictable reads for exactly those, and pay dearly for anything else.

Write the access pattern inventory first

Before comparing anything, write the list. Every read and write the application performs, in plain language, with the shape of the operation and how fast it needs to be. This much is enough:

PATTERN                                SHAPE           FREQ    LATENCY
get order by id                        point read      high    p99 < 50ms
list a customer's orders, newest first range read      high    p99 < 100ms
orders by status, across customers     cross-entity    low     seconds fine
revenue by product category, monthly   aggregate       low     minutes fine
find orders by partial address         text match      medium  p99 < 300ms
mark order shipped + write audit row   multi-item write high   p99 < 100ms

Now read the SHAPE column. If nearly every row is a point or range read, and the exceptions tolerate latency, DynamoDB is a live option. If the column is full of cross-entity reads, aggregates and text matching, you’re describing a relational workload and can stop shopping.

The rows people leave out

The inventory is only useful if it’s honest, and the omissions are predictable:

• The admin back office. Support staff search by email, phone, partial name, anything. Ad hoc queries, and they never appear in the first inventory.
• Reporting. Someone will want a monthly rollup. Decide now whether it lives in the operational store or streams out to a warehouse.
• Deletion. Regulatory deletes cascade across entities. In a normalized schema that’s a transaction. In a denormalized single table it’s a fan-out you have to write and test yourself.
• Backfills. Every schema change becomes a migration job when no schema is enforced at the storage layer.

Write them down even if the answer is “we’ll handle it elsewhere.” A pattern you consciously exile to a warehouse is fine. One you forgot is a rewrite.

Where DynamoDB wins, and where it doesn’t

Give it its genuine case first, because it’s a strong one.

Where it wins

• Connection model. It’s an HTTPS API with SigV4 auth, so there’s no pool to exhaust. That’s why it pairs cleanly with Lambda. A relational database behind high Lambda concurrency needs RDS Proxy or a pooler, which is another component you operate.
• Predictable reads at any size. A query against a well-chosen partition key costs the same at ten thousand items or ten billion. Nothing in Postgres gives you that for free.
• Idle cost. On-demand mode bills per request unit consumed, so a table with no traffic costs storage and nothing else. Useful for tenant-per-table designs and low-traffic side services.
• Operational surface. No minor version upgrades, no vacuum, no failover window, no parameter groups to argue about.

The query API is narrow on purpose. Give it an exact partition key plus an optional sort key condition, and it returns an ordered slice of an item collection:

aws dynamodb query 
  --table-name AppData 
  --key-condition-expression "PK = :pk AND begins_with(SK, :sk)" 
  --expression-attribute-values '{":pk":{"S":"CUSTOMER#42"},":sk":{"S":"ORDER#"}}'

One customer’s orders, in sort order, in one request, no join. If that call shape covers most of your inventory, you’re looking at the right service.

Where it doesn’t

• Anything you didn’t model. New patterns mean new keys or a new index, and a new global secondary index means a backfill plus write capacity on every future write.
• Filtering is not querying. A FilterExpression runs after the read, so you pay capacity for every item examined and only save bandwidth. A filter that discards most of what it reads is a design smell.
• Aggregates. There is no GROUP BY and no COUNT(*) over a table. You maintain aggregates yourself, usually with DynamoDB Streams feeding a Lambda that updates a counter item, which means you own the correctness problem when that consumer fails.
• Hard physical limits. An item caps at 400 KB. A Query or Scan page returns at most 1 MB before you paginate. A single partition sustains roughly 3,000 read and 1,000 write units per second, so a hot key throttles while the table sits well under its quota.
• Index budget. Global secondary indexes default to twenty per table; local secondary indexes cap at five and can only be defined at table creation. You can’t index your way out of a bad key design forever.

Where RDS wins, and where it doesn’t

Where it wins

• Unknown future queries. The entire point. Joins, aggregates, window functions, ad hoc analysis, and a new index in one statement when something turns out slow.
• Constraints the database enforces. Foreign keys, uniqueness, check constraints, transactions across arbitrary tables. In DynamoDB each of those is application code you write and maintain.
• Extensions. PostGIS for geospatial, pgvector for embeddings, full-text search built in, all against the same rows in the same transaction.
• Portability. Postgres and MySQL run on RDS, in a container, or on a plain VPS from a provider like Contabo or InterServer, so migrating off is an export and an import. DynamoDB’s data model doesn’t port without rewriting your data access layer.
• Everyone already knows SQL. Underrated on a small team. Teaching four developers single-table design costs real review time.

Where it doesn’t

• Connections under serverless concurrency. Each Lambda execution environment opens its own connection, and the database refuses new ones once max_connections is reached. RDS Proxy multiplexes to fix that, but some operations pin a client to a backend connection and pinned connections aren’t reused. Watch DatabaseConnectionsCurrentlySessionPinned before trusting the pool.
• Instances are always on. A provisioned instance bills whether or not anyone queries it. Aurora Serverless v2 changes that with a minimum of zero capacity units on a supported engine version, but resuming from paused is slow enough that the first user after an idle period feels it. AWS documents resume as taking roughly fifteen seconds.
• Vertical scaling has a ceiling. Writes go to one primary and read replicas help reads only. Sharding is a project, not a setting.
• Maintenance is yours. Version upgrades, failover testing, long transactions blocking vacuum, connection storms on restart. Managed does not mean absent.

If you want a database that hibernates properly, it lives in the scaling configuration and the idle timeout is yours to set:

aws rds create-db-cluster 
  --db-cluster-identifier app-cluster 
  --engine aurora-postgresql 
  --serverless-v2-scaling-configuration 
      MinCapacity=0,MaxCapacity=4,SecondsUntilAutoPause=600 
  --manage-master-user-password

A minimum of zero only works on engine versions supporting automatic pause and resume, so check yours before planning a budget around it. If the cluster refuses the setting, that’s usually why.

A decision procedure for RDS vs DynamoDB

Run these in order against the inventory you wrote. The first clear answer wins.

1. Can you enumerate the access patterns, and are they stable? If the product is still moving and nobody can say what the admin tools will need, pick the store that tolerates being wrong. That’s RDS.
2. Does any pattern need a cross-entity aggregate on the hot path? A user-facing screen needing a count or sum across entities in under a second, with no way to precompute it, means RDS.
3. Is there a natural partition key with even distribution? Tenant ID, user ID, device ID. If traffic concentrates on one key, the per-partition ceiling finds you regardless of capacity mode. No good key means no DynamoDB.
4. What’s the concurrency shape of the compute tier? Thousands of short-lived Lambda invocations argue for DynamoDB. A few long-running containers with a warm pool remove the strongest argument against RDS.
5. Does the workload go quiet? Bursty and mostly idle favors on-demand DynamoDB or a scale-to-zero Aurora cluster. Steady traffic makes provisioned capacity or a right-sized instance cheaper.
6. Who maintains this in a year? If it’s one part-time developer, weight familiarity heavily. A design nobody on the team can debug is a liability whatever the benchmark said.

The cost model nobody actually models

The two bill on axes that don’t compare. RDS charges instance hours, storage, and depending on engine and storage type, I/O, busy or not. DynamoDB charges request units and storage, so an idle table is nearly free and a chatty one isn’t.

The number that matters is request units per user action, and almost nobody calculates it. Reads bill in 4 KB increments and writes in 1 KB increments, strongly consistent reads cost twice what eventually consistent ones do, and transactional operations double again. Every index you project into consumes write units on every write that touches it. A screen firing six queries plus an audit write can cost many times the naive estimate.

Work it out per action, multiply by real traffic, and sanity check the instance side with my AWS cost estimator before the decision hardens. AWS recommends on-demand as the default capacity mode for most workloads, but steady predictable traffic is still cheaper provisioned, and you can flip between them:

# which mode is this table on?
aws dynamodb describe-table --table-name AppData 
  --query "Table.BillingModeSummary.BillingMode"

# what is it actually consuming?
aws cloudwatch get-metric-statistics 
  --namespace AWS/DynamoDB 
  --metric-name ConsumedWriteCapacityUnits 
  --dimensions Name=TableName,Value=AppData 
  --statistics Sum --period 3600 
  --start-time $(date -u -d '1 day ago' +%Y-%m-%dT%H:%M:%SZ) 
  --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

Switching billing mode is rate limited, so treat it as a planned change rather than an incident-time knob.

Arguments that don’t survive contact

• “DynamoDB scales infinitely.” The service does. Your partition key might not. Uneven access concentrates load on one partition, and adaptive capacity only helps within limits.
• “Postgres can’t handle our scale.” Usually said before anyone has run EXPLAIN (ANALYZE, BUFFERS) on the slow query. A missing index and an N+1 in the ORM explain most claims of outgrowing relational.
• “We’ll add the indexes later.” True in Postgres, expensive in DynamoDB. A new global secondary index backfills across the whole table and then taxes every subsequent write.
• “Serverless database means no operations.” You trade instance operations for capacity and key-design operations. Throttling, hot partitions and stream consumer lag all need dashboards, exactly like a relational instance does.
• “We can just use both.” Sometimes right, often a way to avoid deciding. Two stores means two consistency models, two restore procedures, and a sync path that becomes the least reliable component you own.

How I’d decide

My default for a new application with an unfinished product definition is managed Postgres. Not because it’s better, but because being wrong about a relational schema costs an afternoon and being wrong about a key design costs a migration.

I’d reach for DynamoDB first when the workload is a small closed set of patterns keyed off one identifier, with high write volume, tolerance for eventual consistency, and concurrency that would flatten a connection pool. Session stores, telemetry ingestion, per-user feeds, idempotency keys, feature flags. It’s excellent at all of those.

The hybrid worth doing is narrow: relational as the system of record, DynamoDB for one high-volume pattern that joins nothing. The hybrid to avoid splits related entities across both stores and reconciles them in application code.

Whichever you land on, instrument it on day one. Throttled requests and consumed capacity on the DynamoDB side, connection counts and slow queries on the relational side, on a CloudWatch or Grafana Cloud dashboard someone actually opens. If you’re restricting item-level access with IAM condition keys such as dynamodb:LeadingKeys, run the policy through my IAM policy checker before it ships.

Frequently asked questions

Is DynamoDB always faster than RDS?

For a primary-key lookup at large scale its latency is more consistent, because that operation’s cost doesn’t grow with table size. For a query it wasn’t modeled for it can be far slower, because the fallback is a scan. Speed depends on the match between query and key design, not on the service.

Can I run analytics on DynamoDB?

Not directly, and you shouldn’t try. Export the table to S3 or stream changes out, then query with Athena or load a warehouse. Treat operational and analytical stores as separate systems.

What about Aurora Serverless as the middle ground?

It solves idle cost, not connections or write scaling. If you’re considering DynamoDB because of Lambda concurrency or single-primary write limits, Aurora Serverless doesn’t address that. If it’s because you’re paying for an idle dev database, it does.

How do I migrate from DynamoDB to RDS if I get it wrong?

Export to S3, reshape denormalized items into normalized tables, load, and dual-write during cutover. The data movement is routine. The hard part is that your application code assumed a key-value access shape everywhere, so the rewrite lands in the service layer, not the pipeline.

Is DynamoDB cheaper than RDS for a small application?

Usually yes when traffic is low and bursty, because on-demand charges per request against an idle table while an instance bills continuously. The advantage narrows as traffic steadies and reverses once throughput justifies provisioned capacity or a reserved instance.

Do I need RDS Proxy if I use Lambda with Postgres?

At meaningful concurrency, yes. Below that, a direct connection reused across invocations is fine, and the proxy adds cost plus a pinning failure mode. Add it when connection counts approach your limit, not preemptively in development.

Conclusion

The one thing worth remembering about RDS vs DynamoDB: you’re not choosing a performance profile, you’re choosing when to pay the modeling cost. DynamoDB takes it up front and pays you back in predictability. A relational database lets you defer it and charges interest later in query complexity.

Write the access pattern inventory. Be honest about the admin screens and the reporting nobody has asked for yet. If the list is short, stable and keyed on one identifier, DynamoDB will serve you for years. If it isn’t, take the relational database and spend the saved effort on indexes and connection handling.

Need a second opinion on the data store decision?

Cheap to review now, expensive to revisit later. Things I help with:

• Building the access pattern inventory with your team and pressure-testing it against the queries your roadmap implies
• Reviewing a DynamoDB key and index design before it ships, including partition key distribution and index write amplification
• Diagnosing throttling and hot partitions on an existing table, and whether the fix is a key change, a capacity change or a cache
• Sizing RDS or Aurora for a serverless compute tier, including connection handling, RDS Proxy configuration and pinning
• Modeling the cost of both options against your real request volume instead of a rule of thumb
• Planning a migration in either direction, with a dual-write cutover and a rollback that works

Send me your access pattern list, a slow query plan, or your throttling metrics and I’ll tell you what I’d do with it.

The post RDS vs DynamoDB: The Benchmark Isn’t the Decision appeared first on John Nessime.