Serverless Databases: a Deep Dive into DynamoDB and Cosmos DB

The rise of serverless computing has fundamentally changed how organizations build and deploy applications. By abstracting away server management, developers can focus on writing code and delivering features rather than provisioning hardware. Among the most critical components in this paradigm are serverless databases, which offer on-demand scaling, pay-per-use pricing, and high availability without operational overhead. Two leading cloud providers offer powerful serverless database solutions: Amazon DynamoDB (AWS) and Azure Cosmos DB (Microsoft). Both are fully managed, globally distributed NoSQL databases, but they differ in architecture, consistency models, indexing, and integration ecosystems. This deep dive explores each service in detail, compares their strengths and trade-offs, and provides guidance for selecting the right tool for your workload.

What Are Serverless Databases?

Serverless databases are database services that automatically handle infrastructure tasks such as provisioning, scaling, patching, and backups. The term “serverless” does not mean that servers do not exist; rather, the cloud provider manages them entirely, exposing only a database endpoint to the application. Resources scale up and down automatically based on demand, and billing is consumption-based—typically pay for the storage used and the number of read/write operations executed.

This model is especially beneficial for applications with variable or unpredictable traffic, such as e‑commerce flash sales, IoT sensor ingestion, mobile backend services, and event-driven architectures. Serverless databases eliminate capacity planning, reduce idle costs, and simplify development by providing latency-optimized APIs and built-in replication. However, they also introduce trade-offs: cost can become hard to predict at very high throughput, and the lack of control over underlying hardware may complicate certain performance optimizations or migration paths.

Amazon DynamoDB – A Pillar of AWS Serverless

Amazon DynamoDB is a fully managed NoSQL key‑value and document database that delivers single‑digit millisecond latency at any scale. Launched in 2012, it has become the default database for many AWS serverless applications, working seamlessly with Lambda, API Gateway, Step Functions, and Kinesis. DynamoDB supports both eventually consistent and strongly consistent reads, and offers features such as global tables, auto-scaling, on‑demand capacity, DynamoDB Streams for change‑data‑capture, and global secondary indexes (GSIs).

Key Features of DynamoDB

  • Flexible data models: Supports key‑value (simple primary key) and document (composite primary key with sort key) schemas. Items can have varying attributes, making it easy to evolve without schema migrations.
  • Automatic scaling: You can choose between provisioned throughput (with auto‑scaling) or on‑demand capacity. On‑demand automatically adjusts for traffic spikes but charges per request; provisioned is more cost‑effective for stable, predictable workloads.
  • Global Tables: Multi‑region, multi‑leader replication with eventual consistency. Ideal for disaster recovery and low‑latency reads/writes across the globe.
  • DynamoDB Accelerator (DAX): An in‑memory cache that can reduce read latency from single‑digit milliseconds to microseconds.
  • Security: Encryption at rest (AWS KMS) and in transit (TLS), fine‑grained IAM policies, VPC endpoints, and integration with AWS CloudTrail for audit logs.
  • Streams and Triggers: DynamoDB Streams capture item‑level changes in near‑real time, enabling event‑driven architectures (e.g., replicate to Elasticsearch, update secondary indexes, trigger Lambda functions).
  • Transactions: ACID transactions across up to 25 items or 4 MB of data, useful for financial applications and multi‑item operations.

Pricing Model

DynamoDB pricing is based on capacity mode. Provisioned capacity requires you to specify read and write capacity units (RCUs/WCUs). You pay an hourly rate per unit, plus storage costs ($0.25 GB/month). Auto‑scaling adjusts within bounds you set. On‑demand capacity charges per million read/write request units (RRUs/WRUs) and includes a premium for elasticity. Storage, data transfer, Global Tables replication, DAX, Streams, and backup are billed separately. For spiky workloads, on‑demand can be simpler; for steady flows, provisioned is usually cheaper. AWS provides a free tier of 25 GB of storage and 200 million requests per month (for new accounts).

