Everything you need to know about AWS DynamoDB

Summary:

• AWS DynamoDB is a fully managed NoSQL database delivering single-digit millisecond latency at any scale, with recent 2024-2025 enhancements including multi-Region strong consistency and more flexible capacity mode switching.
• Understanding the distinction between on-demand and provisioned capacity modes, along with the November 2024 pricing reductions, can dramatically reduce costs for workloads ranging from small applications to global enterprise systems.
• Effective data modeling using composite keys, single-table design patterns, and strategic use of Global Secondary Indexes separates performant DynamoDB implementations from costly anti-patterns.
• Advanced features like DynamoDB Streams, ACID transactions, DAX caching, and zero-ETL integrations with services like Amazon OpenSearch and Redshift unlock sophisticated event-driven architectures.

When a service handles over 100 trillion requests annually while maintaining single-digit millisecond response times, it earns attention from engineers building systems at every scale. AWS DynamoDB has evolved from a simple key-value store into a sophisticated distributed database. It powers everything from gaming leaderboards processing millions of concurrent players to financial systems requiring strict transactional guarantees.

Despite its ubiquity in modern cloud architectures, many engineers struggle to move beyond basic CRUD operations. The nuanced territory of cost optimization, advanced data modeling, and global replication strategies distinguishes production-grade implementations from tutorial-level deployments.

The following illustration depicts the high-level architecture of DynamoDB, showing how client requests flow through the service endpoint to distributed storage nodes across multiple Availability Zones.

The evolution of AWS DynamoDB

Amazon DynamoDB emerged in 2012 as the public cloud manifestation of lessons learned from Amazon’s internal Dynamo system, documented in the influential 2007 Dynamo paper. The original service offered a straightforward proposition: a managed NoSQL database with predictable performance regardless of data volume.

Over the subsequent decade, AWS systematically addressed enterprise requirements that initially pushed teams toward relational alternatives. The introduction of Global Secondary Indexes in 2013 enabled flexible query patterns beyond the primary key. ACID transactions arrived in 2018, eliminating a significant objection from teams requiring multi-item atomic operations.

Global Tables, initially launched with eventual consistency, received a transformative upgrade in 2025 with multi-Region strong consistency (MRSC). This allows applications to read their own writes immediately across geographic boundaries. Consider the following timeline of pivotal enhancements:

• 2018: DynamoDB Transactions introduced with full ACID guarantees (the service has since expanded this to support up to 100 items per transaction)
• 2023: Incremental export to S3 introduced for cost-effective data lake integration
• 2024: Warm throughput feature launched to manage baseline capacity, and on-demand/Global Tables pricing cut significantly (November 2024)
• 2025: Multi-Region strong consistency for Global Tables, and capacity mode switching (from provisioned to on-demand) increased to four times per 24-hour period.

These incremental improvements transformed DynamoDB from a niche solution for specific access patterns into a general-purpose database capable of handling diverse workloads. Understanding this evolution helps engineers appreciate why certain design decisions exist and anticipate future capabilities.

Core architecture and data models

DynamoDB’s architecture centers on automatic partitioning, where data distributes across storage nodes based on partition key hash values. Each partition supports up to 3,000 Read Capacity Units (RCUs) and 1,000 Write Capacity Units (WCUs). The service transparently splits partitions as throughput or storage requirements grow.

This design eliminates manual sharding but demands careful partition key selection to avoid hot partitions that throttle requests.

Primary key structures

Tables support two primary key configurations. A simple primary key uses only a partition key, suitable for scenarios where each item has a unique identifier and access patterns involve direct lookups. A composite primary key combines a partition key with a sort key, enabling range queries and hierarchical data organization within partitions.

The sort key supports operators like begins_with, between, and comparison operators. This makes it powerful for time-series data and parent-child relationships.

Secondary indexes

Global Secondary Indexes (GSIs) project data into alternative key structures, enabling queries on non-primary attributes. Each GSI maintains its own provisioned throughput and can include a subset of attributes to minimize storage costs.

