DynamoDB Aurora
tl;dr: Choose DynamoDB to prioritize Scale and/or Operational Simplicity tl;dr: Choose Aurora to prioritize Features and/or Dynamic Queries
DynamoDB is a distributed key value store with one Primary Partition Key, an optional Secondary Sort Key, and Global Secondary Indexes Aurora is a fully managed relational database engine that's compatible with MySQL and PostgreSQL featuring a a high-performance storage subsystem.

Both databases provide a similar set of core features:

  • Transactions (ACID) - Both DynamoDB and Aurora support multi-document ACID transactions.
  • Available - Both DynamoDB and Aurora store at least 3 copies of all data across multiple availability zones.
  • Consistent - Both DynamoDB and Aurora support serializable isolation for transactions and strongly consistent reads/writes.
  • Serverless - Both databases support being consumed from Lambda functions (although DynamoDB is preferred due to IAM simplicity and lack of VPC cold starts)
  • Automatic Backups - Both DynamoDB and Aurora support both continuous point-in-time backups for up to 35 days as well as on-demand snapshots.

DynamoDB provides the following advantages:

  • No write scaling bottlenecks - Assuming a good partition key, DynamoDB reads and writes can scale forever.
  • Automatic Auto Scaling - DynamoDB supports paying per request on-demand or read/write capacity auto scaling.
  • No Connection Limits - DynamoDB does not have a concept of maintaining a connection (because it uses HTTPS), thereby supporting unlimited clients.
  • Centralized Configuration - All DynamoDB configuration is codified using AWS APIs, meaning that configuration and index creation is done in the resource definition.
  • Streaming APIs - DynamoDB Streams supports streaming all changes to a log (similar to a Kinesis Stream).
  • IAM Permissions - Applications can authenticate automatically using IAM instance profiles removing the need for user management.
  • The end of upgrades - All versions of DynamoDB are the same, meaning there never need to be failovers for upgrades or concerns that an upgrade may break something.
  • Multi-Region - DynamoDB Global Tables supports writes across multiple regions (but not transactions).
  • DAX - DynamoDB features a fully managed, automatically invalidating cache called DAX which can speed reads by an order of magnitude.

Aurora provides the following advantages:

  • Features, Features, Features - MySQL and PostgreSQL have far more features like search, joins, complex queries/types, views, rules, aggregations and more.
  • Dynamic Queries - MySQL and PostgreSQL support more dynamic queries than DynamoDB, primarily because all data lives on a single host. If you ever want to change your query pattern, you can always add another index to an existing table, or use foreign keys to create a new table and query with a JOIN.
  • Unlimited Transaction Size - MySQL and PostgreSQL do not have a row maximum for transactions (but may have very large size limitations).
  • Consistent by Default - MySQL and PostgreSQL reads are consistent by default (although reads sent to an Aurora read replica are not consistent).
  • Foreign Key Constraints - MySQL and PostgreSQL support consistency across multiple tables via foreign key constraints.

DynamoDB carries the following disadvantages:

  • Less Flexibility - DynamoDB requires sound up-front schema decisions because changing the primary key requires a migration. However, to support new access patterns beyond your primary partition key, you can add Global Secondary Indexes later, but lose consistency guarantees on reads through those indexes.
  • Secondary Index Consistency - DynamoDB's global secondary indexes are eventually consistent, they are essentially async replicated tables.
  • Size Limitations - DynamoDB items are limited to 400KB per item (item is analogous to "row" in a relational DB, so all columns including key names need to fit within this limit).
  • Small Transactions - DynamoDB transaction blocks cannot be larger than 10 operations or 4MB.

Aurora carries the following disadvantages:

  • Write Scaling - Aurora allows for up to 16 read replicas but writes and consistent reads can only be made from the primary replica. Vertically scaling (increasing the instance type) of the primary replica is the only way to improve write capacity.
  • Connection Limits - Aurora is limited to at most 6000 connections on the largest instance size. Any connections beyond this amount would require a connection pooler like PgBouncer.
  • Multi-Region Writes - Aurora does not support multi-region writes. Aurora MySQL does support multi-region replicas.
  • No Streaming - Aurora does not yet support streaming data (ie "change sets" or "streams").

Helpful resources for DynamoDB

Helpful resources for Aurora