Frame from AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) Plays with YouTube's privacy-enhanced embed

AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401)

Amazon Web Services Talks advanced
Open on YouTube First HN thread

12 HN users recommended this talk in 9 different months between 2019 and 2025.

2007–2026
7 strong recommendations 5 recommendations 4 citations HackerTube score 11.5

The go-to recommendation for learning DynamoDB data modeling, with many saying it made access-pattern-driven design click.

Rick Houlihan's AWS re:Invent 2018 deep dive on advanced DynamoDB design patterns. It covers index overloading, GSI sharding, composite keys, graph processing and transactions.

Pull quote: “I highly recommend every engineer to watch it: it's a great overview of SQL vs NoSQL” (HN, 2022)

Also tagged: dynamodb data modeling, dynamodb, nosql, single-table design, aws, reinvent

What Hacker News said

16 labeled comments from the HN archive; up to 20 are kept per video, favoring different commenters. Each one links back to the original thread.

Strongly recommends gigatexal September 2019 under Designing database: split into different tables or group them together?
Talk on creating a DynamoDB schema around access patterns
If you go single table you can use filtered indexes if your database supports it to speed up queries instead of having to do a row by row search with a where clause. Personally this seems like a job for DynamoDB but that’s a whole beast unto itself. You must know the queries you will do to the database before hand as that guides how you craft it. There’s an amazing talk at reinvent that is given almost every year on creating a DynamoDB schema ( [this video] ) I would normalize as the theory says and then denormalize as performance requires it.
View on Hacker News
Strongly recommends tmsh September 2019 under Ask HN: Resources for Learning about Databases
Talks on DynamoDB, relational history, and access-pattern oriented design
AWS re:invent 2018 talks: [this video] He has a sequence of 2-3 great talks on DynamoDB, the history of relational databases and the rise of access-pattern oriented db design.
View on Hacker News
Strongly recommends kbanman March 2020 under The good parts of AWS: a visual summary
Explains modeling relational data efficiently in key-value stores
I've seen this done for new projects, and it works really well. If your data access patterns are truly relational (varied lookup paths) then it is probably not the right tool, but many apps can be modeled in a way that DDB handles well. Highly recommended viewing: [this video] this talk explains how relational data can be efficiently modeled for key-value stores.
View on Hacker News
Strongly recommends artembugara January 2022 under DynamoDB 10 years later
Great overview of SQL versus NoSQL by Rick Houlihan
We realized how great Dynamo was only after we migrated off AWS. Dynamo was a key factor to us when we were releasing the MVP of our News API [0]. We used Dynamo, ElasticSearch, Lambda and could make it running in 60 days while being full-time employed. Also, the best tech talk I saw was given by Rick Houlihan on re:Invent [1] I highly recommend every engineer to watch it: it's a great overview of SQL vs NoSQL [0] [link] [1] [this video]
View on Hacker News
Strongly recommends mabbo July 2022 under The DynamoDB Paper
Talk that wows Amazon engineers with DynamoDB data layer design
Read the full comment
Rick Houlihan did a talk a few years ago about designing the data later for an application using dynamodb. The most common reaction I get from people I show it to- most of them Amazon SDEs who operate services that use Dynamodb- is "Holy shit what is this wizardry?!" [this video] One of the biggest mistakes people make with dynamo is thinking that it's just a relational database with no relations. It's not. It's an incredible system, but it requires a lot of deep knowledge to get the full benefits, and it requires you, often, to design your data layer very well up-front. I actually don't recommend using it for a system that hasn't mostly stabilized in design. But when used right, it's an incredibly performant beast of a data store.
View on Hacker News
Strongly recommends ronjouch July 2022 under The DynamoDB Paper
Excellent talk, revelatory about using DynamoDB well
For explicitness & searchability, commenting with the title of this talk, which is indeed excellent , not limited to DynamoDB, and which was kind of a revelation after years of using DynamoDB suboptimally: Rick Houlihan - AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) , [this video] It should be watched along with reading the associated doc: [link]
View on Hacker News
Strongly recommends sass_muffin August 2022 under Some notes on DynamoDB 2022 paper
Go-to video for learning DynamoDB modeling
This is the video I recommend to others when working with dynamodb. The video is by Rick Houlihan about dynamodb modeling. In my experience most developers that complain about dynamodb don't fully understand it. [this video]
View on Hacker News
Recommends dalailambda February 2019 under Google Cloud Firestore NoSQL database is in GA
Teaches modeling relational data in DynamoDB
While the move seems to be towards NewSQL databases (Spanner/CockroachDB), the answer to relations in NoSQL is to model the data differently. This can generally resolve a lot of the problems inherent in the need for relations. This might not be useful advice for everyone, but I can highly recommend this youtube video on DynamoDB data modelling: [this video]
View on Hacker News
Recommends forgingahead December 2020 under Building a scalable e-commerce data model
Video on NoSQL data modeling tradeoffs
If I may share some advice - don't bother. As another commenter pointed out, relationships are inherent in a lot of the data you'll store for your platform, and for those elements that you'd like to keep the full data hash, just use jsonb in Postgres. Once you're at several million in revenue, then you can think about splitting off some parts of your data into document storage solutions for certain efficiency reasons, but that is by no means necessary. This is a great video on the topic: [this video]
View on Hacker News
Recommends unfunco January 2022 under DynamoDB 10 years later
Watching it several times made DynamoDB design click
I struggled at first but I watched Advanced Design Patterns for DynamoDB[0] a few times and it clicked. As other responses have suggested, generally you define your access patterns first and then structure the data later to fit those access patterns. [0]: [this video]
View on Hacker News
Recommends belter January 2025 under Distributed Transactions at Scale in Amazon DynamoDB (2023)
Starting point for understanding DynamoDB design
My name is Marco Inaros! > What kind of system/application/query pattern does DynamoDB optimize for Start here: "Real-world use cases for Amazon DynamoDB" - [link] > I'm legitimately ignorant and a lot of people seem to dislike it. Start here: "AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB " - [this video] Then: "Build with DynamoDB | S1 E5 – A Data Modeling Use Case Deep Dive" - [link] "Model hierarchical automotive component data using Amazon DynamoDB" - [link] "AWS re:Invent 2024 - Advanced data modeling with Amazon DynamoDB" - [link]
View on Hacker News

