How to Think in Access Patterns First With DynamoDB

If you’ve spent years building apps on relational databases, switching to DynamoDB can feel very strange.

I often tell folks to “forget everything you know” about relational databases.

Designing data on DynamoDB requires a very different mindset.

The biggest shift is that you don’t start with your data structure, you start with your access patterns.

Understanding this concept will catapult you ahead of most folks building with DynamoDB.

It’s a mindshift from “what data do I have?” to “how will users access my data”.

Let’s break this concept in this article.

SQL vs. DynamoDB: The Mental Model Shift

In SQL, you define your schema first and normalize data into tables:

• users
• posts
• comments
• likes
• shares

You then query across tables using joins to fetch the data you need. This flexibility is simultaneously SQL’s strength and performance bottleneck.

DynamoDB is drastically different.

You have to think differently.

You start with your use cases:

How your application will write/read data.

“What are the questions your application needs to answer”?

• Get all posts by a user within a specified date range
• fetch orders made by a user this month
• show a feed of user’s posts sorted by date published
• Get comments on a given post.

Each one of these are access patterns and you model your table around these patterns specifically.

Think in access patterns instead of queries

Instead of starting with:

“What tables do I need”?

Ask yourself:

“What queries will my app need to support for its users (at scale and performance)”

For example, imagine you are building a marketplace application.

Your app needs to:

• Show all listings by a seller
• Fetch a listing by its ID
• Display orders for a buyer
• Show order status by orderID

Those are your app’s main access pattern and each one needs to be efficient and satisfied with a single query operation.

Using the single table design pattern

DynamoDB’s performance comes (in part) from avoiding joins and sticking to primary key lookups.

This is why the single table design is the recommended approach.

In this design strategy, you store different entity types (e.g. users, posts, comments, likes) in the same table.

Each entity item is differentiated by a “PK” and “SK” composite key format. For example:

PK        | SK
-------------------------
user#101  | profile
user#101  | post#201
user#101  | order#303

This data model makes it easy to query the related data on your table with a single query.

You can also avoid joins and multiple queries.

If you’re curious about the single table design, I recommend this article.

How to get started with DynamoDB Design

Here’s a breakdown on getting started with your first DynamoDB database design process:

1. List every access pattern your app needs. (Don’t think about tables, just access patterns).
2. Group them by common entity or user context.
3. For each one, decide the ideal PK/SK structure that makes queries simple and efficient.
4. Identify where you’ll need GSIs to support alternate lookups. (For each access pattern add a “table” or “GSI1” in parentheses after it)
5. Once you’ve done all that, create a single table and store all your data on it. (read this article on how to do this)

Conclusion

Working with DynamoDB requires a large mindset shift.

Forget what you know about SQL and learn to embrace access patterns first. This will help you build systems that are faster, cheaper, and scale effortlessly.

The shift isn’t always easy, but it’s worth it and gets easier the more you work with DynamoDB.

👋 My name is Uriel Bitton and I’m committed to helping you master AWS, serverless and DynamoDB.

🚀 Build the database your business needs with DynamoDB — subscribe to my email newsletter The Serverless Spotlight

Thanks for reading and see you in the next one!