Postgres Is Quietly Eating Your Stack

For most RAG applications — think tens of thousands to low millions of embeddings — pgvector with an HNSW index performs well within acceptable latency for user-facing search. It starts to lose ground past very high vector counts with aggressive p99 latency requirements, where purpose-built stores' indexing strategies pull ahead. The honest answer is: measure your actual embedding count and latency budget before assuming you need something else.

Not really, and this piece doesn't claim it can. Redis's value is largely in-memory speed for ephemeral data and specific data structures (sorted sets, pub/sub at high frequency) that Postgres isn't built for. The consolidation argument here is narrower: it applies to search, vector similarity, and moderate-throughput queueing — not to Redis's core caching use case.

There's no single number, but rough signals: sustained write throughput in the tens of thousands per second, vector counts in the hundreds of millions with strict sub-10ms latency SLAs, or queue throughput in the millions of messages per minute with strict ordering guarantees. Below those thresholds, the operational cost of a specialized service usually outweighs the performance gain.

Both, but complexity is the bigger win. A single managed Postgres instance is often cheaper than a managed vector database plus a managed queue plus a managed search cluster, but the larger saving is engineering time not spent on integration glue, consistency bugs, and separate on-call runbooks for each service.

Postgres has pulled ahead specifically because of its extension architecture, which lets projects like pgvector ship as first-class citizens rather than bolted-on features. MySQL has made some moves in this direction, but its extension ecosystem is considerably less mature, which is a real part of why Postgres is the one absorbing these workloads rather than MySQL.