🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.

Overview

📖 AWS re:Invent 2025 - What Database Would Your AI Agents Choose - Escape the Frankenstack (DAT203)

In this video, the speaker explores how "Frankenstacks"—complex systems with multiple databases, caches, and pipelines—emerge from incremental reasonable decisions rather than single bad choices. Using an e-commerce pricing optimization example, they demonstrate how AI agents amplify this complexity by requiring real-time access to structured, unstructured, and vector data across numerous systems. The talk contrasts a simple 3-system POC with production architectures involving dozens of interdependent data stores, showing measurable impacts: 3X more code, multiple failure points, and unpredictable latency. The solution proposed is consolidating to a unified database like SingleStore, which reduces maintenance burden, speeds development, and makes production manageable. Key metrics show one database connection versus multiple, fewer lines of code, and simpler debugging processes.

; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.

Main Part

The Birth of a Frankenstack: How Complexity Creeps Into Your Architecture

All right, thank you for coming. So who here has intended to build a Frankenstack? None of us. None of us say, you know what sounds like fun? Six databases, three caches, a message bus, two streaming platforms, a homemade ETL pipeline that runs only on full moons. It just happens, like when you forget about that Halloween pumpkin and it suddenly collapses into an orange pile of goo on your porch.

So again, quick show of hands. How many people here maintain more than five data stores right now? And how many of you suspect there are even more than that, that have not been touched since the year 2020? All right, so you're in the right place. This talk is really for all of us. We're going to explore how Frankenstacks happen and why AI agents make them worse and how we avoid ending our careers managing something that looks like it escaped from a haunted data center.

So teams tell me the same story over and over again. The demo's easy. Production, that's where the real work is. And not just a little work, like a village of work with guilds and blacksmiths and stuff. Complexity doesn't grow linearly with systems or even exponentially. With data sources, it grows factorially, and nobody wants a system that scales factorially. It's like adopting a kitten and waking up with a herd of blood-hungry lions.

So let me ask you. How many of you feel like your system works great until suddenly it falls apart? That's, at the end of the day, the Frankenstack effect. And here's the twist. AI agents are actually going to amplify this effect significantly. So let's dive in.

So of course, this is how it starts. You have hope, you have ambition, you have a clean architecture diagram. In this case, we have an AI agent stack, the web mobile app, an OLTP system, a vector data store. It's good enough to win a hackathon. It's good enough to get your boss to give you an applause, and it's good enough to maybe even win a trophy, or at the very least, get yourself a free t-shirt.

We're in the honeymoon phase at this point. You've wowed the team. Your POC works. Maybe you even have a demo video with some upbeat music. Someone in the back shouts from rags to riches, and you don't even groan at that dad joke because you're so proud of what you've made. Your architecture feels extensible. You need search? No problem. Bolt on another store. Need a recommendation engine? No problem, bolt on another store. Need analytics? No problem, bolt on yet another data store. And of course, this is the point at which we all say we'll clean it up later. But we all know the truth. We've all built these systems before. We're not cleaning anything up, ever.

So the monster starts. The complexity doesn't start very loudly. It doesn't start with a bang. It starts with little whispers. It grows at the seams with every new data store, every sync job, every environmental variable someone adds just for the time being. Frankenstacking is not one bad decision. It happens because of fifty reasonable ones. And once the symptoms appear, the creepy crawlies have made home in your system.

And the symptoms come out. Latency, cache inconsistency, schema drifts, surprise costs, a debugging process that takes three Slack channels, a seance, and goat's blood sprinkled three times over your left shoulder. These aren't big dramatic failures. They're annoying, creepy crawly ones, like the little beetles that get inside your pumpkin and turn it into mush.

When AI Agents Meet Production: A Real-World E-Commerce Nightmare

So let's move from the theoretical to a customer story. A high-scale e-commerce platform running a pricing optimization engine. Here's where all of these little decisions have added up.

So we're going to start with a user who's clicking buy now on, I don't know, maybe a Frankenstein costume, let's say. We want to personalize a discount based on their intent in live inventory. Very normal. At this moment, your system springs into action. It's going to hit the inventory system, your OLTP database, event streams are going to work. All very classic patterns. We're about to see a tiny spark hitting those dry fall leaves when an agent comes into play.

All in the request fans out. All the different systems that we're going to touch, and each of these different systems is going to operate independently with its own SLAs and its own quirks. So the next step, our agent brings an action. It's going to be orchestrating by pulling cache profiles from your key value store, recent behavioral trends from your time series database, and blending that together with a pricing engine.

Next, we're going to add search and discovery. So it's going to query your search database for similar products, query your vector database for embeddings and similarity matches, going back to your product catalog and your inventory levels, pulling all of that. And of course we're hoping that this returns in under 50 milliseconds. But of course we're not even done yet.

There's more. You want to improve your models. So you're adding in your lakehouse, you're adding in your analytics warehouse, reporting tables, model training orchestration. All of that data is now exported, transformed, re-ingested, versioned, stitched back together to be put into the online system. Not only that, we essentially have two parallel stacks, one for our real-time and one for our batch. Our architecture is now basically a giant spider web of interdependencies.

