Vector Database vs. pgvector: Do You Actually Need a Dedicated One?

The usual sequence is backwards. A team builds a RAG feature, reads that "you need a vector database," and provisions Pinecone or Weaviate before checking whether the Postgres instance already running the rest of the product can do the job. That's an extra system to deploy, monitor, back up, and pay for — before anyone has confirmed it was necessary. If you haven't settled the broader question of how your AI feature should be built at all, start with RAG vs. fine-tuning; this post assumes you've landed on retrieval and are now choosing where the vectors live.

What pgvector actually is

pgvector isn't a competing database. Its own GitHub README describes it plainly: an open-source extension that adds a vector data type and HNSW and IVFFlat index types to PostgreSQL. You install it into a database you already run, add a column, build an index, and query it with ordinary SQL — joined against the rest of your schema, inside the same transactions, behind the same row-level security you already have.

That has real limits. The vector type caps out at 2,000 dimensions; the lower-precision halfvec type raises that to 4,000. HNSW builds a multilayer graph that the README says trades slower, more memory-hungry builds for better speed-recall than the older IVFFlat method, and it doesn't need a training step, so you can create the index before the table has data. Filters apply after the index scan, so a highly selective WHERE tenant_id = 42 can still cost you recall unless you address it with partitioning or iterative scans. None of this is exotic — it's the normal shape of running a feature on a database you already operate, with the normal tradeoffs that come with it.

The signals that say pgvector is enough

• You're already on Postgres. There's no new system to provision, secure, or keep patched. Your existing backups, monitoring, and access controls already cover it.
• Your corpus is comfortably under the point where index size becomes the bottleneck. pgvector's documentation doesn't publish a hard row-count ceiling — the real constraint is whether the index fits in available memory and how selective your filters are. Most practical guidance treats corpora under roughly 10 million vectors as comfortable on a reasonably provisioned Postgres instance.
• Hybrid search is a nice-to-have, not the product. You can combine pgvector with Postgres's full-text search, but you're wiring that yourself rather than getting it as a built-in.
• You need growth room, not a rewrite. The pgvector README itself points to read replicas, Citus, or PgDog for scaling the underlying Postgres horizontally — options that exist before you'd need to migrate off it entirely.

The signals that say you've outgrown it

• Scale that's actually large — hundreds of millions of vectors or sustained query volume high enough that the index no longer comfortably fits in memory on instances you're willing to run.
• Hybrid search as a first-class product feature. Weaviate's own documentation highlights combining BM25 keyword search with vector search as a headline capability; Qdrant natively fuses dense and sparse vectors. Both are built around that combination rather than treating it as an add-on.
• Multi-tenant isolation at scale is core to the architecture. Weaviate describes built-in multi-tenancy and replication as production-readiness features, not something you'd otherwise build by hand across many Postgres schemas.
• You want a vendor to own uptime, scaling, and ops and are willing to accept managed-only, closed-source hosting and its cost model in exchange.

Comparing the usual next step

Each of the three is a reasonable choice for the thing it's built around. None of them is automatically "the" vector database — the fit depends on whether you need to self-host, whether hybrid search is a feature or the whole point, and how much operational work you're willing to take on yourself.

What actually breaks RAG — and it's rarely the database

Teams that migrate from pgvector to a dedicated store expecting better answers are often disappointed, because answer quality mostly isn't a storage-layer problem. It comes from how documents are chunked, which embedding model is used and whether it fits the domain, and whether retrieval is actually measured rather than assumed to be working. Our LLM evaluation guide covers how to build a golden set and test retrieval before and after shipping changes — that's the step that catches bad chunking and stale embeddings, and no vector database does it for you. A faster or fancier index returns bad chunks faster; it doesn't make them good chunks.

A simple decision framework

1. Are you already on Postgres, and is your corpus under roughly 10 million vectors? If yes, add pgvector. Don't stand up a new system to solve a problem your current one can already handle.
2. Is hybrid search or multi-tenant isolation actually core to the product — not a feature you might want someday, but something customers are asking for now? If yes, evaluate Weaviate or Qdrant on your own data before committing.
3. Do you want to hand database ops to a vendor and are you comfortable with managed-only, closed-source hosting and its pricing model? If yes, Pinecone fits; if self-hosting or portability matters, it's the wrong choice regardless of how convenient it looks at first.

Most teams never clear the first question. If you're not sure where your own data lands, the honest first move is to measure — count what you actually have, profile your filters, and check whether the index fits in the memory you're willing to provision — before adding a second database to operate.

If you're building or extending an AI feature and want a second opinion on where the vectors should live, that's part of what we scope during AI integration work — timeline and cost depend on your existing stack and data volume, and get set during discovery rather than guessed up front.