Vector Databases Compared

What to compare

Vector databases all answer the same question: given a query vector, return the k closest stored vectors fast. The differences that matter for a RAG project are hosting model, the indexing algorithm, metadata filtering quality, and licensing. Pricing and benchmark numbers change too fast to trust in print, so treat those as check-at-signup and measure your own workload.

The indexing algorithm decides the recall, latency, and memory tradeoff. HNSW (Hierarchical Navigable Small World) builds a layered graph and gives the best query latency at a given recall level, at the cost of higher memory. IVF (Inverted File) clusters vectors and scans only nearby clusters, which uses less memory but answers slower. Most managed and self-hosted systems default to HNSW for RAG-sized corpora.

pgvector

pgvector is an open-source PostgreSQL extension under the PostgreSQL license, not a standalone database. Vectors live in a vector(N) column next to the rest of the application data, and similarity search is SQL:

```sql

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE chunks (

id SERIAL PRIMARY KEY,

content TEXT,

source TEXT,

embedding vector(1536)

);

CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

SELECT id, content, 1 - (embedding <=> $1) AS similarity

FROM chunks

ORDER BY embedding <=> $1

LIMIT 5;

```

pgvector supports HNSW and IVFFlat indexes, with <=> for cosine distance, <-> for Euclidean distance, and <#> for inner product. HNSW parameters are m (default 16), ef_construction (default 64), and query-time ef_search. Filtering is plain SQL WHERE clauses, which is the most expressive filtering of any option here and joins against the rest of the schema. It self-hosts anywhere PostgreSQL runs, including RDS, Cloud SQL, Supabase, and Neon. Practical scale is single-digit millions of vectors on tuned hardware; beyond that, the shared Postgres buffer pool and single-node layout become the ceiling.

Pinecone

Pinecone is a proprietary, managed-only vector database: there is no self-hosted option and the source is closed. You send vectors and metadata over its API and it handles indexing, scaling, and replication. Its serverless tier provisions capacity automatically and bills on read and write units plus storage, with a free Starter tier.

For teams with no appetite for database operations, Pinecone removes the whole category of work. The cost is vendor lock-in and usage-based billing that scales with query volume, which matters for chatbots that fire many retrieval calls per session. Metadata filtering is supported but basic compared with SQL or Qdrant's filter engine. It suits prototypes and production systems that prefer to buy the retrieval layer outright.

Qdrant

Qdrant is open source under Apache 2.0, written in Rust, and runs self-hosted as a single binary or in a cluster, with a managed cloud option. It uses its own HNSW implementation and is known for filterable HNSW: metadata filters execute inside the index during graph traversal rather than as a post-filter, so heavily filtered queries stay fast.

Filtering is JSON-based with range, match, geo, and full-text clauses, and it supports dense plus sparse vectors for hybrid search in one query. Quantization options (scalar, product) cut memory for large indexes. Qdrant fits teams that self-host, need strong filtered search, and want a permissive open-source license with no usage metering on the software itself.

Weaviate

Weaviate is open source under BSD-3-Clause, written in Go, and runs self-hosted in containers or as a managed cloud service. Its indexing is HNSW-based, and its signature feature is native hybrid search: dense vector search combined with BM25F keyword search in a single query, which fits document corpora where exact terms matter.

Weaviate can vectorize objects on ingest through its module system (bring your own vectors or use built-in vectorization), supports GraphQL and REST query APIs, and has multi-tenancy built in for SaaS workloads. The data model carries more concepts than its peers (classes, properties, modules), so the learning curve is steeper, but hybrid document search is first class rather than bolted on.

Milvus

Milvus is open source under Apache 2.0 and is the heavyweight option: a distributed system with separate components for coordination, storage, and indexing, plus Milvus Lite (an embedded Python library) and a standalone deployment for smaller workloads. Zilliz Cloud is the managed service from the same team.

It supports multiple index types including HNSW, IVF variants, and GPU-accelerated indexes, and it separates storage into object storage, so capacity scales without re-architecting. The operational cost is real: a distributed deployment involves etcd, message storage, and object storage. Milvus is the choice when the corpus is hundreds of millions to billions of vectors and the team has the DevOps capacity to run it.

Chroma

Chroma is open source under Apache 2.0 with an embedded mode that runs in-process in Python, a server mode, and a managed cloud. The embedded mode is the fastest path from zero to a working RAG prototype: pip install, add documents, query, with no infrastructure at all.

Its simplicity is also its ceiling. Embedded Chroma is single-node and prototype-grade in durability, and high-availability self-hosting is harder than with the server-oriented options. For local development, demos, and small applications it remains the lowest-friction pick.

Choosing

Start from constraints, not features. Already on PostgreSQL with under a few million vectors: pgvector adds no new infrastructure. Prototype or local tool: Chroma embedded. Self-hosted production with heavy filtering: Qdrant. Document search that needs keyword plus vector in one query: Weaviate. Hundreds of millions of vectors with an ops team: Milvus. No ops capacity and budget for usage billing: Pinecone.

Whichever you pick, the decisions that transfer are the embedding model, chunk boundaries, metadata schema, and evaluation set. The vector store is the most replaceable part of the stack as long as those are solid.