Local Secondary Indexes (LSIs) share the base table’s partition key but provide alternative sort keys. This is useful when query flexibility is needed within existing partitions. GSIs support eventual consistency only, while LSIs offer strongly consistent reads at higher cost.

The following diagram illustrates how a single-table design uses composite keys and GSIs to support multiple access patterns without data duplication.

Understanding these foundational structures prepares engineers for the critical decision between capacity modes, which directly impacts both cost and operational complexity.

Capacity modes and pricing strategies

DynamoDB offers two capacity modes with distinct cost models and operational characteristics. Choosing correctly can reduce monthly bills by 50% or more. Choosing incorrectly leads to either throttling during traffic spikes or paying for unused capacity during quiet periods.

On-demand versus provisioned capacity

On-demand mode charges per request with no capacity planning required. The service automatically scales to accommodate traffic spikes, making it ideal for unpredictable workloads, new applications without established baselines, or development environments. Following the November 2024 pricing reduction, on-demand costs dropped significantly, making it viable for a broader range of production workloads.

Provisioned mode requires specifying RCUs and WCUs in advance, with auto-scaling available to adjust within defined bounds. Reserved capacity purchases offer up to 77% savings compared to on-demand pricing for predictable, steady-state workloads.

The recent enhancement allowing capacity mode switches up to four times per 24-hour period enables sophisticated strategies. You can switch to provisioned during predictable business hours and on-demand overnight.

Additional cost factors

Beyond capacity charges, several factors influence total cost. Storage costs $0.25 per GB-month for standard tables. Data transfer out incurs standard AWS egress charges. GSIs consume separate throughput and storage. DynamoDB Streams add $0.02 per 100,000 read requests.

Point-in-time recovery (PITR) adds approximately 20% to storage costs but provides continuous backups with 35-day retention.

Global tables and multi-Region replication

Global Tables replicate data across AWS Regions with sub-second latency, enabling applications to serve users from geographically proximate endpoints while maintaining a unified data layer. The 2025 introduction of multi-Region strong consistency (MRSC) fundamentally changed the consistency model available to globally distributed applications.

Multi-Region strong consistency architecture

MRSC Global Tables introduce a witness Region concept, where a lightweight witness participates in consensus without storing full data replicas. When an application writes to any Region and immediately reads from another, MRSC guarantees the read reflects the write. This eliminates the eventual consistency window that previously forced architects to implement complex conflict resolution or restrict writes to a single Region.

The following architectural diagram shows how MRSC achieves strong consistency using a witness Region for distributed consensus.

Global Tables pricing decreased substantially in November 2024, with replicated write costs reduced by up to 67% in some configurations. This makes multi-Region architectures economically viable for mid-size applications that previously could not justify the expense.

Data modeling best practices for 2026

DynamoDB data modeling inverts traditional relational thinking. Instead of normalizing data and joining at query time, effective DynamoDB design starts with access patterns and denormalizes data to serve those patterns efficiently. This section addresses both foundational patterns and advanced techniques for handling edge cases.

Single-table design principles

Single-table design consolidates multiple entity types into one table, using generic attribute names (PK, SK) with prefixed values to distinguish entities. This approach minimizes the number of requests needed to retrieve related data and simplifies capacity management. Key principles include:

