139: Alex DeBrie - DynamoDB for Relational Database Diehards

May 8, 2020

58 min episode · 2 min read

Alex DeBrie

Episode

58 min

Read time

2 min

Topics

Software Development, Science & Discovery

AI-Generated Summary

Published Dec 25, 2025

Key Takeaways

✓Single-table design: Store multiple entity types (customers, orders, order items) in one table using generic attribute names like PK and SK, with type prefixes (CUSTOMER#, ORDER#) to enable efficient queries within partition boundaries.
✓Composite primary keys: Use partition key to locate data across shards and sort key to organize items alphabetically within partitions, enabling range queries like fetching a customer plus their 10 most recent orders in one request.
✓Access pattern planning: Design table structure before implementation by listing all query patterns upfront, then arrange data to satisfy those patterns, since DynamoDB cannot perform joins or query arbitrary attributes without secondary indexes.
✓Pagination strategy: Implement cursor-based pagination using last-seen item identifiers in query parameters (like GitHub's after=commit-hash approach) rather than page numbers, since DynamoDB does not support offset-based queries across partitions efficiently.

What It Covers

Alex DeBrie explains DynamoDB architecture, data modeling, and query patterns for developers with relational database backgrounds, covering partition keys, sort keys, single-table design, secondary indexes, and serverless integration strategies.

Key Questions Answered

•Single-table design: Store multiple entity types (customers, orders, order items) in one table using generic attribute names like PK and SK, with type prefixes (CUSTOMER#, ORDER#) to enable efficient queries within partition boundaries.
•Composite primary keys: Use partition key to locate data across shards and sort key to organize items alphabetically within partitions, enabling range queries like fetching a customer plus their 10 most recent orders in one request.
•Access pattern planning: Design table structure before implementation by listing all query patterns upfront, then arrange data to satisfy those patterns, since DynamoDB cannot perform joins or query arbitrary attributes without secondary indexes.
•Pagination strategy: Implement cursor-based pagination using last-seen item identifiers in query parameters (like GitHub's after=commit-hash approach) rather than page numbers, since DynamoDB does not support offset-based queries across partitions efficiently.

Notable Moment

Amazon requires all tier-one services (those whose downtime costs money) to use DynamoDB exclusively, demonstrating how the retail giant handles complex relational models like shopping carts and customer data at massive scale without traditional databases.

Know someone who'd find this useful?