The 5 Most Common Mistakes Developers Make In DynamoDB

If you're coming from SQL you are most probably making these mistakes, here's how to fix them.

Article cover image

DynamoDB isn’t a relational database.

Neither is it document-oriented, like many NoSQL databases.

This is why most developers coming from other database systems often make these mistakes.

I’ve seen many implementations of DynamoDB tables and many of them had one of these design mistakes or bad practices.

These mistakes directly lead to suboptimal performance, higher latencies, and critical scalability issues.

Hopefully by seeing these I can help you avoid them and design better DynamoDB tables in the future.

1. Normalizing Data 

With SQL you almost always want to normalize data and rarely denormalize it.

This is because traditionally relational databases placed an emphasis on optimizing storage. More normalization means less storage costs, amongst other benefits.

DynamoDB, on the other hand, is designed for denormalized data structures. 

If you normalize your data, you’ll need to make multiple queries to retrieve related information. This adds complexity to your application and will significantly slow down performance.

Instead, denormalize data even if it means duplicating some information.

A general rule of thumb is: for data that changes less frequently, go for denormalization. If your data changes more frequently, find an efficient batch update strategy.

One other remedy for this is the single table design, you can check out all the details here.

2. Misunderstanding Primary Key Design

In SQL databases, primary keys are simple, unique identifiers (e.g. userID or postID). 

When using DynamoDB, developers tend to use the same design principle with DynamoDB primary keys. 

The issue is that the purpose of primary keys in DynamoDB is not only about uniqueness.

Primary key design is crucial for scalability, low latency, and query efficiency.

A well-designed primary key in DynamoDB is one that is based on a data access pattern. 

Good primary (partition) keys provide high cardinality — which is responsible for efficient and low latency data retrieval, while bad primary keys cause hot partitions (concentration of too many concurrent reads and writes on the same partition).

Hot partitions lead to throttling and degrade performance.

Instead, learn how partition and sort keys work. 

Learn how primary key design impacts querying efficiency in DynamoDB and how it is different than in SQL.

If you want to learn more about proper primary key design, you should check out this article. 

I go into greater detail on how to design the most efficient primary keys with real examples.

3. Using Filters Instead of Indexes

One of the most common mistakes developers make with DynamoDB is relying too much on filter expressions to filter results of queries.

Many developers assume the filtering is applied in the same way as SQL databases.

But filtering work much more differently in DynamoDB. 

When using FilterExpressions, DynamoDB retrieve all items that match the query, and then applies the filter after the items have been fetched.

This means that the costs will still be as high as the same query with no filters. The latency of the query with the filtering will also be the same, following this logic.

What is the more efficient alternative to FilterExpressions?

Using good sort key design with secondary indexes.

DynamoDB lets you create secondary indexes to query your table data but by using a different partition and sort key. By manipulating the sort key and carefully designing it, you can achieve powerful and highly efficient filtering of data.

To understand how this can be implemented, you can read this article.

4. Ignoring DynamoDB’s event-driven nature

Don’t treat DynamoDB as a static database purely for storing and retrieving data without taking advantage of its event-driven features.

With DynamoDB Streams, you can enable powerful event-driven architectures. 

Streams allow you to capture real-time changes such as inserts, updates, and deleting of data. This makes your database more dynamic and responsive.

You can leverage event-driven workflows for various use cases. 

For example, when an order is placed in your system, a DynamoDB stream can trigger a serverless function that sends a notification or email using other services.

Learn more about DynamoDB streams and how to use them here.

5. Overusing Multi-item transactions

In relational databases, transactions are commonly used to ensure consistency across tables or rows. Sometimes developers overuse transactions with DynamoDB.

While DynamoDB does support ACID transactions, it isn’t designed for frequent and complex multi-item transactions like in SQL.

Using transactions too frequently can lead to performance issues and increased costs.

Instead, you should model your data to minimize the need for transactions.

Aim to design your data in such a way that operations can be done on a single item or a small set of related items. 

This is most commonly done by denormalizing data or again by using the single table design to combine multiple related entities in one table. 

For example, instead of using a transaction to update an order in one table and a user in another table, combine both of these entities in one table. This will allow you to update the data in one single atomic operation. 

Conclusion

Designing and querying data with DynamoDB requires a different mindset compared to relational databases.

By avoiding these 5 common anti-patterns — normalizing data, SQL primary key design, over-relying on filters, ignoring event-driven capabilities, and overusing transactions, you can make much more efficient use of DynamoDB. 

If you’re guilty of making these mistakes, it's not too late to go in and start fixing them and benefit from the full potential of DynamoDB.

---

👋 My name is Uriel Bitton and I’m committed to helping you master Serverless, Cloud Computing, and AWS.

🚀 If you want to learn how to build serverless, scalable, and resilient applications, you can also follow me on Linkedin for valuable daily posts.

Thanks for reading and see you in the next one!