Aurora Serverless v2 vs DynamoDB: The architectural showdown you can't ignore
DynamoDB or Aurora Serverless v2? The wrong choice can break your architecture. In this article, I break down a real-world scenario: 60 million transactions in 7 days, 2,500 req/s peak, RPO=0. Using 8 technical dimensions, load tests, and a contingency architecture, I show you: - When to choose horizontal scale (DynamoDB) - When to choose vertical elasticity (Aurora Serverless v2) - The exact trade-offs that separate senior from principal architects
Aurora Serverless v2 vs DynamoDB – The AWS Titan Clash (and why you need to care NOW!)
"The worst mistake isn't choosing the wrong tool for the right problem; it's stubbornly sticking with it. I've seen it happen, and the scars remain."
> A veteran architect, after a few sleepless nights.
> A veteran architect, after a few sleepless nights.
Table of Contents
- The scenario that separates the boys from the real architects
- Unveiling the internals: How each one truly works
- The gloves are off: Detailed technical showdown (8 heavy rounds)
- At the limit: What happens when the heat is really on
- Survival Plan B (if you insist on Aurora, with tears in your eyes)
- The right choice: When to use each one (no sugarcoating)
- Conclusion: Right tools for the right problems, not for hype
- Technical References (because data beats arguments)
- Acknowledgements
1. The scenario that separates the boys from the real architects {#1}
I was in a technical architecture review – one of those that keep you up at night – when a heavy challenge landed on the table:
- "60 million transactions in 7 days, but concentrated within registration windows (10:00 AM to 8:00 PM). A brutal peak of 10,000 requests per second (req/s). RPO zero. Maximum latency of 2 seconds (P99)."
The question that echoed in my head afterward was something like:
- "You chose DynamoDB. Great. But why not Aurora Serverless? What are the trade-offs? How would you set it up? And, most importantly, where would the system explode?"
This article is for the folks living the reality of architecture, who face these excruciating decisions every day. It's for those who need solid data, not guesswork, to defend their choices.
1.1 Scenario parameters (so we don't lose sight of the scale)
| Metric | Value | Technical implication (and a bit of a headache) |
|---|---|---|
| Total registrations | 60 million | Insane volume. We're talking "Big Data" for real. |
| Window | 7 days (with registrations from 10:00 AM to 8:00 PM) | 70 active hours in total. ~857k per active hour, ~238 req/s (average). But averages don't pay the bills. |
| Peak (first hours) | 10,000 req/s sustained! | This isn't just a peak; it's a tsunami of requests. The infrastructure capacity needs to be incredibly elastic and immediate. |
| Maximum latency | 2 seconds (P99) | Demanding, but for this volume, this is where things start getting serious. |
| RPO | Zero | Data loss? No way. This is "mission critical." |
| RTO | 15 minutes | Failures happen, but recovery must be swift. |
Real-world context, as it is: I spent 16 years at FIES in CAIXA, and the registration system experienced peaks exactly like this. Guess what? Cloud didn't exist then. I learned the hard way, in the trenches, what works and what breaks a system under pressure. That's the experience I'm sharing here.
2. Unveiling the internals: How each one truly works {#2}
Before hammering down a decision, we need to know what's under the hood. Ignoring this is asking for a surprise in the middle of the night.
2.1 DynamoDB: Built to scale like the universe
DynamoDB wasn't "adapted" to scale; it was born to do so. Its internal architecture is an engineering masterpiece designed to distribute the load.
| Component | How it shows off |
|---|---|
| Partitioning | Your data is automatically spread across partitions (each 10 GB). This is the secret to its scalability. |
| Throughput | Measured in WCUs (1 KB/s write) and RCUs (4 KB/s read) per partition. It's what you pay to move data. |
| Scaling | It transparently and automatically adds partitions when demand increases. Magic? No, pure engineering. |
| Consistency | Eventual (default, faster, and cheaper) or Strong (double the cost, but immediate guarantee). |
| Global Tables | Multi-region replication with "last writer wins" conflict resolution. Your data close to your users, globally. |
Where it has (almost) no limit: Each partition supports 1,000 WCU or 3,000 RCU. With a well-designed key, the limit is virtually the sky.
2.2 Aurora Serverless v2: The "elastic" with a glass ceiling
Aurora Serverless v2 is a different beast from v1 (the one that hibernated and hit you with a cold start). V2 is much better, but it still has its quirks:
| Feature | Important detail |
|---|---|
| Scaling unit | ACU (Aurora Capacity Unit) – think of it as a resource bundle: 1 ACU is roughly 2 GB RAM + equivalent vCPU. |
| Scaling range | It can go from 0.5 ACU up to a maximum of 128 ACU (which is about ~64 vCPUs). |
| Scaling time | Much faster than v1, in the order of seconds. But it's still time. |
| Auto-pause | It's optional in v2. Don't expect the same cost savings as v1 if you don't configure it. |
| Cold start | Yes, it still exists. For the first connection after inactivity, expect 3-5 seconds. At peak, this kills you. |
Where it hits the ceiling: 128 ACU is the limit. If your application needs more horsepower, like in our scenario of 10,000 req/s, it simply will not scale. It will hit the hardware limit and break. Then you'll have to do manual sharding (multiple clusters), and goodbye to the simplicity of "serverless."
3. The gloves are off: Detailed technical showdown (8 heavy rounds) {#3}
Get ready to see where the rubber meets the road.
| Criterion | DynamoDB | Aurora Serverless v2 | Winner | Justification from someone who's seen the circus burn |
|---|---|---|---|---|
| Scaling Model | Horizontal (automatic shards, scaling DNA) | Vertical (0.5 to 128 ACU, but with a ceiling) | 🏆 DynamoDB | For a 10,000 req/s peak, horizontal scaling isn't just preferable; it's the only realistic option for survival. |
| Theoretical Max Limit | Unlimited (with good sharding design) | ~64 vCPUs (128 ACU) | 🏆 DynamoDB | With 10,000 req/s, 128 ACU will be an immediate and catastrophic bottleneck. Simply unfeasible for the volume. |
| Consistent P99 Latency | 5-10ms (global, predictable as a Swiss watch) | 10-50ms (variable and unpredictable under heavy load) | 🏆 DynamoDB | Latency is a promise. A 2-second SLA demands predictability, and DynamoDB delivers with ease. At 10,000 req/s, any minimal variation from Aurora becomes a massive problem. |
| Cold Start | ❌ Does not exist. Ever. | ✅ Yes (3-5s of torture) | 🏆 DynamoDB | A 3-5s cold start at 10,000 req/s means 30,000 to 50,000 requests will fail or time out. Impractical and unacceptable. |
| Connection Pooling | ❌ Unnecessary, it handles it | ✅ Mandatory (via RDS Proxy) | 🏆 DynamoDB | Aurora forces you to use an RDS Proxy (more cost, another point of failure, more complexity). |
| Data Modeling | Single table design (steep learning curve, requires a mindset shift) | Standard SQL (low learning curve, familiar) | 🏆 Aurora | If your team only breathes SQL, Aurora is easier to start with. But that doesn't mean it's the best long-term choice or for this scenario. |
| ACID Transactions | Limited (Transactions API, up to 25 items) | ✅ Full (SQL transactions, robust) | 🏆 Aurora | For complex business logic requiring multi-item transactions and impeccable integrity, SQL is unbeatable. |
| Complex Joins | ❌ Impractical (requires brutal denormalization) | ✅ Native (SQL joins, as you know them) | 🏆 Aurora | If you rely on frequent joins, DynamoDB will give you nightmares. |
| Cost for Extreme Peak | Low (pay only for WCUs/RCUs used) | High (you need to provision an ACU buffer, even if not always used) | 🏆 DynamoDB | To handle 10,000 req/s (even for a few minutes), Aurora would need massive ACUs, likely not even achievable with a single cluster, resulting in prohibitive cost and instability. |
| Operational Management | Zero (truly serverless, literally) | RDS Proxy + pooling + tuning + ACU monitoring | 🏆 DynamoDB | Fewer "to-dos," less sweat in the middle of the night. Aurora v2 still requires you to "operate" the database. |
Final Score: DynamoDB 7 x 3 Aurora Serverless v2. The result is even clearer for our extreme scenario.
4. At the limit: What happens when the heat is really on {#4}
Let's imagine the front lines, with 10,000 req/s knocking at the door.
4.1 DynamoDB
| Scenario | Real-world behavior |
|---|---|
| Peak of 10,000 req/s | This translates to 10,000 WCU (if each item is <1 KB). It absorbs it as if it were easy, provided the design is sound. |
| Adaptive capacity | Partitions scale automatically and transparently. You don't even see it happen; it just works. |
| Hot partition | This is the ONLY real risk: If your partition key is poorly distributed, a partition can get "hot" and experience throttling. But this is solved by good design, not by more infrastructure. |
| Cost | The cost will be higher than for 2,500 req/s, but still predictable and directly tied to consumption. |
Main risk: Poor partition key design. Fix that, and DynamoDB is an unshakeable rock.
4.2 Aurora Serverless v2
| Scenario | Real-world behavior (and your nightmares) |
|---|---|
| Peak of 10,000 req/s | Aurora will attempt to scale ACUs up to the 128 limit. But this capacity will not be sufficient to sustain 10,000 req/s. |
| Physical limit | 128 ACU (~64 vCPUs) – you are ridiculously below the necessary capacity for 10,000 req/s. The database will saturate and fail. |
| Cold start | The first connection after an idle period will take 3-5 seconds. At a peak of 10,000 req/s, this means tens of thousands of users will experience timeouts. Unacceptable and catastrophic. |
| Connection pool | RDS Proxy is mandatory, adding about R$ 0.10/hour in cost and another point of failure to worry about, which will also need to scale for 10,000 req/s. |
| Cost | If by some miracle it tried to handle it, the cost would be astronomical, and instability would be your constant companion. |
Main risks: Insurmountable scaling ceiling, the dreaded cold start right at crunch time, and the complexity and cost of RDS Proxy. For 10,000 req/s, Aurora Serverless v2 is not a viable option.
5. Survival Plan B (if you insist on Aurora, with tears in your eyes) {#5}
If for any reason, political, technical, or divine, you are forced to use Aurora Serverless v2 for a scenario like this, here is the minimum configuration to avoid a collapse. But frankly, for 10,000 req/s, this "contingency" is more a recipe for disaster:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# Contingency Architecture for Aurora Serverless v2 (10,000 req/s and lots of coffee):
1. Aurora Serverless v2:
- min ACU: 64 (to *try* to delay cold start and have some initial performance)
- max ACU: 128 (the ceiling, which will be **totally insufficient** for 10,000 req/s. Expect failures.)
- Make sure it's v2, not v1, for heaven's sake!
2. RDS Proxy (mandatory and well-configured):
- Min connections: 500 (to have a reasonable buffer)
- Max connections: 2000 (or the maximum it can support, and pray!)
- Idle client timeout: 300s (to avoid dropping active connections)
3. Write decoupling queue (your best friend, now an essential lifeline):
- SQS (Standard or FIFO, depending on order needs) in front of ALL writes to the database. ALWAYS.
- Dead Letter Queue configured, so you know what went wrong and don't lose data.
- Lambdas consuming from the queue (Node.js or Python, for faster cold start).
- **This only buffers the peak for the database; it does not solve the lack of capacity.**
4. Read cache (to take *maximum* pressure off the database):
- ElastiCache (Redis or Memcached) for all frequent queries.
- TTL of 5-15 minutes (for data that doesn't need to be *real-time*).
- **This will be your primary line of defense, but not for writes.**
5. Failover strategy (because failures will happen):
- Read Replica in ANOTHER AZ (Availability Zone).
- Prepare for manual failover (RTO of about 5-10 minutes, even then).
- **Consider Aurora Global Database** for disaster recovery, but it is not serverless!
6. Load test (and may God help you, you'll need it):
- Use AWS Distributed Load Testing.
- Simulate at least 3x the expected peak (i.e., **30,000 req/s**). This will demonstrate Aurora's inevitable failure.Main risks: Scale ceiling, peak-time cold start, RDS Proxy requirement.
6. When to use each (decision matrix)
✅ Use DynamoDB when:
| Scenario | Why |
|---|---|
| Extreme horizontal scale (>1,000 req/s sustained) | Aurora's ceiling may be reached |
| Ultra-low consistent latency (<10ms) | Aurora has variability |
| Zero operations | DynamoDB is truly serverless |
| Non-relational or denormalized data | Single-table modeling is natural |
| Cost is a priority | On-demand pays only for what you use |
✅ Use Aurora Serverless v2 when:
| Scenario | Why |
|---|---|
| Intermittent workloads (dev/test, overnight batch) | Scales to nearly zero when idle |
| Complex joins are frequent | SQL is far more expressive |
| Lift-and-shift migration of small SQL databases | PostgreSQL/MySQL compatibility |
| Team isn't ready to learn DynamoDB | DynamoDB learning curve is steep |
| Rapid prototyping (as I did with my GenAI chatbot) | Start with SQL, scale later |
⚠️ Avoid Aurora Serverless v2 when:
| Scenario | Why |
|---|---|
| 24/7 constant workload | Provisioned instances are cheaper |
| Extreme peaks >500 req/s | Cold start + scale ceiling are problems |
| RPO = 0 com failover cross-region | Aurora Global DB is better, but not serverless |
7. Conclusion: right tools for the right problems
Let's be honest: Aurora Serverless v2 is a fantastic technology. But, like any tool, it has its place. The most common mistake I see architects make is treating "serverless" as the "silver bullet" that solves everything. And it's not!
| Ferramenta | Nasceu para... |
|---|---|
| DynamoDB | Horizontal scale, predictable latency, zero operations |
| Aurora Serverless v2 | Intermittent workloads, SQL compatibility, smooth migrations |
Knowing the difference between these two powerhouses, understanding their limits, and defending your choice with data and experience – that's what truly separates a senior architect from a principal architect. And that's what will help you sleep soundly on the night of the next peak.
8. Technical references (because data beats arguments)
| Reference | Description | link |
|---|---|---|
| AWS re:Invent 2023 - Scaling the Brazilian Elections | Architecture serving 156M Brazilians with 1.5M req/s, 90 TB data, zero incidents | Watch on YouTube |
| Aurora Serverless v2 – What's new | Official AWS documentation | Read More |
| DynamoDB single table design – Best practices | How to model data for horizontal scale | Read More |
| DynamoDB vs Aurora Serverless: Cost comparison | Cost analysis for peak workloads | Read More |
Liked this article? Share it with your network. Disagree? Tag me in the comments, technical discussion is what makes us grow.
Acknowledgements {#9}
This article was inspired by a conversation with Vinicius Soares Batista (Sr. Solutions Architect at AWS). During our technical chat.
Thanks for the insight, Vinicius.
#AWS #Serverless #DynamoDB #Aurora #Architecture #CloudComputing #PrincipalArchitect
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article