Citations, criticism and jokes

Cites it abd12 April 2020 under Rules for Data Modeling with DynamoDB
Lists Rick Houlihan's yearly re:Invent DynamoDB talks
Rick has had the most-watched re:Invent talk the last three years. Here are the links for each: - 2019: [link] - 2018: [this video] - 2017: [link] Additional DynamoDB links here: [link]
View on Hacker News
Cites it isbvhodnvemrwvn May 2021 under A minimalistic Python wrapper to AWS DynamoDB
Shows how keys can handle relational data in DynamoDB
The issue is that the keys can be used to various extent to handle relational data (this re:Invent video shows this well: [this video] ). What people miss though is that in order to not shoot themselves in the foot, you have to have stable, known access patterns which meet the constraints of DynamoDB. Even the documentation of DynamoDB says so: [link] This means that it's a good use case for shopping cart of Amazon since there's limited innovation possible there and it fits the bill nicely, but for a new application with relational data where the requirements change all the time - it's a terrible, terrible choice for which you will pay dearly.
View on Hacker News
Cites it belter January 2022 under DynamoDB 10 years later
Lists Rick Houlihan's DynamoDB talks across years
Read the full comment
You never heard of Rick Houlihan? He is the 90% of DynamoDB Evangelism... At the same time you are able to this internal lookups? Do you work with DynamoDB? AWS re:Invent 2018: Amazon DynamoDB Deep Dive: Advanced Design Patterns for DynamoDB (DAT401) [this video] AWS re:Invent 2019: [REPEAT 1] Amazon DynamoDB deep dive: Advanced design patterns (DAT403-R1) [link] AWS re:Invent 2020: Amazon DynamoDB advanced design patterns – Part 1 [link] AWS re:Invent 2020: Amazon DynamoDB advanced design patterns – Part 2 [link] AWS re:Invent 2021 - DynamoDB deep dive: Advanced design patterns [link] Amazon DynamoDB | Office Hours with Rick Houlihan: Breaking down the design process for NoSQL applications [link]
View on Hacker News
Cites it Zanfa December 2023 under How Pinterest scaled
Describes single-table data design
I think they're referring to single-table data design as described in [this video] It's quite clever and scales well, but completely unnecessary for the vast majority of CRUD apps.
View on Hacker News

Keyboard shortcuts

/
Search
j k
Next / previous video in a list
Enter
Open the focused video
l
Like (on a video page)
w
Watch later (on a video page)
?
This help
Esc
Close