Approx. 8 min read · ~1,820 words
The Stack Sprawl Nobody Actually Budgeted For
Most growing teams don't sit down and choose a sprawling data stack. They accumulate one. Postgres runs the core app, then someone bolts on Redis for a job queue, Elasticsearch for search, a managed vector database for the new AI feature, and MongoDB for the one service that needed flexible documents. Three years later you're paying for five datastores, four of which serve under 5% of your traffic.
Postgres 18, released on 25 September 2025, is one more reason to question that habit. It shipped an asynchronous I/O subsystem, faster B-tree skip scans, native uuidv7() for time-ordered keys, and virtual generated columns. None of those are headline-grabbing on their own. Together they keep extending the range of workloads a single instance handles well.
The argument going around in 2026 is blunt: just use Postgres. We mostly agree, with caveats. The interesting question isn't whether it can do X anymore, because it usually can. It's "should this be a separate system yet, or are you adding operational cost ahead of real load?"
What "One Database" Actually Buys You
The pitch for consolidation isn't performance. A dedicated vector index will beat pgvector at a billion rows, and Elasticsearch will out-search it on typo tolerance and faceting at scale. The pitch is operational surface area.
Every datastore you run is a thing to back up, monitor, patch, secure, and reason about during an incident. It's another place data can drift out of sync. It's another vendor invoice and another access-control model your team has to audit. For a 12-person engineering org, the second and third datastore often cost more in attention than they save in throughput.
This is the same instinct driving teams to rethink the cloud-first default: not anti-cloud, just tired of paying for capacity and complexity that the actual workload never demanded. Consolidating onto one database lets you run analytics directly against operational data instead of shipping it through a pipeline into a separate warehouse you also have to maintain.
What Postgres Already Does That Used to Need a Separate Service
Here's the honest map of what a modern install covers, and what people reach for instead out of habit.
| What you need | The usual extra service | What it already gives you |
|---|---|---|
| Background jobs / queue | Redis, SQS | SELECT ... FOR UPDATE SKIP LOCKED, LISTEN/NOTIFY, the pgmq extension |
| Full-text search | Elasticsearch | tsvector / tsquery with GIN indexes |
| Vector / semantic search | Pinecone, managed vector DB | pgvector |
| Flexible / document data | MongoDB | JSONB with GIN indexes |
| Scheduled tasks | External cron service | pg_cron |
| Hot-read caching | Redis | Materialized views, UNLOGGED tables |
The queue case is the one developers underrate. With SKIP LOCKED you get a transactional job queue that shares a transaction with the data it's mutating. No dual-write problem, no "the job ran but the row didn't commit" race. For most apps doing thousands of jobs a minute, that's plenty, and it's one fewer system to run.
Vector search is the other big shift. pgvector has quietly closed the gap for the workloads most SMEs actually have. Under roughly 10 million vectors it holds its own on recall and latency, and the pgvector project keeps tightening index build times. If you're trying to ship retrieval-augmented features, keeping embeddings next to your relational data removes a whole class of sync bugs.
Where a Single Postgres Genuinely Falls Down
We don't think "one database forever" is the goal, and anyone selling you that is overselling. The goal is to defer each new datastore until it truly can't do the job, because most teams add the second and third datastore years before they have load that justifies it.
So where does it break? A few real places. pgvector past tens of millions of vectors starts losing to purpose-built indexes, both on latency and on index build time. Built-in full-text search is good, not Algolia-good, once you need fuzzy matching, synonyms, and rich faceting under heavy query volume. And a single primary is a single failure domain, so you still need streaming replication, a tested restore, and connection pooling in front of it. PgBouncer isn't optional once you have a few hundred concurrent clients.
The truth is, consolidation has a ceiling, and part of doing it well is knowing roughly where yours sits before you commit.
A Real Consolidation, With Real Numbers
Last year we picked up a logistics SME running four datastores: a primary database for the app, Redis for queues and caching, a managed Elasticsearch cluster for shipment search, and a separate vector database powering a "find similar shipments" feature. The vector index held about 600,000 rows. Nobody had planned this; each piece got added in a different quarter to ship a different feature.
We moved search to tsvector, folded the embeddings into pgvector on the same Postgres 16 instance, and kept Redis only for session storage. Their managed-data bill dropped from roughly $1,300 a month to under $400. The migration took two engineers about three weeks, and most of that was rewriting queries and backfilling indexes, not moving data. Six months on, search latency is slightly worse on the worst-case query and nobody has noticed, because the worst case is rare and the median got faster.
That's the pattern we keep seeing. The win isn't a benchmark. It's a smaller bill, fewer pager alerts, and a junior engineer who can now hold the whole system in their head.
How SMEs, Founders, and Engineering Leads Should Approach This
The right move depends on where you sit, so here's the practical version for each seat at the table.
- Founders pre-product-market-fit: every datastore is a tax on your runway and your focus. Start with one database. Add a second system only when a specific number forces it, not because a blog post said you'd need it eventually.
- SME owners: fewer systems means one vendor relationship, one backup to verify, and a bill you can actually read. That's worth more than a 10% latency edge on a feature your customers don't stress.
- CTOs and IT decision-makers: a smaller stack is a smaller attack surface and one access-control model to audit. Vendor risk drops when you're not depending on four managed services to all stay healthy at once.
- Developers and architects: transactional guarantees across your queue and your data kill an entire category of consistency bugs. Pair it with a typed query layer, which is part of why Drizzle has become a sensible default ORM for new TypeScript projects, and the developer experience holds up as you grow.
At Datasoft Technologies, when we build a multi-tenant SaaS platform on a single primary database, the first architecture review is usually about what we can not add. That conversation saves clients more money than any query tuning we do later.
If you already have sprawl, don't do a big-bang rewrite. Pick the cheapest, lowest-risk service to retire first, usually the one with the smallest data footprint and the fewest callers. Move it, run both systems in parallel for a week, compare results, then cut over. Repeat. The logistics example above retired its vector DB first because it had one consumer and clear success criteria.
Keep replication and backups solid before you concentrate more load on a single primary. Add PgBouncer early. And resist the urge to fold in the one workload that genuinely needs a specialist system, because consolidation is a tool, not a religion.
Frequently Asked Questions
Is Postgres really fast enough to replace Redis for queues?
For most applications, yes. A queue built on SKIP LOCKED comfortably handles thousands of jobs per minute and gives you transactional safety Redis can't. If you're pushing hundreds of thousands of jobs a second, that's the point where a dedicated broker earns its keep.
Can pgvector handle a production RAG or semantic search feature?
Under roughly 10 million vectors it's a genuinely good choice, and keeping embeddings beside your relational data removes sync headaches. Past that scale, benchmark it against a dedicated index before you commit, because build times and tail latency start to matter.
What about MongoDB? Do I lose flexible schemas by consolidating?
Postgres JSONB covers most document use cases, including indexed queries into nested fields. The cases where a document database still wins are narrower than they were five years ago, mostly very high write-throughput, schema-free workloads.
Does consolidating onto one database create a single point of failure?
It concentrates risk, which is exactly why streaming replication, a tested restore process, and connection pooling stop being optional. Done right, one well-run Postgres is more reliable than four services you only half-monitor.
When should an SME actually add a second datastore?
When a specific, measured limit forces it: vector counts past tens of millions, search requirements it can't meet, or a write pattern that fights the relational model. Add it for a number you can point to, not for a hypothetical.
Final Take
The boring answer is usually the right one in 2026. A single, well-run Postgres covers more ground than most teams give it credit for, and every system you don't add is one you don't have to keep alive at 2 a.m. Push the next datastore as far into the future as the workload allows.
If you're staring at a stack that grew faster than your traffic, it's worth a second opinion before you bolt on the next service. We're happy to look at it with you. You can book a free architecture review and we'll tell you honestly what to keep and what to fold back into Postgres.
