In my previous article we discussed DynamoDB's dual nature - simultaneously the best and worst database imaginable (talk about split personality!). We also explored some pretty unconventional topics:

🩸 Why DynamoDB is terrible at grocery shopping 🛒
🩸 Medical risks related to working with DynamoDB 👀
🩸 What item count and F1 racetrack 🏎️ have in common

I found that theory alone rarely convinces people about DynamoDB limitations. On the other hand, specific examples sometimes also fail to resonate. That's when I realized what we really need are stories. I must tell tales in which you could see your own mistakes reflecting in other people's experiences.

It's story time!

When collecting article ideas, I came up with a handful of DynamoDB disaster stories that, despite being works of fiction, are almost certainly happening somewhere right now. These are situations where teams pushed DynamoDB too hard to learn that sometimes it's better to stop and think rather than act "smart" and "clever" only to end up feeling defeated and confused.

I took those ideas for a spin and created a short tale that hopefully shines a light on real teams, real projects, and real problems. A tale of what happens when you try to trick DynamoDB into granting your wishes instead of working with its design.

And so it begins...

All events and characters appearing in this work are fictitious. If you find anything like this actually happening in real life, please contact me immediately for help!

Might I also suggest some appropriate background music...?

We Don't Need Another Database champions

The application design was prominently displayed as a neat diagram on a whiteboard. The team gathered in a room following a meeting with product owners, discussing the usual - new enhancements and quality of life improvements in the app.

It all started as a perfect plan - a hot new startup building a SaaS platform for content creators. Just basic CRUD operations for profiles, projects, and payments. The engineering team had read all the AWS blog posts and designed the most elegant single-table DynamoDB schema you'd ever seen. A beauty to behold. Six months later, it had evolved into something that looked more like a Jackson Pollock painting, but it was still coping - a calculated technical debt. All in all, everything was going pretty well.

The new feature request that they just finished discussing - "What if you could look up freelancers based on their past project history?" - was a tough nut to crack.

– Why can't we just use PostgreSQL? We know SQL! – asked one developer.
– We don't need another database! – declared the Lead – DynamoDB can do everything!
– Look how clean this access pattern is! – the team celebrated – Zero latency, infinite scale, and we barely pay anything. We can't let it be ruined!

That night, as the team huddled around their screens desperately searching for answers, their frustration echoing through Stack Overflow posts, AWS wikis, and GitHub issues, they were still at a dead end. After all, this was their first serverless project since moving away from hosted solutions they'd been using for years until they started using AWS a year ago. In their darkest moment of desperation, someone stumbled upon a hidden AWS forum thread that sparked their attention.

It spoke of a legend - a peculiar AI assistant that could be summoned by asking Amazon Q the right question at exactly midnight (UTC). Not your typical chatbot, this mystical creature was said to have been granting database wishes since the beginning of Epoch time.

The cryptic post described a digital genie 🧞‍♂️ and claimed that as long as you phrased your wishes in valid JSON, all was possible. The message offered surprisingly detailed instructions for summoning it.

They were desperate and getting nowhere despite putting in extra hours. In perfect unison, everyone in the room looked at the clock. It was showing exactly 2024-11-28T23:59:00.000Z.

– This is ridiculous – muttered the Lead, staring at the screen – but I've seen crazier things.
– Have you? This must be the weirdest post I've ever seen. Someone must be having a good laugh. – said one of the developers.
– What's the worst that could happen? – shrugged another, already typing the suggested prompt – Better than explaining to Product why we need two more sprints only to work on some spikes.
– Wait, let me record this – grinned the junior dev, pulling out their phone – You guys are nuts. This thing, you summoning that legendary creature... it will totally blow up on social media!

The words died in their throats as the screens flickered in unison, terminal windows filling with swirling blue text that coalesced into a shimmering form.

Initializing...
> Checking midnight timestamp alignment ...........OK
> Deploying wish-granting instance ................COMPLETE

⚡️ You have summoned DynamoDB Genie v1.0.0-wish (build 1970-01-01T00:00:00.000Z)

Hey guys, what's happening? What is going on?
You can have three wishes
If you don't take too long...

(type wish -h for a list of options)

genie@dynamodb-realm:~$ ▋

The cursor pulsed with a green glow, each blink seeming to last an eternity, as if time had slowed down. A sudden commotion filled the room as everyone rushed to their keyboards, each desperate to be the first to type their wish command.

What they did not know was that, like all genies through history, this one also had a peculiar way of interpreting wishes - and an unusual fondness for eventually inconsistent results.

Wish #1: I Wish I Could Count Items

The first team wished for a simple counter.

"Just COUNT the items, that's what we need,
But we don't know what it its."

The genie smiled

;) Consider it done!
You have a timeline that you don't want to miss

> Granting... (1/3) OK! 

genie@dynamodb-realm:~$ ▋

And just like that, the wish was granted as the genie flicked its fingers to deploy the whole solution stack to production in an elegant single CLI call.

"It's but a simple counter."
Lead said with a hint in his voice
"Something that should be available
in any database of choice."