Common Use Cases

  • Session state: Low‑latency reads/writes make it excellent for storing user sessions in web and mobile applications.
  • Gaming: Player profiles, leaderboards, and game state with high concurrency and unpredictable load.
  • IoT: Ingestion of sensor data with automatic scaling to handle millions of writes per second.
  • E‑commerce: Shopping cart and order processing using transactions to ensure consistency.
  • Event‑driven microservices: Combined with Lambda and EventBridge, DynamoDB forms the backbone of many serverless backends.

Limitations and Considerations

While powerful, DynamoDB is not a one‑size‑fits‑all solution. Its query capabilities are limited: you can only query by primary key (or GSI) and optional range conditions. Complex joins, aggregation, and full‑text search require external services like Elasticsearch or Aurora. The 400 KB maximum item size can be restrictive for large documents. Global Tables replicate eventually (no strong consistency across regions). Provisioning can be tricky: underestimating throughput leads to throttling, while over‑provisioning wastes money. Strongly consistent reads are limited to the primary copy (not available in secondary regions). The lack of a native serverless SQL interface (like DynamoDB’s PartiQL) is sometimes seen as a learning curve for teams accustomed to relational databases.

Amazon DynamoDB official documentation

Azure Cosmos DB – Globally Distributed, Multi‑Model Database

Microsoft Azure Cosmos DB is a fully managed NoSQL database designed for mission‑critical applications that require global distribution, elastic scaling, and multiple consistency models. Unlike DynamoDB, Cosmos DB is multi‑model out of the box: it supports document (SQL API), key‑value (Table API), graph (Gremlin API), column‑family (Cassandra API), and MongoDB API. This flexibility allows developers to use familiar query languages while benefiting from Cosmos DB’s underlying global replication and turnkey SLA guarantees.

Key Features of Cosmos DB

  • Multi‑model and multi‑API: You can choose between NoSQL (document), MongoDB, Cassandra, Gremlin (graph), and Table APIs. All APIs sit on the same core — the Cosmos DB engine — so they share throughput, indexing, and global distribution.
  • Global distribution (turnkey): With a few clicks or lines of code, you can replicate data to any number of Azure regions. Cosmos DB supports multi‑region writes (active‑active) with automatic conflict resolution.
  • Five well‑defined consistency levels: Strong, Bounded staleness, Session, Consistent prefix, and Eventual. You can choose the level per request, balancing performance against consistency guarantees.
  • Automatic indexing: By default, all item properties are indexed without manual schema definition. This speeds up arbitrary queries, but you can customize indexing policies to reduce RU consumption.
  • Request Units (RUs): Cosmos DB uses a unified throughput currency measured in Request Units per second. 1 RU corresponds to a 1 KB read. Reads are faster (1 RU per read) than writes (5 RU per 1 KB write). You provision throughput per container or database, or use serverless (autoscale) mode.
  • SLA guarantees: 99.999% read availability, 99.999% writes for multi‑region, and <10 ms latency for reads and writes at P99 (within the same region). Strong consistency has slightly higher latency.
  • Change Feed: A persistent, ordered log of item changes that can be consumed by Azure Functions or other processors for event‑driven architectures.
  • Analytical store: Built‑in columnar store for running large‑scale analytical queries without impacting transactional workloads (using Synapse Link).

Pricing Model

Cosmos DB pricing is based on provisioned throughput (RUs) and consumed storage. You can also use serverless mode (preview at time of writing) where you pay for consumed RUs and storage, scaling to zero when idle — ideal for small workloads. Provisioned throughput can be set per container or per database. Autoscale allows you to set a maximum RU limit and the system adjusts within that range. Storage costs approximately $0.25 GB/month (similar to DynamoDB). Data transfer costs for multi‑region replication are extra. Cosmos DB provides a free tier of 1000 RU/s and 25 GB storage for the first account per subscription.

Compared to DynamoDB, Cosmos DB’s RU modeling is more granular and can be more complex to estimate, especially for multi‑model workloads. However, automatic indexing and tunable consistency can reduce total RUs needed, especially for read‑heavy applications that can tolerate eventual consistency.

