Amazon DynamoDB: Pros, Cons, and Use Cases

Amazon DynamoDB is a fully managed NoSQL key-value and document database service from AWS. It is designed for applications that need predictable low latency, high throughput, automatic scaling, and minimal database operations.

Table of Contents

• What Is DynamoDB?
  • Why DynamoDB Exists
  • How DynamoDB Is Different From Relational Databases
• Core Concepts
  • Tables, Items, and Attributes
  • Primary Keys
  • Secondary Indexes
  • Capacity Modes
• Advantages of DynamoDB
  • Performance at Scale
  • Fully Managed and Serverless
  • High Availability
  • Flexible Schema
  • AWS Integration
• Disadvantages of DynamoDB
  • Limited Query Capabilities
  • Data Modeling Complexity
  • Cost Complexity
  • Item Size Limit
  • Consistency Tradeoffs
• Common Use Cases
  • User Profiles and Sessions
  • Event-Driven Systems
  • E-commerce and Order Management
  • IoT and Time-Series-Like Data
  • Gaming and Leaderboards
• When Not to Use DynamoDB
• DynamoDB vs Relational Databases
• Best Practices
  • Design Access Patterns First
  • Avoid Hot Partitions
  • Use Indexes Carefully
  • Store Large Objects in S3
• Conclusion

What Is DynamoDB?

DynamoDB is a serverless NoSQL database optimized for high-throughput and low-latency access patterns. Unlike traditional relational databases, DynamoDB does not focus on joins, complex SQL queries, or flexible ad-hoc reporting. It focuses on fast key-based access at scale.

A typical DynamoDB use case is not “find anything in any possible way.” A typical DynamoDB use case is “given this key, return the exact data this application needs as quickly as possible.”

Why DynamoDB Exists

Many cloud-native applications need to serve large amounts of traffic without spending time on database servers, patching, replication, failover, and capacity planning. DynamoDB exists for these workloads.

For example, imagine a mobile application with millions of users. Each user opens the app and loads a profile, preferences, recent activity, and session state. These reads are simple, predictable, and key-based. DynamoDB fits this pattern very well because the application can fetch data directly by primary key.

How DynamoDB Is Different From Relational Databases

In a relational database, you usually start with entities, relationships, normalization, and SQL queries. You may create tables like users, orders, order_items, and payments, then join them when needed.

In DynamoDB, you usually start with access patterns. You ask what the application needs to read and write, then design keys and indexes around those operations.

Relational database thinking:

Entities first
Relationships second
Queries later

DynamoDB thinking:

Access patterns first
Keys second
Table structure later

This is the biggest mindset shift. DynamoDB can be extremely powerful, but only when the data model is designed around how the application actually accesses data.

Core Concepts

Tables, Items, and Attributes

DynamoDB stores data in tables. A table contains items, and each item contains attributes.

• Table - a collection of items.
• Item - a single record inside a table.
• Attribute - a key-value field inside an item.

Unlike a relational table, items in the same DynamoDB table do not need to have exactly the same attributes.

{
    "pk": "USER#123",
    "sk": "PROFILE",
    "email": "user@example.com",
    "name": "Alex"
}

{
    "pk": "USER#123",
    "sk": "SESSION#abc",
    "expires_at": "2026-06-01T10:00:00Z"
}

Both items can live in the same table even though they represent different concepts.

Primary Keys

Every DynamoDB table requires a primary key. The primary key can be a simple partition key or a composite key made from a partition key and sort key.

• Partition key determines where data is distributed.
• Sort key enables ordered queries inside the same partition.

A common pattern is to use structured key values:

pk = USER#123
sk = PROFILE

pk = USER#123
sk = ORDER#2026-01-15

pk = USER#123
sk = SESSION#abc

This allows the application to query all records for a user, or a specific type of record for that user.

Secondary Indexes

Indexes allow DynamoDB to support additional access patterns beyond the main table key.

• Local Secondary Index (LSI) uses the same partition key as the table but a different sort key.
• Global Secondary Index (GSI) can use a different partition key and sort key.

For example, an orders table may use USER#123 as the main partition key so the application can find orders by user. But the business may also need to find orders by status.

Main table:
pk = USER#123
sk = ORDER#9001

GSI:
gsi1_pk = STATUS#PAID
gsi1_sk = ORDER#9001

This gives the application another way to query the same data. However, indexes are not free. They increase write cost, storage cost, and modeling complexity.

Capacity Modes

DynamoDB supports two common capacity modes: on-demand and provisioned.

