Designing a Blog App Using The Single Table Design With AWS DynamoDB

How you can leverage the powerful single table design approach to create the database for a blog app, with a very easy to understand example.

Courtesy of Unsplash.com

The single table design is a design pattern in key-value databases made popular by AWS DynamoDB and invented by Rick Houlihan.

It is the recommended approach to designing your tables in DynamoDB and has received much praise, albeit some criticism from users who haven’t fully learned how it works.

A Brief History on SQL & noSQL Databases

Traditionally developers worked with relational databases and performed joins to get related data in a single query. This worked great until we realized joins are slow and CPU intensive.

The affected latency drove database engineers to look for a more optimal solution, one that would dramatically reduce latency by removing joins completely.

From these efforts, noSQL was born and perfectly addressed the latency issue. With storage costs and capabilities not being a concern anymore in this day and age, noSQL became rapidly adopted by modern database teams and businesses.

Naturally, the ancient practices of relational databases stuck with database developers through noSQL databases.

Practices such as data normalization and having one table per entity was and remains a concept most developers are highly accustomed to from their days of relational databases.

Unfortunately this has led to consequences especially with key-value pair databases like DynamoDB. While offering single digit latency at any scale, DynamoDB tables can quickly become costly.

In one his workshops, Rick Houlihan mentions how he helped dozens of customers save enormous amounts on costs simply by moving from multiple table designs to the single table design.

The Motivation Behind The Single Table Design

Having multiple tables, one per data entity, is a common practice for relational databases. But with noSQL key-value databases the same best practices don’t apply.

DynamoDB has costs attributed for each table you create and the higher the throughput capacity you provision, the higher the costs are.

In a typical database, developers can create anywhere from from 5 to 20 tables that stores each their own data entities. Calculating the cost of a few dollars by 20 tables goes well into the hundreds of dollars. But keeping a single table for all your entities reduces the hundreds or even thousands of dollars down to double or triple digits, realistically cutting down thousands of dollars each month.