Choosing a key value store on AWS

DynamoDB is a managed database for workloads that need predictable access at a large scale. It stores items under keys and lets each item carry its own set of attributes. That makes it a different tool from a relational database, not a replacement for every relational database. The decision should begin with the shape of the queries, not with the popularity of the service.

The item model

An item is a collection of named values identified by a primary key. The key can be a simple partition key or a composite of a partition key and a sort key. The partition key determines how data is distributed. The sort key makes it possible to retrieve a range of related items together. A well chosen pair can answer several product questions with one request.

Because items do not share a rigid schema, the application must be deliberate about optional fields and types. A flexible model is not permission to be vague. It is a reason to document the access patterns and validate the data at the boundary where it enters the system.

Scaling is a property of the workload

DynamoDB scales by distributing work across partitions. The service handles much of the operational burden, but the data model still decides whether traffic is spread evenly. A hot key can turn a globally scalable table into a bottleneck. A good design avoids concentrating too much traffic on one value and considers how the key behaves as the product grows.

Capacity choices also shape the bill. On demand capacity is convenient when traffic is unpredictable. Provisioned capacity can be more economical when the workload is steady. The right answer changes with the product, so the decision should be revisited rather than set once and forgotten.

When a cache belongs in front

DynamoDB Accelerator adds an in memory cache for reads that need even lower latency. It is useful when the same popular items are requested repeatedly and the access pattern can tolerate cached results. It is not a fix for a poor key design or a query that asks for too much data. Add a cache after measuring the read path, not before.

Backups, point in time recovery, and access control are part of the design as well. The managed service gives you the mechanisms, but the team still owns the policy. How long should data be recoverable? Who can read it? Which application roles need write access? Those questions belong in the same conversation as the table design.

Notebook note: DynamoDB is at its best when the access patterns are known and stable. If the product needs many unplanned joins, a relational service may be the more honest choice.