Picture a fairly ordinary business application with a few thousand users. Behind it sit a relational database, a separate document database, a search cluster, a message broker, an in-memory cache and, most recently, a vector database for an AI feature. That's six data stores, and each one has its own backups, security settings, upgrade cycle, monitoring and bill.
It's a very common shape. None of the choices is wrong on its own terms, since each was added by a capable engineer solving a real problem. Put together, though, you end up with a system that eats a big slice of the team's time just to keep running, and with data that keeps drifting out of sync between the stores.
Most of those jobs could be done by the relational database that's already there.
Postgres grew up
PostgreSQL has been around for decades and has grown well beyond "a place to put tables". Between its extension system and a steady stream of new features, one well-understood database now covers a lot of ground that used to need separate specialist services.
Documents: JSONB
Postgres stores JSON natively in a binary format you can index and query efficiently. Keep a proper relational schema for the stable, structured parts of your data and add a JSONB column for the parts that vary, like custom fields, integration payloads and per-tenant settings. For many teams that removes the reason they wanted a document database in the first place.
Search: built-in full text
Postgres has solid full-text search with stemming, ranking, phrase matching and multiple languages, all backed by proper indexes. It won't replace a dedicated search engine for a huge online catalogue with finely tuned relevance. For finding customers, tickets, documents and records inside a business app, it's usually plenty. Your search results can't fall out of sync with your data, either, because they are your data.
Queues: SKIP LOCKED
A table plus SELECT ... FOR UPDATE SKIP LOCKED gives you a reliable job queue. Several workers can pull jobs at once without tripping over each other, and each job is created in the same transaction as the business data that triggered it. That gets rid of a whole family of bugs where the order is saved but the "send confirmation email" message goes missing. Most major languages have mature open-source job libraries built on this pattern.
Vectors: pgvector
The pgvector extension adds vector storage and similarity search, which sits at the heart of most retrieval-based AI features. Your embeddings live next to the records they describe, with the same permissions and the same backups, and you query them with the same SQL. At the scale most business AI features run at, a separate vector database is often one more service to babysit without a clear payoff.
And the rest
There's LISTEN/NOTIFY for lightweight pub/sub, table partitioning for big time-series data, and row-level security so the database itself enforces tenant isolation. Materialised views handle expensive reports and PostGIS covers geospatial queries. Every major cloud offers it as a managed service.
Why fewer moving parts matters
We're not arguing that Postgres is the best at everything. Usually it isn't. The argument is about what each extra data store quietly costs you.
Each one needs patching, backups, restore tests, monitoring, capacity planning and someone who understands it at 2am. Data kept in two places will eventually disagree, and keeping it in sync is a distributed-systems problem most apps don't need. Each store is another set of credentials, network rules and access policies to get right, and another thing for an auditor to ask about.
Then there are transactions. In a single database, "save the order, queue the email, update the search index" either all happens or none of it does. Spread that across four services and the guarantee is gone. And several managed services, each sized for peak load, get expensive fast.
When you do need something else
We're not saying never add a specialist store. It's time when search relevance is central to your product and needs tuning Postgres can't express. It's time when you're running analytical queries over billions of rows and a columnar warehouse would be dramatically faster, or when your message volumes or fan-out patterns really call for a streaming platform. Mostly it's time when you've measured a real bottleneck, not an imagined one, that the database can't handle after reasonable tuning.
Measured is the important word. Most of the extra data stores we come across were added for scale that never showed up, or because a tutorial used one.
Our default
For new business applications we start with a single managed Postgres, used well. That means a clean relational schema, JSONB where you need flexibility, built-in search, a table-backed job queue, and pgvector if there's an AI feature. We add a specialist service only when there's a specific, measured need, and when that day comes you know exactly what problem it's there to solve.
A simpler architecture is cheaper to run and easier to secure, and the next developer will understand it much faster. If your data layer has become more complicated than your business, we can help you work out what to consolidate.
