Vector Database Comparison for RAG and AI Agents

Last updated: July 14, 2026

Every RAG pipeline and every tool-using agent eventually needs the same piece of infrastructure: a place to store embeddings and retrieve the nearest ones fast. The vector database market has settled into a few durable options, and they split along a real fault line - Postgres-native versus purpose-built, and hosted versus self-managed. This is a practical, source-linked comparison, not a benchmark leaderboard.

If you're new to the underlying technique, see our what is RAG explainer first, and our AI agent architecture piece for how retrieval fits into a larger agent loop.

The contenders#

• pgvector - a Postgres extension for vector similarity search (exact and approximate via IVFFlat/HNSW indexes), documented in the project README.
• Pinecone - fully managed, serverless vector database; pricing at pinecone.io/pricing.
• Qdrant - open-source vector search engine written in Rust, available self-hosted or as Qdrant Cloud.
• Weaviate - open-source, schema-based vector database with built-in hybrid search modules; cloud pricing at weaviate.io/pricing.
• Chroma - open-source embedding database designed for simple local and small-scale RAG use, plus a hosted Chroma Cloud.
• Milvus - open-source, distributed vector database built for large-scale deployments, with a managed offering via Zilliz Cloud.
• Turbopuffer - object-storage-backed vector database, priced primarily on storage plus query compute per turbopuffer.com/pricing.

Hosted vs. self-host#

Fully managed only: Pinecone is serverless-only - there is no self-hosted Pinecone binary, per its architecture docs. You trade infrastructure ownership for zero-ops scaling.

