How to Choose a Vector Database in 2026

A vector database stores embeddings and enables similarity search at scale. When you build RAG, you chunk documents, embed them, and store the vectors somewhere. That somewhere needs to return the nearest neighbors to a query vector in milliseconds, even with millions of rows. That’s what a vector database does.

The question is which one to use. The answer depends on scale, infrastructure preferences, and whether you already run PostgreSQL.

What a Vector Database Actually Does

You have chunks of text. Each chunk becomes a dense vector (typically 384 to 3,072 dimensions) via an embedding model. Similar meaning produces similar vectors. A vector database stores these vectors and, when given a query vector, finds the K nearest neighbors using a distance metric like cosine similarity.

Exact search (compare the query to every stored vector) doesn’t scale. At 10 million vectors, that’s 10 million distance computations per query. Vector databases use approximate nearest neighbor (ANN) algorithms that trade a small amount of accuracy for orders of magnitude faster search. You get the right results 99 percent of the time in a fraction of the time. The two dominant index types are HNSW and IVF, both of which we’ll cover in the performance section.

When You Need a Dedicated Vector Database vs. pgvector

pgvector is a PostgreSQL extension. Add a vector column, create an index, and you have vector search in your existing database. No new infrastructure. No new billing. For many applications, that’s enough.

pgvector handles tens of millions of vectors well. Beyond 50 to 100 million, index build times and query latency start to hurt. At that scale, dedicated vector databases (Pinecone, Weaviate, Qdrant) are built for the workload. They optimize storage layout, indexing, and query execution for vectors specifically.

You also need a dedicated solution if you want hybrid search (vector plus keyword) out of the box, built-in vectorization, or a GraphQL API. pgvector is vector search only. You can layer full-text search alongside it, but that’s your job to wire up. The same applies if you need multi-tenancy with strong isolation, or if your LLM application requires sub-50ms retrieval latency at very high QPS.

The Main Options

Pinecone

Fully managed, serverless, simple API. You create an index, upsert vectors, and query. No servers to provision. No clusters to tune. Good for teams that want zero infrastructure management.

Pricing is usage-based. The free tier includes serverless with community support. Standard starts at $50/month minimum with pay-as-you-go beyond that (storage around $0.33/GB/month, reads around $16 to $24 per million). Enterprise starts at $500/month with SLAs and private networking. If you want to avoid ops entirely and can afford the minimums, Pinecone is the path of least resistance.

Weaviate

Open-source. You can self-host or use Weaviate Cloud. Built-in vectorization (you send text, it embeds for you), GraphQL API, and hybrid search (vector plus keyword) are differentiators. Good for teams that want flexibility and don’t mind running infrastructure or paying for managed hosting.

Weaviate Cloud runs roughly $45 to $65/month for managed instances. Self-hosted is free aside from your own compute. The schema-based data model and GraphQL make it feel more like a database than a simple vector store. If you need hybrid search or want the database to handle embedding calls, Weaviate is worth a look.

Qdrant

Open-source, Rust-based, high performance. Benchmarks often show Qdrant with lower query latency than alternatives at scale (roughly 22 to 38ms at 10M vectors vs. 38 to 65ms for Weaviate). Good filtering and payload support. Self-host or use Qdrant Cloud.

Qdrant excels at production workloads where latency and throughput matter. The filtering is expressive: you can combine vector similarity with metadata filters (e.g., “nearest vectors where category = X and date > Y”). If you’re building something performance-critical and want open-source, Qdrant is a strong choice.

pgvector

PostgreSQL extension. Use your existing Postgres. Add the extension, create a vector column, add an HNSW or IVFFlat index, and you’re done. Simplest option if you already have Postgres in your stack.

pgvector scales well to tens of millions of vectors. Beyond that, index build times (hours at 100M vectors) and memory requirements become limiting. The standard vector type supports up to 2,000 dimensions for indexed search; for larger models like text-embedding-3-large (3,072 dimensions), you use the halfvec type. For most RAG applications, pgvector is sufficient. Start here.

Chroma

Open-source, lightweight, Python-first. Zero configuration by default. Good for prototyping and small-scale applications. Embed it in your app or run it as a server.

Chroma struggles at scale. At around 10 million vectors, query latency climbs (180 to 340ms in benchmarks). It’s single-node only. Use it for experiments, demos, and local development. When you move to production at scale, migrate to something else. The Python API is minimal: a few lines of code and you have a working vector store. That simplicity is the trade-off for limited scalability.

Decision Factors

Scale. Millions of vectors: pgvector or any dedicated option works. Tens of millions: pgvector still holds up with tuning. Hundreds of millions or billions: you need a dedicated vector database.

Self-hosted vs. managed. Self-hosting (Weaviate, Qdrant, Chroma) means you own the ops. Managed (Pinecone, Weaviate Cloud, Qdrant Cloud) costs more but removes that burden. Your team’s capacity for infrastructure work matters.

Hybrid search. If you need vector plus keyword search combined (e.g., exact matches on codes plus semantic matches on descriptions), Weaviate and Qdrant support it natively. With pgvector, you combine it with PostgreSQL full-text search yourself.

Existing infrastructure. Already on Postgres? pgvector is the obvious first step. No Postgres? A dedicated vector store may be simpler than adding Postgres just for vectors.

Budget. pgvector is free (you pay for Postgres). Chroma is free. Pinecone has a free tier but Standard starts at $50/month. Weaviate and Qdrant Cloud run roughly $45 to $65/month for managed. Scale and features determine where you land.

Practical Recommendation

Start with pgvector if you already use Postgres. You get vector search with no new systems. The extension is mature, well-documented, and handles most RAG workloads. When you hit scale limits (slow index builds, high memory, latency degradation), move to a dedicated solution. Pinecone if you want managed and simple. Qdrant if you want open-source and performance. Weaviate if you need hybrid search or built-in vectorization.

For prototyping without Postgres, Chroma gets you running in minutes. Plan to migrate before production scale.

Performance Considerations

Index types. Most vector databases use HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index). HNSW gives faster queries (often 15x faster than IVF in pgvector) but slower index builds and higher memory. IVF builds faster but degrades with frequent updates. For read-heavy RAG workloads, HNSW is usually the right choice. Both are approximate: they don’t guarantee the exact K nearest neighbors, but in practice the recall is high enough that retrieval quality is unaffected.

Approximate vs. exact search. Exact search compares the query to every vector. It’s correct but doesn’t scale. ANN search returns approximate nearest neighbors: you get the right results almost always, with a small recall trade-off. In practice, the difference is negligible for retrieval quality. Use approximate.

Filtering. Metadata filters (filter by category, date, tenant) can slow queries if not indexed. Most vector databases support payload or metadata indexing. Design your schema so common filters are indexed. Otherwise, you filter after retrieval, which wastes compute. Qdrant and Weaviate handle filtered vector search efficiently: they prune the search space using the filter before or during the vector lookup. pgvector can do the same with standard SQL WHERE clauses, but the planner needs to use the right indexes.

Migration path. If you start with pgvector or Chroma and later move to a dedicated store, the migration is straightforward. Embeddings are just arrays of floats. Export from one system, import to another. The embedding model and chunking strategy stay the same. The main work is rewriting the query layer to use the new client library.

Choosing a vector database is mostly about matching your scale and infrastructure preferences to the right tool. Start simple. Avoid over-engineering: a team of three building an internal knowledge base does not need Pinecone Enterprise. A startup with 100K documents does not need Qdrant clusters. Match the tool to the problem. Get Insanely Good at AI goes deeper into RAG architecture and production patterns. Scale up when you need to.