Four databases in one would be great if you had a reason for needing them.
That used to be our technology combination some time ago. It still causes me emotional pain when I remember. We had Mongo for handling documents, Redis for caching, Elasticsearch for searching, and then some obscure vector database for the new fancy AI features that every developer needed immediately.
We removed everything. Only Postgres is being used now.
The justification was always based on using the most suitable solution for a particular problem. It may seem like a good engineering approach, but in reality, it just means that you will have to monitor and maintain four control planes.
It was Martin Fowler who coined the term back in November 2011, stating that "any decent sized enterprise will have a variety of different data storage technologies for different kinds of data".
That was reasonable in 2011. Back in 2011, Postgres lacked many of the features we required.
However, this motto remained relevant for longer than it should have. We continued to open new stores simply because some blog post recommended it, not because the data required us to do so.
What was even more challenging than dealing with the costs on the cloud was that each store had its own backups, its peculiar way of scaling, and something different would fail at each of them at 3 am.
Once we migrated onto Postgres and consolidated our systems, not only did our bill decrease, but the operational overhead decreased significantly. This meant fewer issues to be alerted for. Fewer systems to constantly monitor. 🎯
But actually, it was a more subtle cost that convinced me to finally take the plunge. Tacnode's Alex Kimball coined the term back in March 2026: the "Retrieval Gap."
If one decision is reading from multiple stores, each read is reflecting a different point in time. You're assessing a composite state that has never really existed. Consider this: Your cache stores some information, your search index stores different information, and your source of truth stores yet more information. Your code then accesses this information based on a specific moment's snapshot, which may not have ever been an accurate reflection of actuality.
Having a single database in place will also ensure that all processes are in sync and there are no discrepancies in time tracking. The effort put into migration will be worth it for this reason alone.
While we were off trying to weld four systems into one, Postgres went away and became an adult. A proper one. In 2024, Feng Ruohang, creator of the Pigsty distribution of Postgres, penned "Postgres is Eating the Database World," in which he positioned Pigsty as "a data management abstraction framework with the potential to encompass everything and devour the entire database world."
That seems like an exaggeration, but when you see the reality of what was delivered, it starts to look like a fair description.
→ Vector search: In 2024, Timescale benchmarked Postgres with pgvector plus its pgvectorscale extension as faster than Pinecone and cheaper.
→ Queues: Tools like pg-boss (Node) and River (Go) run entirely on SELECT ... FOR UPDATE SKIP LOCKED
. Postgres becomes a transactional message broker, no Kafka cluster required.
→ Workflows: In mid-2026, durable execution moved into the database. DBOS and Microsoft's pg_durable use Postgres transactions and advisory locks to run crash-safe workflows without a separate orchestration cluster.
The vector DB is gone. The queue system is gone. The search cluster is gone.
Stephan Schmidt, a CTO coach for over a decade now, wrote the original manifesto on this topic: "Just Use Postgres for Everything" (updated December 2025). His assertion is that with the right indexing strategies, Postgres will scale as far as you could ever want for Kafka, RabbitMQ, Mongo, and Redis use cases, and then some. Up to millions of users even.
Millions of users, that's not a toy ceiling, that's most of us, to be honest.
I'm not suggesting that specialized stores are bad in every case. For instance, if you're Google, you have problems that Postgres is not interested in.
Choosing a single-purpose tool in that situation was not the mistake, we really did need it. The mistake was going with four by default, funnelling everything through YAGNI and "the right tool for the job" because that felt like the more grown-up thing to do. The mistake was not being able to see that "just use the database" would have been the right choice.
Fragmentation comes at a daily cost. It's cheaper to use a slightly suboptimal index for one database than to have an optimal one that you can't analyze for four databases running separately.
Begin by using Postgres. Introduce a second store into your system only when Postgres has fallen over, and allow it to prove that it is. In many cases, it never will, and you've just saved yourself from the burden of a stack that you would've been developing, operating, and tending for the rest of your life. 🐘
Which store in your architecture are you secretly confident that Postgres could have managed from the start?