DynamoDB

DynamoDB is AWS's fully managed NoSQL database. It delivers single-digit millisecond response times at any scale — from a handful of requests per day to millions per second — with no servers to provision, patch, or manage.

What Kind of Database Is It?

DynamoDB is a key-value and document database. You store items (similar to rows) identified by a primary key, and each item can hold any set of attributes (similar to columns, but flexible — not every item needs the same attributes). It is not a relational database: there are no JOINs, no foreign keys, and no SQL. If you need to query data in complex, unpredictable ways, DynamoDB is probably the wrong choice. If you need fast, predictable access to data by a known key, it excels.

Why Teams Choose DynamoDB

The main reasons are scale and simplicity of operations. A relational database has a maximum throughput ceiling (however much the largest single server can handle). DynamoDB is distributed — it partitions your data across many servers automatically, so it scales horizontally without any work on your part. You set a throughput target (or use on-demand mode and let AWS scale for you), and DynamoDB meets it.

There's also nothing to manage. No patching, no backups to schedule (point-in- time recovery is a checkbox), no replica setup. AWS handles availability across three Availability Zones automatically.

Core Concepts

Table — the container for your data. Unlike SQL tables, DynamoDB tables are schemaless except for the primary key.

Primary key — every item in a table must have a unique primary key. It can be a single partition key (a simple key lookup), or a composite partition key + sort key (which lets you store multiple related items under the same partition and query ranges of sort key values).

Partition key — DynamoDB uses this value to determine which internal partition (server) stores the item. Choose it carefully: if all requests hit the same partition key value, you get a "hot partition" that becomes a bottleneck.

Indexes — DynamoDB supports Global Secondary Indexes (GSI) and Local Secondary Indexes (LSI) to query data by attributes other than the primary key. Think of them as pre-computed alternative views of your table.

DynamoDB is a valet parking garage. Hand over your ticket (the key) and your car appears in milliseconds — whether the garage holds ten cars or ten million. But ask the valet to "find all the red cars" (a query it wasn't designed for) and he has to walk every floor. That's why access patterns come first: you design the tickets before you park the cars.

Access Patterns First

DynamoDB requires you to know your access patterns upfront and design your table around them. This is different from SQL, where you normalize the schema and write whatever queries you need later. Spend time on your data model before you create the table — changing primary keys later requires migrating data.