AWS Build Diaries: From Table Chaos to One-Table Zen with DynamoDB

[pearlwilson]

Are you using DynamoDB wrong? Let's fix that.

Spoiler alert: I was.

My experience with DynamoDB:

When I first started using DynamoDB, I treated it like any other database that I had used before. Tables? Primary Keys? Got it. I started creating multiple tables. Every time I would need new data, I just create another table. Soon it was a mess, multiple tables, no joins. I had to do multiple trips to retrieve data from multiple tables. My lambda function code used to retrieve data was practically unreadable by any other developer and queries were inefficient. Everything fell apart quickly.

And then, I came across the Amazon developer guide and had a proper face palm moment. It laid out clear best practices, but by then, it was too late. I’d need to blow up everything - tables, Lambda functions, and all the Terraform IaC that glued it together. But as the saying goes, you learn through failure. I systematically started designing my tables according to the recommended DynamoDB design, and after a frustrating few days, came to the realization that DynamoDB doesn’t reward SQL thinking, it punishes it.

Let me show you what I did wrong, and how you can avoid making the same mistakes.

How I designed it the wrong way (SQL Style):

I was tasked with building a cloud-sizing tool and I wanted to store different T-shirt size configurations for various infrastructure setups. Small clusters, Large clusters, different node types, etc. So naturally, I created multiple tables, for each sizing category.

I also had separate tables for DevSizing, BareMetalSizing and so on. Technically, this design follows all the Four Normal Forms(1NF->4NF, Atomic Values, full functional dependency on the Primary Key, no transitive dependency and no multivalued dependencies)

What went wrong?

• I couldn’t query all size options across types – not without scanning every table.
• Searching for given size across cluster types? Not possible.
• You need to create new tables to add new sizing types. Over the next few sprints, multiple sizing types were added, each type required additional Jira points for both table creation and lambda code modifications.
• Managing the code was painful, every access pattern required a different logic.

All of this because according to my logic:

“ONE ENTITY = ONE TABLE”

This made sense to me in a relational world, but in DynamoDB this turned into a rigid mess.

The shift I made to fix my mess:

DynamoDB isn’t about “how your data is stored.”, it’s about “how your data is accessed.”

Instead of splitting sizes into multiple tables, I needed to combine them using Partition Keys (PK) and Sort Keys (SK) to represent relationships and filter easily. Once I realised DynamoDB isn’t just a “table with no joins”, but a query-first, access-pattern-first database, I completely changed my approach to modelling.

Instead of treating ExistingSizing, NewSizing, DevSizing, BareMetalSizing, and others as separate tables, I unified them into a single DynamoDB table with smartly chosen PK (Partition Key) and SK (Sort Key) values to support the exact queries I cared about.

Design Principles Used:

• PK: Category or logical grouping (ExistingSizing, NewSizing, DevSizing, BareMetalSizing)
• SK: Composite string that encodes filterable/searchable attributes like size label, cluster type. In the above example SK is #size_label#cluster_type.
• A core misunderstanding: You would be wondering why two keys, PK and SK exist. DynamoDB offers two types of Primary Keys:

1. A single Primary Key: The Partition Key (PK) needs to be unique.
2. A composite Primary Key: The combination of the Partition Key and the Sort Key (like we have used in the above example) needs to be unique. If you check the above example, you will find that, PK on its own is not unique, but the combination of PK and SK is unique. Here, Primary key = PK + SK

         Why this design works:

• Single table: I can avoid expensive scans and joins to multiple tables.
• Better Filters: I can use specific filters for each type of sizing and get my output with a single query. (example: WHERE PK = 'ExistingSizing')
• Fewer queries
• Stay Flexible as product grows
• Cost Saving: Less tables

Final Thoughts:

DynamoDB is fast, scalable, and powerful, but only if you unlearn SQL habits and embrace access-pattern-first design. Once I did that, my model became:

• Simpler and faster
• Cleaner and easier to maintain
• Actually fun to work with

If you are hitting performance issues or wondering why DynamoDB “feels hard”, maybe you are using it wrong too.

Time to fix that.

Note and Reference:

• Data displayed here is sample data and not real data
• AWS Developer Guide: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html

[RajKanango]

Your use case is clear-cut, providing substantial value to novice DynamoDB users. Also, by applying RDMS concepts, we can boost performance through the use of partition scans, avoiding full scans.