How do you choose a serverless database on AWS?

Write the data requirements before comparing services

List entities, relationships, read and write patterns, consistency, transaction boundaries, query flexibility, latency objectives, throughput shape, data size, retention, recovery, regional needs, and compliance controls.

The word serverless describes infrastructure management, not a universal data model. A service can scale automatically and still be wrong for joins, hot keys, connection behavior, query variability, or recovery objectives.

Choose DynamoDB for key-oriented scale

DynamoDB fits workloads whose access patterns can be expressed through primary keys and indexes and which benefit from managed horizontal distribution. Conditional writes, transactions, streams, time to live, backups, and global tables support many operational application patterns.

The design cost is upfront modeling. Unplanned ad hoc queries, concentrated partition keys, oversized items, and unclear index strategy can undermine an otherwise scalable service.

Choose Aurora Serverless for relational behavior

Aurora Serverless v2 automatically adjusts database capacity within configured bounds while retaining Aurora's relational engine, SQL interfaces, transactions, joins, indexes, and schema constraints.

It remains a database cluster with connection, query, transaction, schema migration, minimum capacity, backup, and failover considerations. Autoscaling capacity does not make inefficient queries or excessive connections disappear.

Prototype the hardest access and failure paths

Model the most demanding transaction, query, traffic burst, migration, and restore for each credible option. Measure integrated latency and cost with representative data rather than comparing headline features.

Polyglot persistence can be correct when boundaries are explicit—for example, DynamoDB for operational state and S3 for objects—but every additional store adds consistency, security, backup, and operator responsibilities.