Little did they know they were about to learn why implementing a simple counter in DynamoDB could turn into an exercise in advanced distributed systems engineering... and creative AWS budget explanations.

Wish #2: I Wish I Could Search

The second team wished for flexible search.

"Let us comb quickly through all our store,
Filter, then find, and then do some more."

Then genie promised

I will make it clean,
Searching through the items no-one has yet seen

> Granting... (2/3) OK!

genie@dynamodb-realm:~$ ▋

Once again, with a mysterious grin, genie performed an elaborate dance with his fingers and with a barely audible crack, a new stack materialized in their account.

Nobody suspected it to be another trap that the genie had set for them. Why would they? The solution worked perfectly. How could they have known that it would completely fall apart the moment they got featured in TechCrunch, resulting in the company holding the record for the most expensive AWS bill accrued in a single day in history?

Wish #3: I Wish I Knew the Past

The last team wished for analytics.

"Give us the power to slice and to dice,
All of our data, make insights precise!"

The genie's eyes sparkled

Oh, that sounds nice,
But do remember - you cannot wish twice.

Granting... (3/3) OK! 

genie@dynamodb-realm:~$ ▋

For the final time genie performed his deployment magic. His fingers moved with practiced precision, though anyone watching closely might have noticed a slight hint of anticipation in his movements. The CloudFormation stack materialized with a sound like distant thunder.

Process your data, aggregate more,
Calculate trends from your DynamoDB store.
Real-time insights at your command,
What could possibly get out of hand?

genie@dynamodb-realm:~$ ▋

The unexpected genie's words hung in the air like a fog, thick with unspoken warnings. His smile - or perhaps a smirk - held secrets that would only become clear in production.

And then it said:

I'm sorry
That's the way it goes
It's time for me to go
Bye

⚠️ Warning: Wish capacity exceeded 

genie@dynamodb-realm:~$ ▋

Session terminated...

~$ █

The Smirk in Genie's Wish-Granting

Fast forward one month and the startup was like a battlefield. AWS bill had increased tenfold, the pages were taking ages to load as the DynamoDB read capacity was constantly maxed out. Every search operation triggered a full table scan, reading (and paying for) every single item. The elaborate event-driven aggregates were constantly off, making "eventually consistent" look like a precise science in comparison. A new term "eventually inconsistent" was even coined.

It was a total disaster...

They tried summoning the genie again but to no avail. It's as if he was mocking them...

Initializing...
> Checking midnight timestamp alignment ...........OK
> Deploying wish-granting instance ................COMPLETE

⚡️ You have summoned DynamoDB Genie v1.0.0-wish (build 1970-01-01T00:00:00.000Z)

⚠️ Request capacity exceeded
Bye
Session terminated...

~$ █

Last time I checked, they had a dedicated team just for maintaining their DynamoDB access patterns and were spending enough AWS credits to buy a small island.

The Three Lessons of the DynamoDB Genie

Lesson #1: Count Your Wishes Carefully

DynamoDB has gaps, significant limitations that can't be "wished away". We are not talking about small imperfections - it's huge chasms in functionality that can swallow entire development teams.

Working with DynamoDB isn't about personal preference – it's like building a space station. When you first launch it, everything is perfectly engineered for your mission. The systems are optimized, performance is there, and the cost-to-value ratio makes perfect sense.

But missions change. What starts as a simple research station will eventually grow and evolve. Each modification requires a spacewalk 🧑‍🚀 and careful planning - there's no room for error when you're in orbit. Sure, you can add new docking ports (GSIs) to allow different types of ships to connect - these are your backup plans, different ways to access your station when you need to. But they're just entry points to your existing structure; they can't change your core architecture. In the end, major changes mean rebuilding entire modules in space. The design that was perfect for your original mission has become a constraint on your future ones.

Apollo 13 mission was a lesson in resourcefulness and resilience. It taught us that sometimes we need to build a carbon dioxide scrubber from incompatible parts just to stay alive. Just like those astronauts had to craft a literal filter from nothing to prevent suffocation, DynamoDB developers often find themselves engineering elaborate workarounds just to perform basic filtering operations - all while watching their CPU credits running out like oxygen leaking out of a damaged spacecraft. The problem is it's not done out of necessity, after exhausting all other options. On the contrary - workarounds are often wielded like weapons.

This is exactly like DynamoDB – your initial data model might be perfect for your current requirements, but when business needs evolve, even small changes can require complete data restructuring. You can by read about this in more detail here, but in short:

🩸 Everything has to be carefully planned
🩸 There is no ad-hoc queries - everything has to be carefully planned
🩸 Filtering as part of data retrieval has to be carefully planned
🩸 Did I tell you that everything has to be carefully planned?
🩸 SELECT COUNT(*) requires a team of Noble-prize scientists to implement
🩸 You can't join tables for querying related data
🩸 Last but not least, forget about even the simplest reporting or analytics

DynamoDB is THE perfect core datastore. It excels for CRUD, scaling to infinity with unmatched performance while remaining very cost effective.

But it struggles with everything else.

Lesson #2: Be Careful What You Wish For