In our proof of concept, our life was simple. We had maybe three systems: a web app, OLTP database, a vector store. Fast forward to production. We now have a small village of systems. So, quick show of hands, how many of you have an architecture diagram more like the one on the left than the one on the right? It's okay guys, this is a safe space. You can raise your hands. I see some pained smiles.

Not on the left, right? So it's okay. This here is your support group. Instead of going with the clean architecture diagram, we have an architecture diagram that looks like we've disemboweled a Martian, put it on a slide, and said, yeah, sure, ship it. It's perfect. And the worst part here is those of us with experience know that over time, supporting the architecture diagram on the left is even worse than building it. Right, because let's look at some zombie pipelines over here that should have died years ago.

We have skeleton crew for support that isn't even pictured here, the real human cost, and a web of connections that feels like the world's saddest haunted house. And the whole thing works because you have an entire team of people who are living and breathing every day just to keep this propped up. So let's go ahead and enumerate some of these costs.

Latency, which spikes unpredictably. Embeddings that drift, caches that are stale, and complexity that ramps up. Suddenly, everyone, instead of getting a good recommendation, is getting a recommendation based on your interest in clown shoes. You fix one problem, and there are more problems decomposing over in the corner. In a week or two, you know you're going to have a whole field of rotting pumpkins.

But don't worry, you know that you have a new project upcoming, a new job offer, and we're going to get over to that new one before anyone notices that field of rotting pumpkins. And of course, the hiring burden for this, to keep it up.

We haven't even talked about the fact that you need experts in each of these different data stores in order to operate them.

Our agents aren't dashboards at the end of the day. They aren't batch jobs. They're interactive, stateful systems that need real-time access to structured, unstructured, vector, and event data. If even one of these pieces is slow, the entire system collapses faster than a rotting pumpkin on December 4th.

Building for Agent Needs: The Case for a Unified Database Approach

So let's flip the problem around and start from the agent's needs instead of the systems that we've inherited. Things are about to get simpler. First, agents need one system that reads their enterprise data and runs common functions like vector nearest neighbors with minimal data movement and ultimately minimal overhead. They need faster development patterns, fewer lines of code, and fewer dependencies to babysit. Ultimately, that's also fewer tokens going in and out of the models that are building them.

Every external system you remove is one less SDK to upgrade, one less client library to patch, and one less "why is this suddenly failing in production" message that you're getting at Slack at 2 a.m. Of course, agents need fewer processes to monitor. Every background job, every sync task, every streaming consumer you bolt on becomes one more ghost haunting your on-call rotation. We want fewer demons involved, and of course that's both the technical and Halloween senses.

So when you start with the agents' needs, architecture looks less like a haunted house. It starts looking like something you can actually support on Monday mornings.

Our customers won't let us play with their production code, but I recreated a demo of what it is they did just to get some metrics behind the Frankenstack effect. There are huge differences, measurable differences in cost and measurable differences in velocities. Just look at lines of code: a 3X difference between SingleStore versus a bolted-on system. Database connections, with each database connection, again that's more maintenance that has to be done. One versus two failure points, only one to manage instead of three. With each different addition of databases and data stores, that's more room for gremlins to hide in your stack.

So let's talk about the part every engineer in this room feels: why a single database makes production feel sane. With everything living in one place, your production stops being a haunted house maze of pipelines, caches, sync jobs, and "why is this table only updated at three-quarter moon cycles?" Your debugging is predictable. CI/CD is much easier with one system. On-call is quieter, significantly quieter. Many fewer people involved, much faster incident resolution.

Not to mention scaling gets easier as well, with one system to scale up, one system that's billing, one graph to watch, one team of experts who can do all the hard work to debug your one system. So we've gone from a house full of spooky corners, dangling cables, and forgotten cron jobs to a clean, predictable, well-lit system that your agents can use and your teams trust.

All right, so let's go ahead and bring this home now. When your team moves from a Frankenstack to a unified database, the very first thing you will notice is speed. Not theoretical speed, but human speed, team speed,

feature speed. Because everything is now working on a single data store, you can ship updates without having those three team meetings or that one meeting that really should just be an email. Product managers like me can get features out in just weeks rather than months of wrangling all of the different engineering teams to get it done. Nobody has to maintain that one mysterious ETL job. We know that ETL job, the one that only runs on full moons the day after February twenty-ninth.

So here's the big message that I want to leave everybody here with. Your Frankenstack doesn't happen because of a bad decision. It happens because our architectures are built for dashboards, and now we're asking them to power real-time multimodal AI agents. AI agents that need real-time state, they need low latency access, they need consistent vector, structured and unstructured data, and no surprises.

So I want to go ahead and thank you all for joining us. Thank you for being here. Thank you for putting up with all of my bad Halloween jokes, and I hope you have a great rest of your re:Invent. By the way, if you want to learn more about SingleStore, we are at booth 1559, or ask the guys in the back over there with their hands up. Thank you all very, very much. Have a great re:Invent.

; This article is entirely auto-generated using Amazon Bedrock.