My Personal Take

The good: It's a managed service that has the ability to auto-scale to different workloads so you're paying for what you're using (cheaper). Plus it's theoretically quicker as you don't have to join disparate datasets, it now all comes from the same partition.

The bad: A steep learning curve, combined with vendor lock and aggregations that have to be performed somewhere else, ie AWS Lambda. The marketing around scaling I don't buy and if I did run into scaling problems I'd be looking at Vitess before DynamoDB.


A good summary of what DynamoDB is and isn't. From what I understood it's got a steep learning curve for those coming from RDBMS's, a pain to integrate into analytics platforms and doesn't jell well with GraphQL. On the other hand, it's managed, "supposedly" cheaper and has excellent performance and scaleability.


  1. Use a high cardinality value for a partition key, ie "CustomerID"

  2. The sort key represents a 1:n or n:n relationship, ie "Orders" or "OrderItems"

  3. 1 application service = 1 table

  4. Using GSI's can enable a lot more accses patterns.

  5. NoSQL aka DynamoDB suited for OLTP and DSS.

  6. RDBMS suited for OLAP when scale isn't a concern.