During an internship, I built a full-stack ticket management system on Spring Boot, with MongoDB, MySQL, and Aerospike all running underneath it. Three data stores, one project. At the time it felt like proof I understood the ecosystem. Looking back, it was closer to proof I hadn't yet learned to say no to a database.
How it actually happened
It wasn't one bad decision. It was three reasonable-sounding ones stacked on top of each other.
MySQL handled the relational data, users, tickets, assignments, the stuff with clear structure and clear relationships. That part made sense from day one. MongoDB got added because some ticket metadata was unstructured and "just throw it in Mongo" felt like the obvious move, without anyone asking whether that unstructured data was actually going to grow into something that needed a document store, or whether it was five fields that could've lived in a MySQL table with a JSON column. Aerospike came in for caching and fast lookups on high-traffic ticket queries, which was the most defensible addition of the three, but even that got applied more broadly than the actual traffic patterns justified.
Each decision, in isolation, had a story. Together, they meant every new feature had to consider three different data models, three different failure modes, and three different places a bug could be hiding.
What it actually cost
Nobody warns you about this part clearly enough: the tax isn't paid once at setup. It's paid every single time afterward.
Every schema change is now a question of which store owns that data. Every bug report starts with "okay, which database is this even coming from." Every new person joining the project has to learn three systems before they can meaningfully contribute, instead of one. None of that shows up in a demo. All of it shows up six months in.
What I'd actually do differently
I'd start with one database and force myself to justify every additional one, not the other way around. MySQL alone probably could have handled 90% of what we needed, including the "unstructured" metadata, which in practice was more structured than anyone wanted to admit when Mongo felt like the trendier answer. Aerospike earns its place if the caching need is real and measured, not assumed.
The actual skill isn't knowing how to wire up multiple databases. Any tutorial teaches you that. The skill is knowing when a second database is solving a real problem versus when it's solving the problem of your resume looking more impressive.
I understand why it happens. A stack full of named technologies feels like proof of range. But the projects that actually hold up under real use are usually the boring ones, one well-chosen database, doing its one job, with nothing extra bolted on to look sophisticated. I know that now. I didn't when I was building it.
Top comments (0)