1. Identify access patterns first: Document every query the application requires before designing the schema
2. Use composite sort keys: Concatenate attributes (STATUS#CREATED_DATE) to enable complex filtering within partitions
3. Leverage sparse indexes: GSIs only include items where the index key attributes exist, enabling filtered views without scan operations
4. Overload GSIs: A single GSI can serve multiple access patterns by using generic key names with entity-specific prefixes

Handling large item sizes

DynamoDB enforces a 400 KB item size limit, which creates challenges for applications storing document metadata, image metadata, or complex nested structures. The chunked-object pattern addresses this limitation by splitting large items across multiple DynamoDB items with a consistent chunking strategy.

Common anti-patterns to avoid

Several modeling mistakes consistently cause performance and cost problems. Using scan operations for regular queries indicates missing indexes. Storing frequently updated counters as single items creates hot partitions. Embedding unbounded lists within items eventually hits size limits.

Creating one table per entity type (relational thinking) multiplies operational overhead and prevents efficient batch operations across entity types.

DynamoDB Streams and event-driven integrations

DynamoDB Streams captures a time-ordered sequence of item-level modifications, enabling event-driven architectures where downstream systems react to data changes without polling. Each stream record contains the item’s key attributes and, optionally, the before and after images of modified items.

Stream processing patterns

Lambda triggers provide the simplest integration, invoking functions automatically when stream records appear. For high-throughput scenarios, Kinesis Data Streams integration offers enhanced fan-out capabilities and longer retention (up to 365 days versus 24 hours for native streams). Common use cases include:

• Materialized views: Maintain denormalized copies of data in secondary tables optimized for specific query patterns
• Cross-Region replication: Custom replication logic for scenarios where Global Tables constraints do not fit
• Audit logging: Capture all modifications for compliance and forensic analysis
• Cache invalidation: Trigger DAX or ElastiCache updates when source data changes

Zero-ETL integrations

AWS introduced zero-ETL integrations connecting DynamoDB directly to analytics services without intermediate data pipelines. The Amazon OpenSearch Service integration enables full-text search across DynamoDB data. The Amazon Redshift zero-ETL integration allows SQL analytics on operational data without building ETL jobs.

These integrations reduce architectural complexity and drastically reduce the synchronization lag inherent in batch ETL processes, typically bringing data replication latency down to just a few seconds.

Transactions, consistency, and performance optimization

DynamoDB transactions support atomic, consistent, isolated, and durable operations across up to 100 items within a single Region. TransactWriteItems and TransactGetItems APIs enable all-or-nothing semantics essential for maintaining data integrity across related items.

Transaction mechanics

Transactions consume twice the capacity of equivalent non-transactional operations due to the two-phase commit protocol. Each item in a transaction must reside in the same Region, though items can span multiple tables. Transactions support condition expressions, enabling optimistic concurrency control where operations fail if underlying data changed since retrieval.

Consistency options and DAX caching

Standard reads offer eventual consistency by default, with strongly consistent reads available at double the capacity cost. For read-heavy workloads, DynamoDB Accelerator (DAX) provides an in-memory cache delivering microsecond latency for repeated reads. DAX operates as a write-through cache, automatically invalidating entries when underlying data changes.

Hot partition mitigation strategies include write sharding (appending random suffixes to partition keys and aggregating on read), caching with DAX for read-heavy items, and using SQS to buffer writes during traffic spikes. The warm throughput feature, introduced in 2024, pre-provisions capacity for tables with predictable traffic patterns, reducing cold-start throttling after periods of inactivity.

Limitations, trade-offs, and when to choose alternatives

Despite its capabilities, DynamoDB imposes constraints that make it unsuitable for certain workloads. Honest evaluation of these limitations prevents costly mid-project migrations.

Key limitations include the 400 KB item size limit, 1 MB response size per query, lack of server-side joins, limited aggregation capabilities, and the requirement to define access patterns before schema design. Complex analytical queries requiring ad-hoc joins perform poorly and expensively compared to relational databases or data warehouses.

For workloads requiring both transactional and analytical capabilities, the zero-ETL integrations mentioned earlier provide a pragmatic middle ground. You can keep operational data in DynamoDB while enabling analytics in purpose-built services.

Conclusion

AWS DynamoDB has matured into a sophisticated distributed database that rewards engineers who invest in understanding its architecture and constraints. The November 2024 pricing reductions and 2025 multi-Region strong consistency capabilities significantly expanded viable use cases. DynamoDB is now competitive for workloads previously requiring relational databases or complex multi-database architectures.

Effective implementation requires mastering single-table design patterns, selecting appropriate capacity modes based on workload characteristics, and leveraging features like Streams and zero-ETL integrations to build event-driven systems.

AWS continues investing in reducing operational complexity through features like the NoSQL Workbench for data modeling and expanded integration options. Engineers who develop fluency with DynamoDB’s access pattern-driven design philosophy position themselves to build systems that scale gracefully from prototype to global production. The database you choose shapes the systems you can build, and DynamoDB, properly applied, enables architectures that would be prohibitively complex with traditional alternatives.