DynamoDB vs Aurora: When to Choose NoSQL or SQL

Choose DynamoDB when application requests fit known key-based access patterns and you want managed partitioning with request-based on-demand billing. Choose Aurora MySQL or Aurora PostgreSQL when joins, relational constraints and SQL transactions are central to the application. Aurora Serverless v2 scales relational compute automatically; Aurora DSQL is a separate distributed SQL service and needs its own compatibility review.

Shared attributes and the main difference

DynamoDB and Aurora are managed operational databases. AWS manages the underlying infrastructure, but application teams still own access control, data modeling, query efficiency and recovery testing. Automatic scaling does not make a poor query or overloaded key disappear.

Amazon Aurora provides MySQL- and PostgreSQL-compatible relational engines. Existing SQL clients and applications can often retain familiar interfaces, subject to engine and feature compatibility. DynamoDB uses its own APIs and a key-value/document model.

Structured data alone does not require Aurora, and JSON alone does not require DynamoDB. An order can be represented in either system. The deciding questions are how the application retrieves related data, enforces invariants and evolves its queries.

DynamoDB vs Aurora at a glance

Latency and performance

DynamoDB

DynamoDB fits small, focused requests such as fetching a cart, updating device state or listing orders under a customer key. Efficient access depends on the primary key and secondary indexes. It does not promise the same latency for every scan or arbitrarily large result.

A denormalized model can retrieve related entities efficiently, but the application then owns how copies stay consistent. Adding a new query may require another index or a different item layout. Use data modeling to test the access patterns before choosing the database from peak-throughput marketing figures.

Aurora

Aurora fits workloads that naturally use joins, relational constraints and transactions across related tables. Query plans, indexes, lock contention, connection counts and memory all affect latency. A simple indexed lookup can be fast, while an unbounded join can still be expensive.

For an order-management system, Aurora can keep customers, orders and line items in separate related tables and query them with SQL. For a service that always reads a complete order by ID, DynamoDB may need fewer application and database operations. Benchmark the actual endpoints, including concurrent updates and failed transactions.

Claims that Aurora is a fixed multiple faster than another database are benchmark-specific. They do not predict your workload, and they are not a useful reason to move an application whose query shape has not been measured.

Scaling: provisioned Aurora and Serverless v2

DynamoDB offers on-demand and provisioned capacity. On-demand avoids specifying throughput in advance, while provisioned capacity can fit predictable demand. Both have quotas, warm-throughput behavior and hot-key considerations.

Aurora Serverless v2 adjusts compute capacity to application demand. It retains the relational engine and connection model. You choose a capacity range and monitor whether the application reaches the maximum or spends most of its time at the minimum.

Supported engine versions can scale to zero ACUs and auto-pause when idle. This is conditional on configuration and workload behavior; persistent connections and incompatible features can prevent pausing. Resuming also affects the first request after an idle period, and storage charges continue while compute is paused.

Provisioned Aurora remains useful when explicit instance sizing fits the workload. Readers can scale eligible read traffic, but read scaling and write scaling are different problems. Do not assume that adding readers increases the writer's transactional capacity.

Aurora storage grows automatically within the applicable engine limits. The current overview lists cluster volumes up to 256 TiB. Check engine/version support and other Aurora cluster characteristics before using a maximum as a sizing target.

Consistency, durability and availability

DynamoDB replicates data across Availability Zones within a Region. Strongly consistent table reads can retrieve the latest committed value; global secondary indexes remain eventually consistent. DynamoDB transactions are available within an account and Region, subject to their size limits and the MRSC restriction.

Aurora separates compute from distributed storage and supports reader instances and failover. Route writes and correctness-sensitive reads to the appropriate endpoint. Reading a replica is not automatically equivalent to reading the writer immediately after an update.

For multi-Region deployments, compare DynamoDB global tables with the chosen Aurora replication architecture. DynamoDB global tables offer eventual and strong consistency modes with different restrictions. Aurora Global Database is an Aurora feature, not another name for DynamoDB global tables. Define recovery objectives and test application routing rather than inferring failover guarantees from either product name.

What about Aurora DSQL?

Aurora DSQL is a serverless distributed relational database with PostgreSQL compatibility and an active-active architecture. It belongs in the evaluation when you need relational transactions and distributed operation without managing conventional database instances.

It is separate from an Aurora PostgreSQL cluster using Serverless v2. Its PostgreSQL compatibility documentation describes supported features and differences. Test SQL, extensions, transaction behavior and application retry handling rather than treating it as a configuration toggle or a fully interchangeable PostgreSQL server.

This makes a simple SQL-versus-serverless decision misleading. DynamoDB, Aurora Serverless v2 and DSQL can all reduce infrastructure work, but they expose different data models, transaction semantics and cost units.

Security

DynamoDB encryption at rest is always enabled. Its AWS owned, AWS managed and customer managed key options provide different levels of key control and billing. IAM and resource-based policies govern table and stream access.

Aurora runs within a VPC and uses security groups plus database-level authentication and permissions. SQL connection access and AWS permission to modify a cluster are separate controls. Encrypt connections and manage credentials using the supported authentication mechanisms for the chosen engine.

Aurora encryption at rest uses KMS keys. Declare encryption, network boundaries and recovery settings explicitly in infrastructure code. A managed service still requires a deliberate authorization model for application users and administrators.

Backups and restore

DynamoDB supports on-demand backups and PITR with a configurable 1-to-35-day window. PITR restores to a new table; it is not an in-place undo button for the current application table.

Aurora automated backups are continuous and incremental with a configured retention period. Snapshots support retention beyond that window, and restoring creates a new cluster. A backup window is not the same thing as the period of history you can recover.

For either service, rehearse recovery through application cutover. Check credentials, endpoints, indexes, dependent consumers and the consistency of external side effects. A backup can recover database state without undoing an email already sent or a payment already submitted.

Pricing

DynamoDB pricing combines requests or provisioned throughput with storage and optional features. Item size, consistency, indexes, transactions and replication affect usage. The pricing calculator helps compare a realistic workload.

Aurora pricing depends on engine, provisioned or Serverless compute, storage, backup and additional features. Standard and I/O-Optimized configurations treat database I/O differently. Include readers and any connection proxy, cross-Region replication or data transfer in the estimate.

Compare the whole application rather than storage rates alone. Serverless auto-pause can reduce idle compute cost where supported, but a sustained SQL workload has a different profile from sporadic DynamoDB item requests. Neither service is automatically the economical option based on company size.

When to use each, or both

Use DynamoDB for well-defined high-volume access patterns such as sessions, carts, player state and device status. Use Aurora when relational queries, constraints and SQL workflows are central, or when retaining a compatible relational application avoids a major rewrite.

A combined architecture can keep relational business records in Aurora and a derived high-volume read model in DynamoDB. Alternatively, independent services can own separate datasets. In either case, avoid uncontrolled dual writes: define ownership, update propagation, retry behavior and reconciliation. The databases do not share one atomic transaction.