DynamoDB

DynamoDB is AWS’s fully managed NoSQL database, a serverless key-value and document store built for single-digit-millisecond latency at any scale. It is the database AWS reaches for in its own highest-traffic systems, and it suits teams who need predictable performance under load without running servers themselves.

Where it fits

DynamoDB targets workloads with known, high-volume access patterns: session stores, shopping carts, user profiles, event sourcing, and time-series data where read and write paths are predictable. It scales horizontally without manual sharding, replicates across regions with global tables, and integrates tightly with the rest of AWS through Lambda triggers, DynamoDB Streams, and IAM.

The catch is design discipline. DynamoDB is access-pattern-first: you model tables around the exact queries your application runs, not around normalized entities. There are no joins and no ad hoc queries. Teams that internalize that constraint get near-flat latency at any scale. Teams that treat it like a relational store fight the model and overpay.

Pricing in practice

DynamoDB bills two ways. On-demand capacity charges per request: roughly $0.125 per million eventually consistent reads and $0.625 per million standard writes (Standard table class), with no capacity to provision. Provisioned capacity reserves read and write capacity units billed per hour, cheaper for steady, predictable traffic, with auto-scaling available. Storage runs $0.25 per GB-month on Standard, $0.10 on Standard-Infrequent Access. The free tier covers 25 GB of storage plus 25 read and 25 write capacity units per month.

The cost-modeling discipline matters. Reads and writes are metered in 4 KB and 1 KB units respectively, strongly consistent reads cost double eventually consistent ones, and transactions double again. A poorly modeled table that scatters small writes can cost far more than the row count suggests. Estimate request volume and item sizes before committing to a capacity mode.

How it compares

• 

  MongoDB, A document store with rich ad hoc queries, secondary indexes, and aggregation. Pick when query flexibility matters more than raw managed scale, or when you want a database that runs anywhere.

• 

  PostgreSQL, A relational database with joins, transactions, and SQL. Pick when access patterns evolve, relationships are central, or you need ad hoc analytics rather than fixed high-scale lookups.

• 

  Convex, A reactive backend with a typed query layer and live updates. Pick for app developers who want a managed data layer with less ceremony, not raw infrastructure-grade scale.