Postgres Is Quietly Eating Your Stack
Vector search, full-text search, and job queues are moving into Postgres extensions instead of separate services. Here's why the operational case beats the performance case — and where it still breaks down.
Postgres Is Quietly Eating Your Stack
For a decade, "scale" meant sharding your data layer across specialists: Redis for cache, Elasticsearch for search, Pinecone or Weaviate for vectors, RabbitMQ or SQS for queues, and Postgres or MySQL sitting underneath as the boring system of record. Each piece did one job well. The cost was operational: five services to patch, five failure modes to monitor, five sets of credentials to rotate, and a distributed-systems problem (keeping them all in sync) that most teams solved badly.
That architecture is losing ground, and Postgres is the reason.
What actually changed
Postgres didn't get faster so much as it got more capable. Extensions matured to the point where they cover use cases that used to require standalone infrastructure:
- pgvector handles similarity search well enough for the large majority of RAG and recommendation workloads. It's not going to beat a purpose-built vector database at billion-row scale with sub-10ms latency requirements, but most products aren't operating at that scale, and the ones that think they are usually haven't measured.
- pg_search / built-in full-text search covers what most teams were reaching for Elasticsearch to do, which was frequently just "let users filter and search a table," not genuine log-scale text analytics.
- LISTEN/NOTIFY plus SKIP LOCKED give you a serviceable job queue without introducing RabbitMQ or Kafka. It won't handle the throughput of a dedicated broker, but it removes an entire service for the 90% of apps that never approach that ceiling.
- Logical replication and native partitioning have closed a lot of the gap that used to justify moving to purpose-built OLAP or sharded setups earlier than necessary.
None of this makes Postgres better than the specialist tools at their specific job. It makes Postgres good enough at all of them simultaneously, which is a different and often more valuable property.
The real argument isn't performance
The pitch for a dedicated vector database or a dedicated queue is always a performance argument. The pitch for staying on Postgres is an operational one, and operational arguments compound in ways performance arguments don't.
Every additional service in your stack is:
- another dependency that can be the reason for an outage
- another thing with its own upgrade cadence, breaking changes, and security patches
- another connection pool, another set of credentials, another network hop
- another place where "eventually consistent" quietly becomes "actually just inconsistent" because nobody built the reconciliation logic
A five-person team maintaining Postgres, Redis, Elasticsearch, and a message broker is spending real engineering time on integration and consistency that a five-person team on Postgres alone is spending on the product. That tradeoff was worth it when Postgres genuinely couldn't do the job. Increasingly, it can.
Where this breaks down
This isn't a case for running everything on a single Postgres instance forever. The consolidation argument has real limits:
- Vector search at genuine scale (hundreds of millions of embeddings, aggressive latency SLAs) still favors specialized stores with purpose-built indexing.
- High-throughput, high-fanout queueing — the kind with strict ordering guarantees and millions of messages a minute — will still choke a queue built on a relational table, no matter how clever the polling.
- Analytics at real OLAP scale wants a columnar store, not row-oriented Postgres with a partitioning band-aid.
The skill isn't "use Postgres for everything." It's knowing which of your assumed constraints are real and which are inherited folklore from a company at 100x your scale. Most teams adopt Kafka, Elasticsearch, or a dedicated vector DB because a blog post from a company with a very different problem told them to, not because they measured their own workload against Postgres and found it wanting.
The practical takeaway
Before reaching for another managed service, it's worth asking what specifically Postgres can't do for the workload in front of you — not what it theoretically can't do at a scale you haven't reached. The extensions ecosystem has moved fast enough that a "we need X specialized database" decision made two years ago is worth revisiting, not because Postgres suddenly became a vector database or a message broker, but because it became adequate at those jobs for the range of scale most products actually operate in.
The winning move for most teams right now isn't picking the best tool for each job in isolation. It's picking the tool that's good enough for most jobs and using the operational budget you save to actually build something.