• On-demand capacity is easier to operate and automatically adapts to traffic.
• Provisioned capacity can be cheaper for predictable workloads but requires more planning.

For a new product with unpredictable traffic, on-demand mode is usually simpler. For a mature workload with stable traffic patterns, provisioned capacity with auto scaling may reduce cost.

Advantages of DynamoDB

Performance at Scale

DynamoDB is designed for predictable low-latency access at very large scale. This makes it a strong fit for workloads where requests are simple, frequent, and key-based.

For example, a gaming platform may need to load player state on every login. The access pattern is predictable: get player by ID. DynamoDB can serve this kind of lookup quickly without requiring joins or complex query planning.

Fully Managed and Serverless

DynamoDB removes much of the operational work normally associated with databases. AWS manages hardware, replication, patching, storage scaling, and availability.

This is valuable for small teams. Instead of spending time managing database servers, the team can focus on application logic, access patterns, monitoring, and cost control.

High Availability

DynamoDB is built for high availability. Data is automatically replicated across multiple Availability Zones inside a region.

For applications that need multi-region behavior, DynamoDB Global Tables can replicate data across regions. This can be useful for globally distributed applications, but it also introduces conflict handling and consistency tradeoffs.

Flexible Schema

DynamoDB does not require every item in a table to have the same shape. This makes it useful for evolving data models.

For example, a user profile can gain new optional settings over time without running a schema migration:

{
    "pk": "USER#123",
    "sk": "PROFILE",
    "email": "user@example.com",
    "theme": "dark",
    "notifications_enabled": true
}

This flexibility is useful, but it also means the application must be disciplined. Without clear conventions, a flexible schema can become messy.

AWS Integration

DynamoDB integrates well with other AWS services:

• AWS Lambda for serverless application logic.
• API Gateway for HTTP APIs.
• EventBridge for event-driven workflows.
• DynamoDB Streams for change events.
• IAM for access control.
• CloudWatch for monitoring.

For example, a system can write an order to DynamoDB, emit a change through DynamoDB Streams, and trigger a Lambda function that sends a confirmation email or updates a search index.

Disadvantages of DynamoDB

Limited Query Capabilities

DynamoDB is not a general-purpose SQL query engine. It does not support joins, arbitrary filtering across large datasets, or ad-hoc analytical queries in the same way a relational database does.

This is a common surprise for developers coming from PostgreSQL or MySQL. In SQL, you can often add a new query later. In DynamoDB, you usually need to design that query as an access pattern upfront.

Data Modeling Complexity

DynamoDB data modeling can be harder than relational modeling because it requires thinking about reads and writes before designing the table.

For example, an e-commerce system may need access patterns like:

• Get cart by user ID.
• Get order by order ID.
• List orders by user.
• List orders by status.
• List orders created during a time range.

Each access pattern may require a specific key structure or secondary index. If one access pattern is missed, adding it later may require a new index, data backfill, or even a table redesign.

Cost Complexity

DynamoDB can be cost-effective, but costs can be tricky. You pay for reads, writes, storage, indexes, backups, streams, and other features depending on configuration.

A common cost mistake is overusing GSIs. Every GSI stores a separate copy of indexed attributes and consumes write capacity when the base item changes.

For example, if an item is written once but projected into three GSIs, the write cost is higher than writing only to the base table.

Item Size Limit

DynamoDB has a 400 KB item size limit.

This means large files, long documents, images, PDFs, and large payloads should not be stored directly in DynamoDB.

A common pattern is to store large objects in S3 and keep only metadata in DynamoDB:

{
    "pk": "USER#123",
    "sk": "FILE#invoice-2026.pdf",
    "s3_key": "invoices/user-123/invoice-2026.pdf",
    "size": 2048000,
    "content_type": "application/pdf"
}

Consistency Tradeoffs

DynamoDB supports eventually consistent reads and strongly consistent reads for base table and LSI reads. Eventually consistent reads are cheaper and often good enough, but some workflows require stronger consistency.

For example, reading a user profile after an update may tolerate eventual consistency. But reading account balance, payment status, or inventory count may require stronger consistency or a different data model.

Common Use Cases

User Profiles and Sessions

DynamoDB is a strong fit for user profiles, settings, preferences, and sessions because these workloads are usually key-based.

Get user profile:
pk = USER#123
sk = PROFILE

Get active session:
pk = SESSION#abc

This type of workload does not need joins or complex queries. The application knows exactly which item it needs.

Event-Driven Systems

DynamoDB works well in event-driven architectures, especially when combined with Lambda and DynamoDB Streams.