Common Use Cases

  • Enterprise SaaS applications: Multi‑tenant systems that require geo‑distributed low‑latency access and strong SLAs.
  • IoT and time‑series: Ingesting high‑velocity sensor data with global views.
  • E‑commerce platforms: Product catalogs, shopping carts, order management, with multi‑region active‑active deployments.
  • Real‑time analytics: Using change feed and Synapse Link to drive dashboards and machine learning models.
  • Graph applications: Social networks, recommendation engines, and knowledge graphs via Gremlin API.

Limitations and Considerations

Cosmos DB’s breadth comes with a learning curve. The RU model requires careful planning: you pay for allocated capacity even when idle (unless using serverless). Making arbitrary queries efficient often relies on the automatic indexing, but poorly designed indexes can explode RU cost. Cross‑partition queries are less efficient because they touch every partition. Strongly consistent reads and multi‑region writes increase latency and cost. The analytical store is only available for SQL API and MongoDB API. Cosmos DB is tied to the Azure ecosystem; integration with other clouds or on‑premises can be more complex. Item size limit is 2 MB (vs. DynamoDB’s 400 KB). As a managed service, you have no direct control over OS, database engine version, or hardware.

Azure Cosmos DB official documentation

Head‑to‑Head Comparison: DynamoDB vs. Cosmos DB

Choosing between these two serverless databases depends on your existing cloud provider, workload characteristics, and specific feature requirements. Below is a structured comparison across key dimensions.

Data Model and API

DynamoDB is primarily key‑value and document. It uses a proprietary API (AWS SDK) along with PartiQL (SQL‑compatible query language). Cosmos DB offers five APIs: SQL (document), MongoDB, Cassandra, Gremlin (graph), and Table. This gives Cosmos DB a clear advantage for teams wanting to use existing drivers or migrate from other NoSQL databases without rewriting queries.

Global Distribution

Both support multi‑region replication. DynamoDB uses Global Tables with eventual consistency (or strong only within a single region). Cosmos DB provides multi‑region writes with multiple consistency levels, including strong across regions (though with latency cost). Cosmos DB’s global distribution management is simpler from the portal.

Consistency Models

DynamoDB offers two: eventual and strong. Cosmos DB offers five: eventual, consistent prefix, session, bounded staleness, and strong. The finer granularity allows Cosmos DB to optimize cost and performance for specific use cases (e.g., session‑level consistency for e‑commerce baskets is very popular).

Querying and Indexing

DynamoDB requires you to define a primary key and optional sort key; it automatically indexes primary keys and GSIs. You can also create sparse indexes. Ad‑hoc querying is limited. Cosmos DB automatically indexes all properties by default, enabling arbitrary queries without upfront schema definition. This makes Cosmos DB more flexible for exploratory queries but can increase RU cost for high‑write workloads.

Throughput and Pricing Granularity

DynamoDB uses RCU/WCU – reads are half the cost of writes (1 RCU for 4 KB, 1 WCU for 1 KB). Cosmos DB uses RUs – 1 RU = 1 KB read, 5 RU per 1 KB write. Cosmos DB’s RU cost varies by consistency level and indexed properties. DynamoDB’s on‑demand charges per request unit, while Cosmos DB’s serverless (preview) charges per RU consumed. In general, DynamoDB is cheaper for simple key‑value workloads, while Cosmos DB may be more cost‑effective for complex queries and global distribution due to automatic indexing reducing the need for secondary indexes.

Ecosystem Integration

DynamoDB is deeply integrated with AWS (Lambda, API Gateway, Kinesis, CloudWatch, CloudTrail, IAM). Cosmos DB integrates naturally with Azure (Functions, Logic Apps, Event Hubs, Synapse, Power BI). Both offer change feeds and event‑driven triggers. The choice often comes down to which cloud provider your organization is invested in.

SLAs and Limitations

