TopolearnKnowing its strengths and limits up front tells you when DynamoDB is the right store and how differently you must think about data.
DynamoDB is AWS's serverless NoSQL database. You create a table, write items (records, like rows) into it, and read them back by key with single-digit-millisecond latency, whether the table holds a megabyte or a hundred terabytes. There are no instances to size, patch or fail over: AWS replicates every table across three Availability Zones and scales it for you.
Each item is a set of attributes (name/value pairs). Apart from the key attributes, items in one table can have completely different attributes; there is no fixed schema. An item can be up to 400 KB.
The trade-off is in querying. There are no joins, no ad-hoc SQL across the whole table and no aggregations. Efficient reads always go through a key: fetch one item by its primary key, or query a group of items that share a partition key. Scanning the whole table works but is slow and expensive.
So DynamoDB fits workloads with known access patterns at high or spiky scale: user profiles, shopping carts, sessions, game state, device data, serverless APIs. It fits poorly when you need flexible analytical queries; you would export the data to S3 and query it with Athena, or use a relational database instead.
You talk to it with the AWS SDKs (in Python, boto3), the AWS CLI or the console.
Remember
- Tables hold schemaless items; only the key attributes are required
- Fast reads always go through the primary key or an index
- No joins or ad-hoc queries: design for known access patterns
- Fully managed, multi-AZ and serverless
Watch out for
- Choosing DynamoDB for a reporting workload that needs arbitrary filters and joins.