For example, a payment workflow can store payment state in DynamoDB. When the item changes from PENDING to PAID, a stream event can trigger downstream processing such as receipt generation, analytics updates, or customer notifications.

E-commerce and Order Management

DynamoDB can support high-traffic e-commerce workloads such as carts, orders, checkout state, and inventory reservations.

A useful pattern is grouping order-related records by user or order:

pk = USER#123
sk = CART

pk = USER#123
sk = ORDER#2026-05-01#9001

pk = ORDER#9001
sk = PAYMENT

This allows the application to fetch common views quickly, such as a user's cart or order history.

IoT and Time-Series-Like Data

DynamoDB can handle high write throughput for IoT-style workloads when partition keys are designed carefully.

For example:

pk = DEVICE#123#2026-06
sk = 2026-06-04T10:15:00Z

This key design allows querying events for one device during a specific month. The month bucket also helps avoid creating one unbounded partition for the entire lifetime of the device.

Gaming and Leaderboards

DynamoDB is often used for player profiles, game state, match history, and leaderboard-like access patterns.

For example, a game may store player state by player ID and use a GSI to query rankings by score bucket or region.

Main table:
pk = PLAYER#123
sk = PROFILE

GSI:
gsi1_pk = REGION#US
gsi1_sk = SCORE#0009500

The exact design depends on how the leaderboard is queried. Global top scores, regional scores, and friend-only leaderboards may require different access patterns.

When Not to Use DynamoDB

DynamoDB is powerful, but it is not the right database for every system.

Avoid DynamoDB when the application needs frequent complex joins, ad-hoc reporting, flexible querying by many different fields, or analytics over large datasets. In those cases, PostgreSQL, MySQL, Aurora, Redshift, OpenSearch, or a data warehouse may be a better fit.

DynamoDB may also be unnecessary for small applications with simple traffic and relational data. If a product has users, invoices, subscriptions, payments, and reporting requirements, a relational database may be easier to build and maintain.

• Avoid DynamoDB when relational joins are central to the application.
• Avoid DynamoDB for ad-hoc analytics and reporting queries.
• Avoid DynamoDB when access patterns are unknown or change frequently.
• Avoid DynamoDB when the team is not ready for access-pattern-first modeling.
• Avoid DynamoDB for large objects that should live in S3.

DynamoDB vs Relational Databases

The practical decision is not “DynamoDB vs SQL” in general. The better question is:

Does the application know its access patterns clearly enough to design keys around them?

If yes, DynamoDB may be a strong fit. If no, a relational database may be safer and more flexible.

Best Practices

Design Access Patterns First

Before creating a DynamoDB table, list the exact queries the application needs.

• Get user profile by user ID.
• List orders by user ID.
• Get order by order ID.
• List active subscriptions by account ID.
• Find failed jobs by status and creation time.

Then design the partition keys, sort keys, and indexes around those access patterns.

Avoid Hot Partitions

A hot partition happens when too much traffic targets the same partition key.

For example, this can be dangerous:

pk = STATUS#PENDING

If thousands of workers constantly query or update the same status partition, it can become overloaded.

A better design may introduce bucketing:

pk = STATUS#PENDING#BUCKET#01
pk = STATUS#PENDING#BUCKET#02
pk = STATUS#PENDING#BUCKET#03

The exact solution depends on the workload, but the principle is the same: distribute traffic across keys.

Use Indexes Carefully

GSIs are powerful, but every index has a cost. It consumes storage and write capacity, and it adds complexity to the data model.

Create indexes for real access patterns, not hypothetical future queries.

Store Large Objects in S3

Do not store large payloads directly in DynamoDB. Store files, images, PDFs, exports, and large documents in S3, then store metadata and lookup keys in DynamoDB.

This keeps DynamoDB items small, predictable, and efficient.

Conclusion

Amazon DynamoDB is a powerful database for cloud-native systems that need low latency, high scale, and minimal operational overhead. It works especially well when access patterns are predictable and the application can model data around keys.

Its biggest advantages are performance, scalability, serverless operations, AWS integration, and flexible schema design. Its biggest challenges are limited query flexibility, access-pattern-first modeling, cost complexity, item size limits, and consistency tradeoffs.

For a real-world example of DynamoDB in practice, see Blog platform DynamoDB single-table design case study, which walks through access patterns, key design, and trade-offs in a production system.

Use DynamoDB when your application needs predictable key-based access at scale. Use a relational database when your application needs joins, flexible queries, and relational consistency as the core of the data model.