Open source with a managed option: Qdrant, Weaviate, Milvus (via Zilliz), and Chroma (via Chroma Cloud) all publish source under permissive-ish licenses (see each project's LICENSE file on GitHub) and let you run the same engine yourself or pay for a hosted control plane. This is the most flexible position - you can prototype self-hosted and migrate to managed later without a rewrite.

Postgres-native: pgvector is not a database, it is an extension. If you already run Postgres (via Neon, Supabase, or your own instance), you add vector columns and indexes to existing tables instead of standing up a new system. That means one fewer service to operate, one connection pool, and transactional consistency between your relational data and your embeddings - at the cost of scaling only as far as Postgres itself scales.

Storage-backed: Turbopuffer's design explicitly separates storage (object storage like S3) from compute, per its architecture writeup, which is why its cost model looks different from index-in-RAM engines.

Filtering#

Metadata filtering (e.g., "only chunks from these tenant IDs" or "only docs published after X") is often the deciding factor for agent and multi-tenant RAG use cases, more than raw recall numbers.

• pgvector: filters are just normal SQL WHERE clauses combined with the vector operator, so you get the full expressiveness of Postgres predicates, joins, and existing row-level security, documented in the pgvector README.
• Qdrant: has a dedicated filtering system with payload indexes built to keep filtered search fast at scale.
• Weaviate: supports filters combined with vector search and BM25 in the same query via its hybrid search docs.
• Pinecone: supports metadata filtering per Pinecone's filtering guide, with the caveat that filter fields must be indexed as metadata at ingest time.
• Milvus: supports scalar filtering alongside vector search, described in the Milvus filtering docs.
• Chroma: supports where metadata filters per the Chroma usage guide.
• Turbopuffer: supports filters natively as part of query requests, per its query API docs.

If your app needs row-level security tied to existing user/tenant tables, pgvector's SQL-native filtering is the simplest mental model because it is the same access control you already write for the rest of your app.

Scale#

Scale considerations split into two questions: how many vectors, and how much query concurrency.

• pgvector is documented as supporting both exact and approximate (HNSW/IVFFlat) indexing, and performance depends heavily on your Postgres instance's memory and index tuning - see the pgvector index tuning notes. It is a strong fit up to the tens-of-millions range on well-resourced Postgres, but you are bound by single-writer-node Postgres scaling characteristics unless you shard.
• Milvus is architected from the start for distributed, horizontally scalable deployments and is used in some of the largest published vector search deployments; its architecture overview documents the separated compute/storage/coordinator design built for that purpose.
• Pinecone serverless separates storage and compute automatically and scales without manual index/shard management, per the Pinecone serverless architecture docs.
• Qdrant supports distributed deployment with sharding and replication for horizontal scale.
• Weaviate supports horizontal scaling via sharding and replication as well.
• Turbopuffer explicitly optimizes for large-scale, cost-efficient storage by keeping data in object storage and loading indexes on demand, per its architecture page.
• Chroma is positioned by its own docs as best suited to lighter-weight and local-first workloads, with Chroma Cloud added for teams that outgrow a single-node setup, per the Chroma Cloud announcement.

Cost#

Pricing structures differ enough that "which is cheaper" depends entirely on your access pattern:

• pgvector has no separate vector-database bill - you pay whatever your Postgres host charges (e.g., Neon's pricing or Supabase's pricing). This is often the cheapest entry point if you already pay for Postgres.
• Pinecone charges by a combination of stored data, read units, and write units under its serverless model, detailed on the Pinecone pricing page.
• Qdrant Cloud prices by cluster size (memory/CPU) for managed clusters, per Qdrant's pricing page, while self-hosting is free aside from your own infrastructure cost.
• Weaviate Cloud prices on a similar managed-cluster basis per Weaviate's pricing page.
• Zilliz Cloud (managed Milvus) prices by compute units and storage, per Zilliz's pricing page.
• Chroma Cloud prices on a usage basis (storage plus queries), per the Chroma pricing page.
• Turbopuffer prices primarily on object storage volume plus query costs, which its docs argue makes cold, rarely-queried collections dramatically cheaper than always-on in-memory indexes, per the Turbopuffer pricing page.

How to choose#

A fair, non-hype summary of when each makes sense:

• Already on Postgres, moderate scale, want one system: pgvector.
• Want zero ops and predictable serverless scaling: Pinecone.
• Want open source you can self-host now and move to managed later, with strong filtering: Qdrant or Weaviate.
• Need distributed scale for very large vector counts: Milvus / Zilliz Cloud.
• Prototyping locally or a small embedded use case: Chroma.
• Large, infrequently-queried datasets where storage cost dominates: Turbopuffer.

None of these is universally "best" - the right choice depends on whether you already run Postgres, how much operational overhead your team can absorb, and whether your workload is read-heavy and hot or cold and storage-heavy. Read the docs and pricing pages linked above before committing, since both terms and tiers change.

FAQ#

Can I use pgvector at production scale, or is it only for prototypes?#

pgvector is used in production by teams running tens of millions of vectors, but it inherits Postgres's scaling characteristics. It is documented to support both exact and approximate indexing (IVFFlat and HNSW) - see the pgvector README for index types and tuning guidance. If you need sharded, horizontally distributed scale beyond a single Postgres cluster, a purpose-built distributed engine like Milvus may fit better.

Do I need a dedicated vector database if I already use Postgres?#

Not necessarily. If your data already lives in Postgres and your scale is moderate, pgvector lets you add vector search without introducing a new service, connection pool, or sync job. Teams typically move to a dedicated vector database when they need distributed scale, specialized ANN index tuning beyond what pgvector offers, or built-in hybrid search features.

Which vector databases support hybrid (keyword + vector) search out of the box?#

Weaviate ships hybrid search combining BM25 and vector similarity natively, per its hybrid search docs. Qdrant and Milvus also support combining sparse and dense vectors for hybrid retrieval - check each project's current docs for the specific API, since hybrid search features have been actively evolving across the ecosystem.

Is a managed vector database worth it over self-hosting?#

It depends on your team's operational capacity. Managed options (Pinecone, Qdrant Cloud, Weaviate Cloud, Zilliz Cloud, Chroma Cloud) remove index tuning, scaling, and backup work, but cost more per unit of data than self-hosting the open-source equivalents. If you have DevOps capacity and predictable load, self-hosting Qdrant, Weaviate, or Milvus can be materially cheaper; if you want to ship without maintaining another stateful service, managed is usually the better trade.

Official Sources#