Amazon DynamoDB - AWS NoSQL Database That Actually Scales

DynamoDB is Amazon's NoSQL database that handles all the server shit for you. No patching, no version upgrades, no 2am maintenance windows. Sounds too good to be true? It mostly isn't, but there are gotchas that'll bite you in the ass if you're not careful.

The Serverless Reality

The serverless part is real - you don't manage any servers. When your app isn't getting traffic, you pay almost nothing. When traffic spikes, it scales automatically. I've seen it handle massive traffic surges during Black Friday sales without breaking a sweat - we're talking 10x normal load with zero intervention.

But "serverless" doesn't mean "zero work." You still need to design your access patterns correctly from day one. Get this wrong, and you'll either pay through the nose or your queries will be painfully slow. There's no going back and adding an index like you would with PostgreSQL - that's just not how DynamoDB works.

Performance: Fast When Done Right

DynamoDB is genuinely fast - usually 1-5ms for simple key lookups. The performance stays consistent whether you're doing 100 requests or 100,000 requests per second. This happens because it partitions your data across multiple machines automatically.

Here's the catch: that performance only applies to simple key-value lookups. Try to do complex queries and you're fucked. No JOINs, no complex WHERE clauses, no ad-hoc queries. If you didn't plan for a specific query pattern upfront, you'll need to scan the entire table - which is both slow and expensive as hell. I've seen developers try to run analytics queries and burn through $500 in a morning.

The AWS Integration Trap

DynamoDB works amazingly well with other AWS services like Lambda and API Gateway. You can build entire serverless applications without thinking about servers. DynamoDB Streams let you trigger Lambda functions when data changes, which is actually pretty fucking cool for real-time processing.

But here's the thing - this tight integration means you're locked into AWS like a hostage. Moving off DynamoDB later is a massive pain because your application architecture becomes tied to AWS-specific patterns. I've seen companies spend 8+ months trying to migrate away, rewriting half their codebase in the process. One startup I worked with had to raise another funding round just to afford the migration costs.

Query Patterns Are Everything

DynamoDB forces you to think about your access patterns upfront. You design your table structure around how you'll query the data, not around the data itself. This feels backwards if you're coming from SQL databases, and it is. But it's also what makes DynamoDB scale.

The partition key determines which physical storage partition your data lives on. Get this wrong and you'll have hot partitions that throttle even when you haven't hit your table limits. This is the #1 mistake I see developers make - they use something like userId as a partition key, then wonder why their app slows to a crawl when their top user gets active.

Think of it this way: DynamoDB takes your partition key, runs it through a hash function, and that determines which physical machine your data lives on. If all your queries use the same partition key value, all your traffic hits one machine. That machine gets overwhelmed and throttles your requests, even if the other 99 machines are sitting idle.

The recent PartiQL support helps a bit - you can write SQL-like queries - but it's still limited compared to a real SQL database. And transactions work, but they're limited to 100 items max and cost more than regular operations. I learned this the hard way when a transaction-heavy feature pushed our AWS bill from $200 to $800 per month.

DynamoDB pricing can be surprisingly cheap or eye-wateringly expensive depending on your usage patterns. AWS cut prices by 50% in late 2024, which helped, but there are still ways to get a nasty billing surprise that'll make you want to throw your laptop out the window.

On-Demand: Great Until It Isn't

On-demand pricing is brilliant for unpredictable workloads. You pay $0.25 per million read requests and $1.25 per million writes. For most small to medium apps, this works out to practically nothing - like $5-50 per month.

But here's where it can bite you in the ass: if you have poor access patterns that require scanning large amounts of data, your bill can explode overnight. I've seen companies get $10,000+ AWS bills because someone accidentally ran a full table scan in production. The beauty of "pay per request" becomes a fucking nightmare when you're making millions of inefficient requests.

Provisioned Capacity: Cheaper but Predictable

If your traffic patterns are predictable, provisioned capacity can save you 60-80%. You commit to a certain throughput level and get discounted rates. The challenge is accurate forecasting - provision too little and you get throttled during traffic spikes, provision too much and you waste money.

Reserved capacity gives even bigger discounts (up to 77% for 3-year commitments), but you're essentially betting on your future usage patterns. Get it wrong and you're stuck paying for capacity you don't need. I watched one company commit to $50K/year in reserved capacity, then their product pivot meant they only used 20% of it.

Storage Costs Add Up

The base storage cost seems cheap at $0.25 per GB per month, but it adds up faster than you think. Global Secondary Indexes double your storage costs because they replicate the data. And if you enable point-in-time recovery, that's another cost on top.

The Standard-IA storage class gives you 60% cheaper storage for infrequently accessed data, but there are access charges that can offset the savings if you access the data more than expected. One client of mine thought they'd save money by moving old user data to IA class, then their compliance team needed to access it weekly for audits. The access charges ended up costing more than standard storage.

Global Tables: Expensive but Necessary

Multi-region replication roughly doubles your costs because you're paying for storage and throughput in each region. Cross-region replication also has bandwidth costs. But if you need global low latency, there's no way around it.

Here's how Global Tables work: you write to your local region and it replicates to others automatically through DynamoDB Streams. Each region has a complete copy of your table, so users get fast local reads. But eventual consistency means there's usually a 1-2 second delay before all regions see your writes.

The tricky part is conflict resolution. If two regions get conflicting writes to the same item simultaneously, DynamoDB uses "last writer wins" based on timestamps. This works for most use cases, but can cause data loss if you need strict consistency. I've seen e-commerce sites lose inventory updates during flash sales because of this.

The Hidden Costs

Watch out for these cost surprises that'll sneak up on you:

• Global Secondary Indexes cost the same as your base table
• Point-in-time recovery has storage costs that compound monthly
• DynamoDB Streams cost $0.02 per 100,000 reads (adds up with high-volume apps)
• Data transfer between regions isn't free
• Backup storage costs accumulate over time

The key is monitoring your billing closely, especially in the first few months after deployment. I recommend setting up billing alerts at multiple thresholds - $100, $500, $1000 - because DynamoDB costs can spiral fast if something goes wrong.