The default assumption in most RAG projects is that you need a vector database. Usually, at the scale the project actually operates at, you need Postgres.

What a dedicated vector store buys you

Specialised indexes, horizontal scale-out, and features like native hybrid search and multi-tenancy primitives. These are real advantages at genuinely large scale.

What it costs you

A second datastore to run, back up, secure, monitor, patch and reason about during an incident. A second consistency model. A second thing that can be misconfigured and leak. For a team of five, that is a significant fraction of operational capacity spent on infrastructure rather than on the product.

The case for pgvector

If your data already lives in Postgres, pgvector lets you keep embeddings beside the rows they came from. That means a single backup, a single access-control model, and - importantly for retrieval quality - the ability to filter by ordinary SQL predicates and join to real business data in the same query. Metadata filtering is often where retrieval quality is actually won, and doing it in SQL is straightforward.

Where the threshold sits

The honest answer is that it depends on your corpus size, embedding dimensionality, query concurrency and latency budget - so measure it. But the failure mode we see is not teams outgrowing Postgres. It is teams adopting a specialist store at a scale where Postgres would have been comfortable, and paying the operational tax for years.

Start with pgvector. Instrument recall and p95 latency. Migrate when the measurement, not the architecture diagram, tells you to.