Cosmos DB offers comprehensive SLAs for latency (P99 <10 ms reads/writes under 1 KB), throughput (high availability), and consistency (for strong). DynamoDB advertises single‑digit millisecond latency and 99.999% availability for global tables, but does not offer a formal latency SLA. Cosmos DB also has a maximum storage per container of 20 TB (or unlimited with partition splitting), while DynamoDB has a 400 KB item size limit and 10 GB per partition hard limit (though you can scale partitions).

When to Choose Which?

  • Choose DynamoDB if: You are building on AWS, need a simple key‑value or document store with predictable low latency, have a clear access pattern (query primarily by primary key), and want to keep costs low at high scale. It’s ideal for gaming, IoT, session stores, and Lambda‑centric serverless backends.
  • Choose Cosmos DB if: You need multi‑model support (especially MongoDB or Cassandra API for migration), require multiple consistency levels, need active‑active multi‑region writes, or need rich query capabilities without upfront index design. It’s well‑suited for global enterprise apps, real‑time analytics, and polyglot persistence architectures.

DynamoDB Developer Guide | Cosmos DB Introduction

Best Practices for Serverless Database Adoption

Regardless of which database you choose, following proven patterns will help you avoid common pitfalls:

Design for Partitioning

In both DynamoDB and Cosmos DB, partition key design is critical. Hot partitions (where a single key receives disproportionate traffic) throttle throughput. Use high‑cardinality keys (e.g., user ID, device ID) and consider write sharding for sequential identifiers. In Cosmos DB, you can partition on the /partitionKey path; in DynamoDB, partition key is chosen at table creation.

Leverage Change Data Capture

Both DynamoDB Streams and Cosmos DB Change Feed enable event‑driven patterns. Use them to replicate data to search engines (Elasticsearch), build materialized views, synchronize with data warehouses, or trigger downstream processes. This reduces load on the primary database and decouples services.

Understand Your Consistency Needs

Serverless databases charge less for eventual consistency. Evaluate whether your application absolutely requires strong consistency. If eventual is acceptable, you can reduce costs and improve latency. For Cosmos DB, use session consistency for many e‑commerce or social media apps – it provides read‑your‑writes guarantees per client session at a lower RU cost than strong.

Use the Appropriate Capacity Mode

For DynamoDB, choose provisioned capacity with auto‑scaling for steady workloads and on‑demand for unpredictable spikes. For Cosmos DB, provisioned throughput with autoscale is good for most production workloads; consider serverless (preview) for dev/test or lightweight apps. Monitor consumed RUs and set alerts for throttle events.

Plan for Backup and Disaster Recovery

Both services offer point‑in‑time recovery (PITR). Enable it for all production databases. DynamoDB backup is continuous and restores to a new table; Cosmos DB backup can be continuous or periodic. Test restores periodically. For global DR, configure multi‑region replication (Global Tables or Cosmos DB multi‑region writes) and have a failover plan.

Cost Management

Track usage with cloud cost management tools (AWS Cost Explorer, Azure Cost Management). For DynamoDB, use reserved capacity for predictable throughput. For Cosmos DB, consider using serverless or autoscale to avoid paying for idle RUs. Remove unused indexes and tables. Use compression where supported (e.g., enabling compression in Cosmos DB’s analytical store).

Conclusion

Serverless databases like Amazon DynamoDB and Azure Cosmos DB have matured into enterprise‑grade platforms that empower developers to build globally scalable applications without operational burden. DynamoDB excels in simplicity, narrow query patterns, and deep AWS integration, making it a default choice for many serverless microservices. Cosmos DB offers superior flexibility with multi‑model support, tunable consistency, and comprehensive SLAs, catering to complex global applications and polyglot persistence needs. The right choice ultimately depends on your cloud strategy, data access patterns, and tolerance for operational complexity. By understanding each database’s strengths, limitations, and pricing models, you can design robust, cost‑effective systems that scale seamlessly with your business.

AWS Serverless Database Resource Hub | Azure Cosmos DB Product Page