iTranslated by AI
re:Invent 2025: The Frankenstack Problem in the Era of AI Agents and SingleStore's Database Integration Approach
Introduction
Our goal with this project is to make valuable, yet often overlooked, information from various overseas lectures more accessible by transcribing them into Japanese articles. The presentation we're covering this time is:
For transcribed articles from re:Invent 2025, please refer to this Spreadsheet for compiled information.
📖re:Invent 2025: AWS re:Invent 2025 - What Database Would Your AI Agents Choose - Escape the Frankenstack (DAT203)
This video explains the "Frankenstack" problem in the era of AI agents. Complex systems with multiple databases, caches, and message buses aren't born from one bad decision, but from the accumulation of fifty reasonable decisions. Using an e-commerce price optimization engine as an example, it shows how a POC that started with three systems can balloon into numerous systems in production, including inventory systems, key-value stores, time-series databases, search databases, vector databases, and lakehouses. AI agents amplify this problem because they require real-time state, low-latency access, and consistent data. An integrated approach using SingleStore has been shown to reduce lines of code by one-third, decrease points of failure, and significantly improve development speed and maintainability.
*This article is automatically generated, aiming to preserve the content of the original lecture as much as possible. Please note that typos or incorrect information may be present.
Main Content
The Birth of the Frankenstack: Complex System Architectures Born Unintentionally
Alright, thanks for coming. Now, how many of you in here intentionally set out to build a Frankenstack? No one, right? No one says, "Hey, wouldn't it be fun to have six databases, three caches, a message bus, two streaming platforms, and a homemade ETL pipeline that only works on a full moon?" It just happens, just like you forget about a Halloween pumpkin, and it suddenly collapses into an orange, gooey pile on your doorstep.
So, again, raise your hands. How many of you in here are currently managing five or more data stores? And suspect there are even more that haven't been touched since 2020? Alright, you're in the right place. This talk is truly for all of us. We're going to explore how Frankenstacks happen, why AI agents make them worse, and how to avoid ending your career managing something that looks like it escaped from a haunted data center.
The team tells me the same story over and over: demos are easy. Production, that's where the real work is. And not just a little work, but a whole village worth of work, like a guild and a blacksmith. Complexity doesn't grow linearly with systems, or even exponentially. It grows factorially with data sources, and nobody wants a factorially scaling system. It's like adopting a kitten and waking up with a bloodthirsty pride of lions.
So, let me ask you. How many of you feel your system is working great until it suddenly collapses? That's the Frankenstack effect, after all. And here's the twist: AI agents are actually going to magnify this effect significantly. So, let's dig in.
Of course, this is how it starts. There's hope, there's ambition, there's a clean architecture diagram. In this case, an AI agent stack, a web mobile application, an OLTP system, a vector data store. Good enough to win a hackathon. Good enough to get a round of applause from your boss, maybe even good enough to earn a trophy, or at least a free T-shirt.
At this point, we're in the honeymoon phase. You've charmed the team. The POC works. Maybe you even have a demo video with some upbeat music. Someone in the back screams "rags to riches," and you don't even get annoyed by the dad joke because you're so proud of what you built. The architecture feels extensible. Need search? No problem. Just add another store. Need a recommendation engine? No problem, just add another store. Need analytics? No problem, just add yet another data store. And of course, this is where all of us say, "We'll clean it up later." But you all know the truth. We've all built these systems before. We never clean anything up, ever.
And then the monster begins. Complexity doesn't begin with a bang. It doesn't begin with a thud. It begins with a whisper. It grows in the seams, with every new data store added, every sync job added, every environment variable someone adds "just in case." Frankenstacking isn't one bad decision. It's fifty reasonable decisions. And by the time the symptoms arrive, the creepy crawlies have made themselves at home in your system.
And the symptoms arrive. Latency, cache inconsistency, schema drift, unexpected costs, three Slack channels and a seance, a debugging process that requires three shakes of goat blood over your left shoulder. These aren't big dramatic failures. They're annoying, creepy-crawly failures. Like little beetles getting into your pumpkin and turning it into mush.
The Reality of Production in an E-commerce Price Optimization Engine: Factorial Growth of Complexity
So, let's move from theory to a customer story. A large e-commerce platform running a price optimization engine. And here, all of these little decisions accumulate.
First, let's start with a user clicking Buy Now. Let's say, a Frankenstein costume. We want to personalize a discount based on their intent in live inventory. Very standard stuff. At this moment, your system springs to life. You hit your inventory systems, your OLTP databases, your event streams are running. All very classic patterns. When the agents show up, we're going to witness tiny sparks hitting very dry leaves.
Every request fans out to 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. In the next step, an agent acts. Grabbing cache profiles from a key-value store, recent behavioral trends from a time-series database, and orchestrating them with a pricing engine.
Next, we add search and discovery. Querying a search database for similar products, querying a vector database for embeddings and similarity matching, going back to the product catalog and inventory levels, getting all of it. And of course, we expect this to come back in 50 milliseconds. But of course, we're not done yet.
We're not done yet. We want to improve our models, right? So we add a lakehouse, an analytical warehouse, reporting tables, and orchestration for model training. All that data is exported, transformed, re-ingested, version-controlled, and then rejoined to put it back into the online system. And that's not all. Essentially, you have two parallel stacks. One for real-time, one for batch. Our architecture is now essentially a massive spiderweb of interdependencies.
In the proof of concept, our lives were simple. We probably had three systems: a web app, an OLTP database, and a vector store. When you get to production, you now have a small village of systems. So, a quick show of hands. How many of you have an architecture diagram that looks more like the left side than the right side? It's okay, this is a safe space. Raise your hands. I see some grimaces.
Not the left side, right? It's okay. This is your support group. Instead of having a clean architecture diagram, we have an architecture diagram that looks like we took a Martian's guts, threw them on a slide, and said, "Yeah, sure, let's ship it. It's perfect." And the worst part is, those of us with experience know that as time goes on, supporting the architecture diagram on the left is even worse than building it. Right? Because look at that zombie pipeline that should have died years ago.
We have a skeleton staff for support, but that's not shown here. This is the real human cost. And we have the saddest haunted house of connections in the world. And the only reason any of this is working is because there's an entire team of people who live and breathe every day just to keep it afloat. So, let's list some of these costs.
Latency spikes unpredictably. Embeddings drift, caches get stale, complexity increases. Suddenly, instead of everyone getting good recommendations, they're getting recommendations based on an interest in clown shoes. You fix one problem, and a dozen more are festering in the corners. You know that in a week or two, you're going to have an entire field of rotting pumpkins.
But don't worry, you know there's a new project coming up, you know there's a new job offer on the table. And you're going to move on to the new one before anyone notices that field of rotting pumpkins. And then, of course, there's the hiring burden to maintain this.
We haven't even talked about the fact that to operate each of these different data stores, you need subject matter experts for each of them.
Our agents are not dashboards, after all. They're not batch jobs. They're interactive, stateful systems that require real-time access to structured data, unstructured data, vector data, and event data. And if one of those pieces is slow, the entire system collapses faster than a rotten pumpkin on December 4th.
Integrated Database Approach Starting with Agent Needs: Solution by SingleStore
So, let's flip the problem and start with the agent's needs, not the systems we've inherited. Things are going to get simpler now. First, agents need one system that can read enterprise data and perform common functions like vector nearest neighbor search with minimal data movement and ultimately minimal overhead. They need faster development patterns, fewer lines of code, and a reduction in the dependencies they have to babysit. And ultimately, 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 Slack message at 2:00 AM asking, "Why is this suddenly failing in production?" Of course, agents need fewer processes to monitor. Every background job, every synchronization task, every streaming consumer you add is another ghost to haunt your on-call rotation. We want to reduce the number of demons involved. And, of course, that's in both the technical and Halloween sense.
So, when you start with the agent's needs, your architecture stops looking like a haunted house. It starts looking like something you can actually support on a Monday morning.
Our customers don't let us mess with their production code, but we did recreate a demo of what they actually did to get some metrics around the Frankenstack effect. And there's a significant, measurable difference in both cost and development velocity. Look at lines of code: a 3x difference between SingleStore and the cobbled-together system. Database connections, each database connection means more maintenance. One versus two failure points, you only have to manage one, not three. Every time you add a database or a data store, you're adding more room for gremlins to hide in your stack.
Now, let's talk about the part every engineer in this room feels: why a single database keeps production sane. With everything in one place, production stops being a haunted house maze of pipelines, caches, sync jobs, and
"why does this table only update on the new moon?" Debugging becomes predictable. CI/CD is much simpler with a single system. On-call becomes quieter, significantly quieter. Far fewer people are involved, and incident resolution is much faster.
Scaling is also easier. There's one system to scale up, one billing system, one graph to monitor, and one team of experts capable of handling the heavy lifting of debugging a single system. So, we've gone from a house full of creepy corners, dangling cables, and forgotten cron jobs scattered everywhere, to a clean, predictable, brightly lit system that agents can use and teams can trust.
So, let's wrap this up. When a team transitions from a Frankenstack to a unified database, the first thing they notice is speed. Not theoretical speed, but human speed, team speed,
feature development speed. Since everything runs on a single data store, they can release updates without three team meetings or that one meeting that really should have been an email. Product managers like myself can release features in just a few weeks instead of coordinating various engineering teams for months. Nobody needs to maintain that mysterious ETL job anymore. You know the one, that ETL job that only runs on the full moon, and only if it's the day after February 29th.
Now, here's the big message I want to convey to all of you. Frankenstack isn't born out of bad decisions. It happens because our architecture was built for dashboards, but now we're asked to run real-time, multimodal AI agents. AI agents need real-time state, low-latency access, consistent vector data, structured data, unstructured data, and no room for unexpected incidents.
So, thank you all very much for joining. Thank you for coming. Thank you for putting up with my terrible Halloween jokes. And have a great re:Invent. By the way, if you want to learn more about SingleStore, please visit booth 1559 or talk to the staff raising their hands in the back. Thank you very much. Have a great re:Invent.
- This article was automatically generated using Amazon Bedrock, maintaining the original video's information as much as possible.
Discussion