Amazon DynamoDB

What managed actually removes

Most database decisions carry a hidden second decision about who runs it. Someone sizes the instance, applies patches, configures replication, monitors disk and responds when a disk fails at an inconvenient hour.

DynamoDB removes that decision. AWS operates the infrastructure. There is no instance to choose, nothing to patch and no failover to configure.

What remains is a table, a key and a capacity setting. That is a genuinely smaller surface, and it is the main reason the service is chosen.

The trade is that the things AWS decides are no longer available to be tuned, and the data model is considerably more restrictive than a relational database.

Items, tables and keys

A table holds items. An item is a collection of attributes, and items in a table do not have to share the same attributes beyond the key.

Every table has a partition key. Its value decides which partition an item is stored in, and partitions are how the service spreads data across its own infrastructure.

A table may also have a sort key. Items sharing a partition key are then ordered by it, which allows querying a range within a partition.

This is the whole model, and everything about using DynamoDB well follows from it.

Why the key is the design

In a relational database, tables are designed around the entities and queries are written afterwards. Indexes are added later when something is slow.

Here the key is decided first, because it determines what is possible.

Retrieving an item by its full key is a direct lookup. Querying a range of sort key values within one partition key is efficient. Anything else requires either a secondary index or a scan.

A scan reads the entire table. On a small table this is unremarkable. On a large one it is slow and expensive, and it is the usual explanation when DynamoDB costs more than expected.

The key also governs distribution. If most traffic uses one partition key value, that partition becomes a bottleneck while others sit idle. Keys are chosen to spread traffic as well as to support the queries.

Indexes for other access patterns

Secondary indexes allow querying by attributes other than the table key.

A local secondary index provides a different sort key within the same partition key. A global secondary index provides an entirely different partition and sort key, effectively a second view of the data.

Global secondary indexes are updated asynchronously, so an index may briefly lag the table. Applications reading immediately after a write need to account for that.

Indexes consume storage and throughput of their own, so adding them for every conceivable query is not a free solution to the modelling constraints.

No joins

There are no joins. Data is fetched by key from one table.

Requirements that would be a join elsewhere are handled by shaping the data so that what is needed arrives together. This often means storing related items under a shared partition key, or duplicating information across items.

To anyone accustomed to normalised design this feels wrong. It is the intended approach for a store built around key access, and it is the same reasoning that applies in other distributed key based databases.

The practical consequence is that access patterns must be known before the table is designed. A new query pattern discovered later may require a new index or a restructuring of the data, which is a real constraint on how the system evolves.

Paying for capacity

Two modes exist.

Provisioned capacity means stating the throughput expected and being charged for that reservation. It suits steady, predictable load.

On demand means the service handles requests as they arrive and charges per request. It suits load that is uneven or unknown, and it removes the need to forecast.

The official documentation defines how reads and writes are measured, which matters because the units are not simply requests and depend on item size and consistency setting.

Streams

Changes to items can be published as an ordered stream. Other services read it and react.

This is how work is triggered by data changes without the application publishing events itself. Updating a search index, sending a notification or maintaining a summary are common uses.

Who uses it

DynamoDB is used by teams building on AWS, particularly where applications scale up and down sharply or where there is no wish to operate database infrastructure. It appears frequently behind serverless applications, since it needs no connection pooling or instance sizing.

Points to consider

It is an AWS service and runs only there. That is a deliberate commitment and it should be a conscious one, since moving the data model to another database is not a straightforward exercise.

The data model is restrictive by design. Applications whose queries are varied and not known in advance are usually better served by a relational database.

Cost depends on access patterns rather than only on data volume. Scans, over provisioned throughput and unnecessary indexes are the common sources of unexpected charges, and all three come back to how the key was chosen.

Getting started

The official documentation covers the data model, key design, indexes, capacity modes and streams. The sections on modelling access patterns are the ones to read before creating a table, because the key decision is difficult to revisit once data exists.