Postgres as a Vector Store: When pgvector Is Enough (and When It Isn't)
pgvector is enough when your corpus is small-to-mid scale (roughly under a few million vectors), your query patterns mix vector search with relational filters you'd otherwise have to reimplement in a separate system, and you value one less piece of infrastructure to operate over marginal recall or latency gains. A dedicated vector database earns its complexity when you're at real scale, need approximate-nearest-neighbor tuning knobs pgvector doesn't expose well, or your query patterns are pure vector search with no relational join — in which case the "one less system" argument stops applying.
The "should I use pgvector or a dedicated vector database" question gets answered too often as a hot take — "just use pgvector, it's fine" from people who haven't operated it past a few hundred thousand rows, or "you need a real vector database" from people optimizing for a scale most projects never reach. The actual answer depends on specifics that are worth naming explicitly instead of defaulting to whichever opinion you read most recently.
Where pgvector is the right call
The strongest case for pgvector isn't really about vector search performance — it's about not having to operate, sync, and pay for a second database. If your corpus lives in Postgres already (which it does for most Supabase-backed products), and your retrieval queries need to combine a vector similarity search with a relational filter — "find semantically similar support tickets, but only from this tenant, only from the last 90 days, only with status=open" — doing that as one SQL query against one database is genuinely simpler and often faster than doing a vector search in a separate system and then joining the results back against Postgres for the relational filter.
For corpora in the range most B2B AI products actually operate at — tens of thousands to low millions of vectors — pgvector with an appropriate index (HNSW for most workloads at this scale) performs well enough that the marginal latency difference against a dedicated vector database rarely matters against the operational cost of running a second system.
Where a dedicated vector database earns its complexity
- Real scale — tens of millions of vectors and up, where index build time, memory footprint, and query latency on pgvector start becoming genuine engineering problems rather than theoretical ones.
- Query patterns that are pure vector search with no relational join — if you're never combining similarity search with a SQL filter, the "one database" argument that favors pgvector stops applying, and a system built specifically for ANN search has real advantages.
- Need for ANN tuning knobs pgvector doesn't expose well — recall/latency tradeoffs, quantization options, and index rebuild strategies that dedicated systems have invested years into, versus pgvector's comparatively young HNSW implementation.
- Multi-region or read-replica-heavy vector workloads where a system designed around that from the start avoids Postgres-specific replication complexity.
Hybrid search is the case that gets missed
A lot of the "pgvector isn't good enough" complaints turn out to be about pure semantic recall on a workload that actually needed hybrid search — combining vector similarity with traditional full-text search (Postgres's built-in tsvector/tsquery) so an exact keyword or product code match doesn't get buried under merely-similar results. Running both in the same database and blending the scores in one query is straightforward in Postgres and awkward across two separate systems — another point in favor of staying in Postgres until there's concrete evidence it's the bottleneck, not the query pattern.
A migration path that doesn't require a rewrite
The pragmatic sequence: start on pgvector, instrument query latency and recall from day one, and treat "move to a dedicated vector database" as a data-backed decision rather than a pre-emptive architecture choice. If the evidence eventually says move, the migration is usually more contained than it sounds — the embedding generation and retrieval-query logic stay the same, only the storage and similarity-search layer changes, so a clean abstraction around retrieval queries from the start pays for itself later even in the common case where the move never actually happens.
This is the same decision underneath most of the retrieval-augmented systems we build — see production RAG systems for the broader architecture, or LLM observability in production for how to actually instrument the retrieval layer once it's live.
Frequently asked questions
Does pgvector support hybrid search?
Yes — pgvector handles the vector similarity side, and Postgres's built-in full-text search (tsvector/tsquery) handles keyword matching, both queryable in the same SQL statement against the same table. That combination is one of the strongest practical arguments for pgvector over a dedicated vector database that only does pure vector search.
How many vectors can pgvector realistically handle?
With an appropriate index (HNSW for most workloads), pgvector performs well into the low millions of vectors for typical B2B application workloads. Real scale — tens of millions and up — is where index build time and memory footprint start becoming genuine engineering problems rather than theoretical ones.
The takeaway
Start with pgvector by default if your corpus lives in Postgres already and your queries mix vector similarity with relational filters — which describes most retrieval-augmented products we've built. Move to a dedicated vector database when you have concrete evidence pgvector is the bottleneck, not when a blog post says it will eventually be. The number of projects that actually outgrow pgvector before outgrowing several other parts of their stack first is smaller than the "you need a real vector database" advice implies.
Have a similar challenge?
Book a free 30-minute architecture call and we'll tell you honestly whether and how we can help.
Book Free Discovery Call →