Serverless Databases - Scalable Data Management with DynamoDB
Build databases that scale automatically with traffic, centered on DynamoDB on-demand mode. Including a comparison with Aurora Serverless, this article explains the selection criteria for serverless databases based on workload characteristics.
The Concept of Serverless Databases and the Role of DynamoDB
Serverless databases eliminate the need for capacity planning and server management, letting you focus on application development. Amazon DynamoDB, since its launch in 2012, has been the cornerstone of AWS serverless databases - a fully managed NoSQL database capable of processing millions of requests per second with single-digit millisecond latency. Running equivalent NoSQL databases on-premises (MongoDB, Cassandra, etc.) requires enormous operational effort including cluster setup, sharding design, replication management, and patch application. DynamoDB handles all of this, allowing developers to focus on table design and query optimization. By selecting on-demand capacity mode, you don't even need to configure capacity in advance - it automatically scales with traffic.
Key Features of DynamoDB
DynamoDB offers two capacity modes: on-demand and provisioned. On-demand mode uses per-request pay-as-you-go pricing, ideal for workloads with unpredictable traffic. Provisioned mode, combined with Auto Scaling, enables cost-efficient operations. DynamoDB Streams lets you trigger Lambda functions in real time on table changes, implementing change data capture (CDC) patterns with just a few lines of code. Global tables provide multi-Region replication, and a 99.999% availability SLA applies to global table configurations. By default, replication between Regions is eventually consistent, and when strong consistency is needed across Regions, you choose the multi-Region strong consistency (MRSC) mode. The official documentation (as of August 2026) specifies that MRSC requires a configuration of exactly three Regions (three replicas, or two replicas + one witness). It can be configured only within each of the US, EU, and AP Region sets and cannot span sets. The following is an example of a CLI command that creates a DynamoDB table in on-demand mode. aws dynamodb create-table \ --table-name Orders \ --attribute-definitions AttributeName=CustomerId,AttributeType=S AttributeName=OrderId,AttributeType=S \ --key-schema AttributeName=CustomerId,KeyType=HASH AttributeName=OrderId,KeyType=RANGE \ --billing-mode PAY_PER_REQUEST
Serverless Architecture with Lambda Integration
The combination of DynamoDB and Lambda is the golden pattern of AWS serverless architecture. A configuration where API Gateway requests are processed by Lambda and data is persisted in DynamoDB can support applications serving millions of users without provisioning any servers. DynamoDB Streams and Lambda integration enables asynchronous processing triggered by data changes. For example, you can automatically execute inventory updates and notification sends triggered by order data insertion, building event-driven data pipelines. PartiQL lets you operate DynamoDB with SQL-like syntax, reducing the learning curve for developers familiar with relational databases. DAX (DynamoDB Accelerator) is an in-memory cache that reduces read latency to the microsecond level. Building an equivalent cache layer on-premises would require separately operating Redis or Memcached, but DAX is a managed service fully integrated with DynamoDB.
Cost Efficiency and Scalability Advantages
DynamoDB's on-demand mode uses per-request pay-as-you-go pricing, and during periods of zero traffic only storage charges are incurred (as of August 2026, Northern Virginia / Tokyo). Reads cost 0.125 USD in Northern Virginia and 0.1425 USD in Tokyo per 1 million request units, and writes likewise cost 0.625 USD in Northern Virginia and 0.715 USD in Tokyo per 1 million request units. The always-free tier consists of 25 GB of storage, 25 provisioned WCUs, and 25 provisioned RCUs, and the official documentation describes it as a scale that can handle 200 million requests per month. However, this allowance applies to provisioned capacity, so it does not apply to request charges in on-demand mode. If you want to run a small application within the free tier, the standard approach is to choose the combination of provisioned mode and Auto Scaling. In provisioned mode, you can purchase reserved capacity for the Standard table class only, and discounts of up to 54% with a 1-year term and up to 77% with a 3-year term apply against standard pricing. (The 3-year term is available only in some Regions, the purchase unit is 100 RCUs or 100 WCUs, and on-demand mode and the Standard-IA table class are both not eligible.) In terms of scalability, the default quota per table is 40,000 read request units and 40,000 write request units per second, and if you need a larger scale, you request an increase through Service Quotas. (Provisioned mode also has a separate default account-level limit of 80,000 RCUs / 80,000 WCUs.) Storage does not require capacity to be reserved in advance, and consistent performance is maintained even when table sizes reach hundreds of TB.
Data Modeling and Access Pattern Design
The key to using DynamoDB effectively is understanding a design approach that differs from relational databases. You start by identifying the application's access patterns, in other words, under what conditions data is read and written, and then design tables and keys to match them. It is important to choose the partition key, which determines how data is distributed and retrieved, so that access is not skewed. If you design so that related data can be retrieved together efficiently, you can draw out fast and stable performance. Because searching with arbitrary conditions afterward is a weak point, understanding the required search patterns in advance is the premise for scalable data design.
Comparison with Aurora Serverless and Selection Criteria
DynamoDB is not the only option for serverless databases. When a relational model is needed, the serverless configuration of Aurora is the counterpart option (its name in the official documentation is Aurora Serverless. AWS announces that it renamed it from Aurora Serverless v2 in April 2026). Aurora Serverless adjusts capacity automatically in units called ACUs (Aurora Capacity Units), and 1 ACU corresponds to about 2 GiB of memory with the matching CPU and network performance. The capacity range can be specified from a minimum of 0.5 ACU to a maximum of 256 ACU, and it follows the workload with fine increases and decreases in increments of 0.5 ACU. As of October 2026, supported Aurora PostgreSQL engine versions allow the maximum to be set as high as 384 ACU. If you want it to stop automatically when there are no user-initiated connections for a certain period, you can set the minimum capacity to 0 ACU. Pricing consists of ACU usage plus storage and I/O, and unit prices differ by Region and configuration, so check the actual amounts in the official Aurora pricing table. The selection criteria can be organized along two axes: "Can the access patterns be fixed at design time?" and "Is the flexibility of SQL needed?" If fast reads and writes with specified keys are the core and you can identify the required access patterns at design time, DynamoDB has the advantage. Single-digit millisecond latency and per-request billing take effect, and the cost while idle is only the storage charge. Conversely, when aggregation, joins, or ad hoc queries whose conditions are changed afterward are included in the business requirements, or when you migrate existing PostgreSQL or MySQL assets, you choose Aurora Serverless. Billing continues even while idle because a minimum ACU is reserved (except when you use the automatic stop with 0 ACU), but you can gain the expressiveness of the relational model and ease of handling transactions that span multiple tables. The two are not mutually exclusive. Using both is also a design option: placing the data that serves as the source of truth for business transactions in Aurora Serverless and handling the high-throughput read-side portion with DynamoDB.
Summary - Serverless Database Selection Criteria
DynamoDB is the main option for data persistence in serverless architectures. On-demand mode's scaling from zero and pay-per-use pricing serves a wide range of use cases from startups to large enterprises. The features needed for data management are provided comprehensively, such as event-driven processing with DynamoDB Streams, multi-Region deployment with global tables (a 99.999% availability SLA for global table configurations), and microsecond-level caching with DAX. As for the order of selection, if you can fix the access patterns at design time, start by examining DynamoDB, and if aggregation, ad hoc queries, or migration of existing relational assets are included in the requirements, choose Aurora Serverless; organizing it this way keeps the decision consistent.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.