What Is DynamoDB? AWS NoSQL Database Explained

Simple explanation

DynamoDB is a strong choice for session storage, shopping carts, gaming leaderboards, IoT telemetry, and any workload that hits the same key-based lookups at very high speed. It is a poor fit for reporting, analytics, or applications with flexible and evolving query requirements.

How DynamoDB works

DynamoDB stores data in tables. Each table holds items (a single record), and each item has attributes (name-value pairs, similar to fields). Unlike a relational database, you do not define a schema for every attribute upfront. You only define the key attributes; the rest can vary per item.

Every item is identified by a primary key, which comes in two forms:

• Partition key only: A single attribute that uniquely identifies each item. Good when every lookup is by a single ID, such as userId in a users table.
• Partition key + sort key: A composite key where items share a partition key but differ on the sort key. This stores related items together and lets you query them as a group or in order.

A concrete example: An e-commerce order history table might use userId as the partition key and orderId as the sort key. All orders for a given user live in the same partition. You can retrieve every order for a user in a single query, or narrow it down to orders placed after a certain date using the sort key.

This design makes DynamoDB fast. It also means your access patterns need to be decided before you design your table. If a query your application needs cannot be answered with a key lookup or index, you are left doing a full table scan, which is slow and expensive. For a deep look at data modelling, see the DynamoDB Data Model guide.

What DynamoDB is good at

High throughput. DynamoDB handles millions of reads and writes per second. Storage and throughput scale independently, horizontally, and automatically. You do not manage sharding, replication, or failover.

Predictable low latency. Responses return in single-digit milliseconds at any scale. This consistency comes from the design constraint: queries are always by primary key or index, never ad hoc table scans.

Flexible item structure. Each item can have a different set of attributes. You only define the key attributes upfront. This works well for heterogeneous objects where not every record shares the same fields, such as a product catalogue where clothing has size and colour but electronics have wattage and voltage.

Global replication. DynamoDB Global Tables replicate data across multiple AWS regions with active-active writes. Users in different regions can read and write to the same logical table with low latency.

When to use DynamoDB

DynamoDB fits workloads where:

• Access patterns are known and predictable. You know exactly how your application will look up data before you build the schema.
• Throughput and scale matter more than query flexibility. You need consistent performance at high request volume.
• Low operational overhead is a priority. No database servers to patch, size, or manage.

Specific workloads where DynamoDB excels:

• User sessions: store and retrieve session state by session ID at high speed
• Shopping carts: read and update cart contents by user ID
• Gaming leaderboards: rank players by score using a Global Secondary Index
• IoT telemetry: write sensor readings at high frequency, retrieve by device ID and timestamp
• High-scale APIs with predictable access patterns: user profiles, feature flags, configuration stores
• Event-driven architectures: DynamoDB Streams can trigger AWS Lambda functions when items change, making it a natural fit for event-driven systems

When not to use DynamoDB

Avoid DynamoDB when:

• You need ad hoc SQL queries. If your team needs to filter, group, or aggregate data in flexible ways, DynamoDB forces a full table scan or requires you to build those patterns into your schema ahead of time.
• Your data is relational with complex joins. Orders that join with customers, products, suppliers, and invoices belong in a relational database.
• Your schema has many-to-many relationships. These patterns require workarounds in DynamoDB that quickly become brittle.
• You are building reporting or analytics features. DynamoDB is not optimised for aggregations, GROUP BY, or exploratory queries. Export to S3 or use Amazon Redshift for analytics.
• Your query patterns are still unknown. Start with RDS if you are still working out how the application will access data. Migrating to DynamoDB later is easier than redesigning a DynamoDB schema in production.

Core concepts

DynamoDB uses different terminology from relational databases:

Items can be up to 400 KB and contain nested maps, lists, and sets. This is much closer to a JSON document than a SQL row. For a full walkthrough of how to model data with these building blocks, see DynamoDB Data Model.

Partition key design

The partition key is the most consequential design decision in a DynamoDB table. DynamoDB uses it to distribute data across internal storage nodes. A good partition key spreads traffic evenly. A bad one creates hot partitions: one node receiving most of the reads and writes while the rest sit idle.

The rule: your partition key should have high cardinality (many distinct values) and traffic should distribute roughly evenly across those values. If you cannot find a natural high-cardinality attribute, consider appending a shard suffix to an existing one.

Capacity modes: On-Demand vs Provisioned

On-Demand mode handles any volume of traffic automatically. You pay per request (per read unit and write unit consumed) with no capacity to configure. Traffic can spike from zero to millions of requests per second without any pre-planning.

Best for: new applications with unknown traffic patterns, dev/test environments, and workloads with large spikes followed by quiet periods.

Provisioned mode with Auto Scaling lets you set a target read and write throughput in capacity units per second. Auto Scaling adjusts capacity within the bounds you define based on actual usage. This costs less per request than On-Demand at sustained high traffic.

Best for: stable, predictable workloads at scale where you want to control cost.

Read consistency

DynamoDB offers two consistency options:

Eventually consistent reads are the default. Reads may not reflect the very latest write. In practice, consistency is reached within milliseconds, but there is a brief window where a read after a write might return the previous value. These reads cost half the capacity of strongly consistent reads.

Strongly consistent reads are guaranteed to return the most recent data. Use this when your application cannot tolerate stale reads, for example when reading back immediately after a write to confirm a value was stored. These reads consume twice the read capacity units.

Eventual consistency suits the vast majority of read operations. The cost difference is real; the performance difference is negligible for most applications. Only request strong consistency where your logic actually requires it.

Global Tables

DynamoDB Global Tables replicate your data across multiple AWS regions with active-active writes. Every region accepts reads and writes. Changes in one region propagate to all others, typically within one to two seconds.

Global Tables suit:

• Applications with users across multiple geographic regions who need low-latency local access
• Disaster recovery with a recovery point objective measured in seconds rather than hours
• Gaming, social media, or IoT workloads with a global footprint

Conflict resolution uses last-writer-wins based on timestamps. If the same item is written in two regions simultaneously, the write with the more recent timestamp wins.

DynamoDB vs RDS

RDS and DynamoDB are not competing products. They solve different problems. Choosing between them is a workload question, not a “which is better” question.

For a detailed side-by-side breakdown, see RDS vs DynamoDB.