What are the key takeaways from this Full Stack Radio episode?

Key insights include: **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.

What did Alex DeBrie discuss on Full Stack Radio?

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 topics include: **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..

How long is this episode of Full Stack Radio?

This episode is 58 minutes long. SignalCast provides an AI-generated summary so you can get the key insights in about 3 minutes.

Full Stack Radio

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

Design & UX, 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?

Episode Transcript

In this episode of Fullstack Radio, I talked to Alex Debris all about DynamoDB from a relational database developers point of view. This is Fullstack Radio episode one thirty nine. You came on my radar because I was tweeting, maybe a couple weeks ago about basically wondering, like, what people are doing for, building applications with kind of non relational databases these days. I know, like, MongoDB has been popular for a long time, but you also hear horror stories about that and stuff as well. But me, personally, my background is just in old school traditional relational databases, you know, MySQL and Post gres, and that's all I really know how to build an application with. So, I've been getting into, like, serverless technologies and stuff a lot lately, and one of the sort of obstacles with that is there's not a lot of good relational database options if you want to deploy something serverless and you, don't wanna have to worry about running into the connection limits and weird stuff like that. All the databases that are sort of designed for handling that sort of thing are stuff like Dynamo or like Fauna DB or a lot of these other alternatives that aren't kind of built with, like, a traditional SQL sort of API. So, you were recommended as someone to to talk to you about this stuff, and I know you just put out a like, the bible on Dynamo DB a few weeks ago. So I thought it would be fun to to chat about that and learn about this technology from, you know, a total beginner's perspective, basically, who only knows the the relational world. How's that sound? Yep. That sounds great. That sounds great. I'm excited. So I guess maybe the, best place to start would be, how do you describe what DynamoDB even is? If someone was just gonna ask you, like, what is this thing for? What do you use it for? Yep. Sure. So it's a NoSQL database like you were saying and and that's not super descriptive because it basically just says what it isn't. Right? It's it's, like, not a relational database that that uses SQL. But you saw a lot of these sort of NoSQL databases popping up in the last ten or fifteen years. And one common thing about all these relational databases is, they were they were built for, like, larger scale, you know, like, as as these sort of, Internet enabled platforms are happening where you have, like, thousands or millions of of users around the world. You're finding out that, like, the single instance relational database just wasn't keeping up, as well. So police have started building these NoSQL databases. And I think one thing that's in common with most of these NoSQL databases is that they they shard your data across multiple instances. So rather than having, like, this one monolithic database, you know, your your MySQL instance, your Postgres instance, you'll have, …

Get the full transcript (12,493 words) + summary by email — free

One-time email with the complete transcript and AI summary of this episode. No account needed.

One email, no spam. We’ll also show you what SignalCast does.

Browse all Full Stack Radio transcripts →