DynamoDB

What is DynamoDB?

Amazon DynamoDB is a fully-managed NoSQL key-value and document database delivering consistent single-digit-millisecond latency at effectively unlimited scale, with zero servers to manage. Its serverless model (no instances, autoscaling or on-demand capacity) and predictable performance made it a default for high-scale AWS applications. But that performance is conditional: DynamoDB is fast only if you model your data around its access patterns, and it punishes relational thinking harder than almost any database.

Access-pattern-first, or it fails

Like Cassandra, DynamoDB requires you to know your queries before you design your tables, because it retrieves efficiently only by partition key (and optionally sort key). There are no joins, no arbitrary WHERE, and scans across the whole table are slow and expensive. The advanced DynamoDB pattern — single-table design, where multiple entity types share one table with carefully overloaded keys and Global Secondary Indexes — is genuinely powerful and genuinely hard, and it exists precisely because DynamoDB’s query model is so constrained. The near-universal failure: teams model DynamoDB like a relational database, then either scan constantly (slow, costly) or bolt on GSIs to compensate until the design is a tangle. If you can’t enumerate your access patterns up front, DynamoDB is the wrong choice.

The cost model and its traps

DynamoDB bills on throughput — read and write capacity units — in two modes: provisioned (set capacity, cheaper for steady predictable load, throttles if exceeded) and on-demand (pay per request, brilliant for spiky/unknown traffic, pricier per unit). The cost traps are specific: hot partition keys concentrate traffic and throttle (a poorly-chosen key that funnels load to one partition), table scans burn capacity reading data you discard, and unbounded GSIs multiply write costs. Well-modeled DynamoDB is astonishingly cheap and fast; badly-modeled DynamoDB is a throttling, expensive mess — the outcome is decided at design time.

What people get wrong

• Relational modeling — expecting joins and ad-hoc queries, then scanning the table to compensate.
• Hot partition keys: a key that concentrates traffic throttles the whole workload while capacity sits unused elsewhere.
• Scans as normal usage — they’re a last resort; every access path should hit a key, not filter the table.

Primary source: Amazon DynamoDB documentation