How to Crater Your Database, Part Five - Summary

and why DynamoDB is different

Jun 30, 2025

Part One
Part Two
Part Three
Part Four
Part Five ←

We are at the end of this whirlwind tutorial on turning your database into a smoking hole in the ground. Along the way, we discussed:

If you need to scale, predictability is paramount (Part one).
COUNT and JOIN don't scale. With poor scalability, your best customers will perform worse. This is a bad business model (Parts two and three).
You don't need airtight consistency. Watch out for excessive SQL transactions, and don't integrate at the data layer (Part four).

DynamoDB is different

Although I've mentioned it throughout, this post emphasizes that DynamoDB is different. It doesn't perform many of the functions that a SQL database can, and this is intentional. DynamoDB can scale predictably.

I've given examples of these differences throughout this series of articles. If you've worked with SQL before, all the examples should be familiar; they are commonly used. When I first point out the problems with things like aggregations, joins, or heavy transaction use, I get looks of surprise. Nobody has ever advised them against doing those things.

I have a colleague who, during discussions about this topic, asked me, "If you're going to avoid all the things that don't scale well in SQL, why don't you just use DynamoDB in the first place?" This is the point of my summary today.

You can use SQL more effectively than you do today and achieve fast, predictable scaling, but you will have to remain eternally vigilant for non-scalable actions creeping back in. A junior dev will reach for a COUNT without a second thought, and you'll have to scrutinize every commit to ensure it doesn't happen.

Or, you can learn the basics of DynamoDB and let its built-in guardrails keep your applications scalable as you build. As Alex DeBrie wrote, "DynamoDB won't let you write a bad query," where "bad query" is defined as a "query that won't scale."1 Think of this as a "pit of success" where it is easy to do the right things and annoying to do the wrong things.2

I didn't even get into all the other benefits of DynamoDB: it is fully managed (no servers to configure), it is pay-per-use when using its On-Demand mode, it has a built-in change stream for publishing events, and it doesn't rely on networking tricks to keep it secure (zero trust). See my article, "Why DynamoDB Is (Still) My First Pick for Serverless," in References, below, for more details. If you haven't started building with DynamoDB, you are missing out. Please give it a hard look.

Pre-defined access patterns

Before wrapping up, I want to address a common polemic when comparing DynamoDB to SQL: pre-defined access patterns. In DynamoDB's documentation3, AWS encourages you to identify your data access patterns before building anything. This idea often receives pushback from SQLites, who argue that it is inflexible and impractical. Their anger is misguided. This has nothing to do with DynamoDB but with scalability more broadly.

Let's say you are using SQL in a scalable manner. You use no aggregations, foreign keys, or joins. I guarantee you that your indexes will follow your access patterns. This applies to any datastore, whether SQL, MongoDB, or Elasticsearch. It would be like DynamoDB, but without the guardrails.

And if a new access pattern were introduced, you'd have to do the work to incorporate it. You would figure out specific indexes and generate composite data keys for this new access pattern. You are optimizing for how your app works, not for flexible access patterns. This was hard for me to unlearn, but it's an essential distinction between OLTP and OLAP systems. Your app requires an OLTP database to scale, and you need to design it accordingly.

As Alex DeBrie wrote in The DynamoDB Book, "[in DynamoDB,] You design your data to handle the specific access patterns you have, rather than designing for flexibility in the future."4 I want to expand this to say, "In any scalable database system, you must design your data to handle the specific access patterns you have." If you have a problem with pre-defining your access patterns, you also have a problem with scalability.

Summary (of the summary)

Build for scalability. Consider using DynamoDB for its built-in guardrails and all the additional benefits it offers. Scale your business to new heights and profit from all your happy customers. And, after you do, I'd like to meet for coffee and hear all about it.

Happy building!