Know Your Tool

Don't try to force DynamoDB beyond its boundaries or you will find setting yourself up for failure.

The real problem isn't DynamoDB's limitations - it's not considering complementary tools that would make these limitations irrelevant. After all, you wouldn't blame a hammer for being bad at cutting wood; you'd reach for a saw. But what if there were no saws available?

The Tooling Gap

Here's something that continues to blow my mind. 🤯 There's a surprising gap in the tools and services ecosystem, both in and out of AWS. While everyone seems eager to integrate with everything else, DynamoDB often gets treated as a second-class citizen.

The lack of native, seamless DynamoDB integrations is staggering and I just don't get it. Think about it:

📈 AWS has a dominant position on the market - check!
❤️ DynamoDB has been widely adopted - check!
💰 Those who adopted it happen to both have money and no problem spending it

It's a huge piece of the market that has been up for grabs for quite a while now, yet there is still minimal support for native DynamoDB integrations.

This is particularly ironic given that AWS provides its own native solutions that eliminate the need for third-party streaming alternatives (DDB Streams, Kinesis). Yet pick a random third-party product and you will be most likely advised to use Kafka for streaming DynamoDB data in and out of it. For us, serverless AWS software engineers, "industry standard" solutions like Kafka are unnecessary middleware layers that only increases operational burden and cost.

This landscape is slowly changing

The Rockset demise drama caught the market off-guard with countless Rockset refugees running around and screaming like headless chicken. I don't blame them - there was literally no other solution on the market that provided their seamless DynamoDB integration experience while delivering exceptional added value. If I were to bet, I would bet all my money on Rockset being on a fast-track for an eye-watering figure AWS acquisition. Imagine my surprise when OpenAI acqui-hired all of its staff and scraped the service practically overnight.

That event highlighted a critical weakness in the DynamoDB ecosystem - when a single third-party tool disappears, teams can be left with no viable alternatives. While new solutions have emerged to fill the void, the fundamental problem of limited choice persists. The demand from customers willing to redirect their past Rockset budgets has driven some market changes, third-party support remains surprisingly limited. This persistent gap creates unnecessary complexity for teams that have deliberately chosen DynamoDB for its operational simplicity and scalability promises.

Lesson #3: Let Not What's in Front of You Blind You to Alternatives

Look Beyond DynamoDB

Being good at DynamoDB doesn't mean using it for everything. On the contrary, if you're good at it, you'll know exactly when to stop. And when you do, the next step is finding just the right tool that will complement DynamoDB by being its perfect extension, integrating so smoothly that you won't even notice.

What makes a solution truly "fit" with DynamoDB? It comes down to three crucial factors:

🩸 Seamless Integration - it should work with DynamoDB native features (especially DDB Streams) without requiring complex middleware or custom code
🩸 Complementary Strengths - it should fill DynamoDB gaps while letting DynamoDB continue doing what it does best
🩸 Operational Simplicity - it should maintain promise of low operational overhead and should not introduce scaling or reliability challenges

Always be on the lookout for tools that have the potentially of being better than your first choices. Invest in spending time to carefully consider your options so that you don't have to pay premium for making the wrong choices in the future.

I have major grievances and complaints about AWS

My complaint is that AWS makes everyone think that DynamoDB is more than it actually is. Take this blog post for example. Publishing an official guide about counting in DynamoDB could and frankly, does mislead developers into thinking this is a reasonable use case.

Think about it in terms of "productive laziness" vs "harmful laziness" - forcing DynamoDB to do counting is a perfect example of expending enormous effort to make the wrong tool do something it wasn't designed for. And people still fall for it.

By not giving developers access to tools that they need in order to be successful in their work, AWS is forcing them into doing something that should never even be considered. Even the best of us are limited in what they can do with business constraints - whether it's money, pre-approved supplied lists, legal or simple reluctance of your superiors for introducing new tools and different solutions.

At the end of the day, AWS is well aware of the fact that once they pull someone into their ecosystem, many companies won't look outside of it for solution assuming, rightfully so, that all of their use cases will be covered by the tools and services provided by AWS.

What's Next

While I will keep preaching that sometimes the best demonstration of DynamoDB expertise is knowing when not to use it, there's more to the story than just avoiding DynamoDB for unsuitable use cases. The real key is being aware of the areas in which alternative tools can seamlessly complement DynamoDB's strengths while addressing its limitations and being open to utilizing such tools.

That's why in my next articles I'll explore such areas and tools that work alongside DynamoDB to create truly robust, scalable architectures. We'll look at solutions that don't just work around DynamoDB's limitations but turn them into opportunities for building better applications.

Stay tuned to learn about the solutions that every DynamoDB developer should be aware of. After all, even the most powerful database needs a few good friends 🤝 and I am not talking about stabbing-in-the-back genies 🧞‍♂️

Disclaimer

_This article is an independent developer guide. All views, wishes, and mystical encounters are entirely my own.

Side effects of reading this article may include: spontaneous JSON formatting, midnight AWS console checking, and an irrational fear of making wishes to database genies._