The vector database is the foundation your RAG system stands on, and the choice affects cost, latency, operational burden, and how cleanly you can enforce access control. pgvector, Pinecone, and Weaviate are the three we most often shortlist, and they sit at genuinely different points on the build-versus-buy and simplicity-versus-scale spectrum. Here is how they actually compare, based on running them in production rather than reading the docs.
The axis that matters: operational model
The real decision is not which one has the best recall on a benchmark — at typical enterprise scale they are all capable — it is the operational model you want to own. pgvector is a Postgres extension you run inside a database you likely already operate. Pinecone is a fully managed cloud service you consume as an API. Weaviate is a purpose-built open-source vector database you can self-host or buy as a managed cloud offering.
That spectrum, from 'a feature of your existing database' to 'a managed service someone else runs' to 'a dedicated system you can own or rent,' drives most of the trade-offs. Anchor your decision there, then check the specifics against your scale, latency, and compliance needs.
pgvector: the pragmatic default
If you already run Postgres, pgvector is the default we reach for first and it is right more often than teams expect. You get vector search inside your existing database, which means transactional consistency, joins between your vectors and your relational metadata, one system to operate, back up, and secure, and no new vendor. For access control this is a genuine advantage: you filter vectors with the same SQL WHERE clauses and row-level security you already trust, so entitlement-aware retrieval is natural rather than bolted on.
With HNSW indexing, pgvector serves millions of vectors with strong latency and recall — enough for the large majority of enterprise RAG workloads. Its limits appear at very large scale (hundreds of millions to billions of vectors) or when you need advanced vector-native features and independent scaling of the vector workload. In our experience most teams that assume they've outgrown pgvector actually have a chunking or reranking problem, not a database problem.
- Best for: teams already on Postgres, up to millions of vectors, tight metadata filtering and access control.
- Strengths: one system, transactional consistency, SQL filtering and row-level security, no new vendor.
- Trade-off: fewer vector-native features and harder to scale the vector workload independently at extreme size.
Pinecone: managed scale with minimal ops
Pinecone trades control for operational simplicity. It is a fully managed, serverless vector database — you send vectors and queries to an API and Pinecone handles indexing, scaling, and availability. For teams that want to move fast, do not want to operate a vector store, and expect to scale into very large collections, it is a compelling choice with predictable low-latency performance at scale.
The costs are the usual managed-service ones: recurring spend that grows with data and query volume, and dependence on a third party for a core piece of your architecture, which raises data-residency questions for regulated workloads you must check against your compliance requirements. You also give up the free relational joins pgvector offers — filtering is via Pinecone's own metadata mechanism, which is capable but a separate model to learn.
- Best for: large-scale workloads where you want zero vector-store operations and elastic scaling.
- Strengths: fully managed and serverless, low-latency at scale, minimal ops burden.
- Trade-off: recurring cost, third-party dependency and data-residency review, separate filtering model.
Weaviate: vector-native, ownable, feature-rich
Weaviate is a dedicated open-source vector database with a rich feature set — built-in hybrid search combining dense and sparse (BM25) retrieval, optional built-in vectorization modules, multi-tenancy, and a GraphQL-style query interface. It splits the difference on the ownership axis: self-host it for full control and data isolation, or use Weaviate Cloud for a managed experience.
It shines when you want vector-native capabilities without gluing them together yourself, especially native hybrid search and strong multi-tenancy for isolating customers or business units. The trade-off versus pgvector is another system to operate if you self-host, and versus Pinecone it is more operational responsibility unless you buy the managed tier. It is a strong pick when your requirements outgrow pgvector but you want to keep the option of owning your infrastructure.
- Best for: vector-native features (native hybrid search, multi-tenancy) with the option to self-host and own the stack.
- Strengths: rich feature set, built-in hybrid retrieval, strong tenant isolation, open source.
- Trade-off: another system to run if self-hosted; more operational surface than a Postgres extension.
The factors the feature matrix hides
Two considerations override most feature differences. First, access control: in a permissioned enterprise corpus you must filter retrieval by the requesting user's entitlements, and how naturally a store supports metadata filtering and row-level security matters more than a marginal recall difference. pgvector's SQL filtering is hard to beat here; Pinecone and Weaviate both support metadata filtering but on their own models you must design deliberately.
Second, your total system. The vector store is one component; embedding model, chunking strategy, and a cross-encoder reranker usually move answer quality far more than the choice between these three. Do not over-optimize the database while neglecting the pipeline around it. Benchmark recall on your own labeled queries rather than trusting public numbers, because performance on your corpus is what you actually ship.
How to choose in practice
Default to pgvector if you already run Postgres and your scale is in the millions of vectors — it minimizes moving parts, makes access control natural, and is right for most enterprise RAG. Choose Pinecone when you want zero vector-store operations and expect very large scale, and your compliance posture permits a managed third-party service. Choose Weaviate when you need vector-native features like native hybrid search or strong multi-tenancy and want the option to self-host for data isolation.
Whatever you pick, abstract retrieval behind an internal interface so the vector store is swappable — the field moves quickly and your scale will change. In our experience the store you start with is rarely the one that would win a benchmark today, and that is fine: the pipeline around it and the discipline of measuring on your own data matter far more than the initial choice.
Key takeaways
- 1.The real decision is the operational model: a Postgres feature (pgvector), a managed API (Pinecone), or an ownable vector-native DB (Weaviate).
- 2.Default to pgvector if you're on Postgres and at millions-of-vectors scale — natural SQL access control and one fewer system.
- 3.Pick Pinecone for zero-ops elastic scale where compliance permits a managed third party.
- 4.Pick Weaviate for native hybrid search and strong multi-tenancy with the option to self-host.
- 5.Access control and the surrounding pipeline (embeddings, chunking, reranking) matter more than marginal recall — abstract the store so it stays swappable.