Best vector databases for RAG in 2026: stop benchmarking, match the deployment shape

The data-gravity rule: prefer the shape your data and operations already occupy. If your application data lives in Postgres, the cheapest correct answer is usually pgvector in that same Postgres, not a new database to sync, secure, and pay for. If you already run Redis, its query engine adds vectors without a new system. A dedicated vector database earns its place when you outgrow that gravity well: tens of millions of vectors, heavy hybrid workloads, or scale and latency targets your primary store cannot hold. Choosing by data gravity beats choosing by benchmark, because the benchmark gap is usually smaller than the operational cost of a system you did not need.

Why hybrid search and filtering stopped being the differentiator

The single biggest change since the 2024 vector-database hype is that the features vendors used to fight over are now standard. Hybrid search, combining dense vector similarity with sparse keyword relevance (usually BM25), materially improves RAG retrieval when exact terms matter, and it has moved from a selling point to an expectation. Weaviate has BM25 hybrid built in, Qdrant and Milvus do sparse-plus-dense, Pinecone has supported sparse-dense for years, and turbopuffer and Vespa treat full-text and vector as one query. If a database cannot do hybrid in 2026, that is the news, not the reverse.

Metadata filtering followed the same path. Filtering vector results by attributes (tenant, date, document type, permissions) is now expected everywhere; the differences are in how well filters combine with the vector index under load. This is the one place a benchmark still earns its keep: Qdrant's Rust filtering is a genuine strength for heavily filtered workloads, and pgvector inherits Postgres's mature query planner for complex predicates. But "can it filter" is no longer a yes/no axis, so the matrix below treats hybrid and filtering as near-universal and spends its discrimination on the axes that still separate the field: deployment shape, open-source license, and pricing model.

The comparison matrix: shape, license, hybrid and pricing model

Eleven databases on the five axes that decide fit and cost. yes, partial, and no are read from each vendor's own repository, docs, or pricing page. "Partial" hybrid means available through an integration or full-text add-on rather than a single native call. Pricing model is the column to read at scale, not a headline number. This comparison is published as an open dataset under CC-BY (see methodology).

Highlighted rows are the picks most teams should start from. Licenses, hybrid support, and pricing models reflect each vendor's public repository and documentation as of June 2026 and change often; verify on the vendor's own page before a decision. Redis is marked partial under "open source" because version 8 ships a tri-license (RSALv2/SSPLv1/AGPLv3) rather than a single permissive license.

This comparison is published as an open dataset (CC-BY) with a permanent DOI: DOI 10.5281/zenodo.20738950. Browse the full dataset landing page or download the machine-readable JSON.

The self-hosted workhorses: Qdrant, Weaviate, Milvus, Vespa, Marqo

This is where most serious RAG teams land, because self-hosting gives the lowest unit cost, full data residency, and no per-vector vendor markup, at the price of running the server yourself. Qdrant is the performance-and-value pick: written in Rust, Apache-2.0, with the fastest filtered-search numbers in the category and the cheapest self-host footprint (it runs millions of vectors on a small VPS). It is the safe default when you want an open-source dedicated database you can also buy as a managed cloud later. Weaviate is the choice when hybrid search and a batteries-included feature set matter most: BSD-3-licensed, native BM25 hybrid, a module ecosystem for embeddings and rerankers, and Weaviate Cloud's entry tier is among the cheapest managed options. Milvus (with Zilliz as its managed cloud) is the billion-scale answer: a distributed, Apache-2.0 architecture built for hundreds of millions to billions of vectors that no single-node option matches, with the operational weight that implies.

Vespa is the heavyweight for teams whose problem is really search-and-ranking, not just vector lookup: an Apache-2.0 engine (out of Yahoo) that unifies vector, text, and structured data with rich, ML-driven ranking, powerful and correspondingly complex to operate. Marqo is the end-to-end option that folds embedding generation and storage into one Apache-2.0 system, which removes a moving part for teams that do not want to run a separate embedding pipeline. The honest split: pick Qdrant for fast filtered search at low cost, Weaviate for hybrid and modules, Milvus for raw scale, Vespa when ranking is the hard part, and Marqo when you want the embedding step handled for you.

The managed and serverless end: Pinecone and turbopuffer

If you would rather pay to make the database someone else's problem, this is the end of the spectrum, and the trade is control and portability for zero operations. Pinecone is the category's default fully-managed serverless option: proprietary, no servers to run, sparse-dense hybrid, and a serverless model that separates storage from compute so idle indexes cost little. It is the right pick for a team that wants to ship RAG without hiring anyone to run infrastructure, accepting closed-source lock-in and per-usage pricing as the cost. turbopuffer is the newer, cost-shaped challenger: an object-storage-first serverless engine that, by its own account, stores vectors on S3-class storage rather than RAM to cut cost dramatically for storage-heavy and many-namespace workloads. It is proprietary with no free tier and a monthly minimum, and it shines specifically when you have a lot of vectors that are queried unevenly. Choose Pinecone for the mature zero-ops default; choose turbopuffer when storage economics dominate your bill and you can live on a managed, closed platform.

The embedded and already-have-it options: Chroma, LanceDB, pgvector, Redis

For prototypes, local-first apps, and teams that should not add a database at all, the best answer often runs where you already are. Chroma is the prototyping default: Apache-2.0, embedded, dead-simple to start in a notebook, with a managed Chroma Cloud when you outgrow local. LanceDB is the embedded option for multimodal and edge: Apache-2.0, built on the Lance columnar format, runs in-process or in your cloud, and handles vectors alongside the raw data on object storage, which suits image and video RAG and offline apps.

The two "already-have-it" options are the ones most lists undersell. pgvector turns Postgres into a vector database with an extension under the PostgreSQL License: if your app data is already in Postgres, you get vector search with transactional consistency, mature SQL filtering, and zero new infrastructure, which is why it is the right first move for the majority of apps under roughly ten million vectors. Redis (via its Query Engine) adds vector search to a store many teams already run for caching, with very low latency, though note the 2025 license change: Redis 8 ships a tri-license (RSALv2, SSPLv1, or AGPLv3 at your option), so it is no longer plain-permissive open source and that may matter for some commercial deployments. The pattern in both cases is the data-gravity rule made concrete: adding vectors to a system you already operate beats standing up a dedicated database you do not yet need.

Which database for your situation

Match the move to where you actually are, not to the leaderboard. The shortlist falls out of the shape and your data gravity:

The honest verdicts

• Best first move for most teams

  already-have-it

  pgvector -- if your data is in Postgres and you are under ~10M vectors, this is the highest-ROI choice: vector search with transactional consistency and SQL filtering, zero new infrastructure. Graduate to a dedicated database when you actually outgrow it.

• Best open-source dedicated database

  self-hosted

  Qdrant -- Rust-built, Apache-2.0, fastest filtered search and cheapest to self-host, with a managed cloud when you want it. Weaviate is the pick when native hybrid and modules matter more than raw filter speed.

• Best at billion-scale

  self-hosted / managed

  Milvus / Zilliz -- a distributed architecture built for hundreds of millions to billions of vectors that single-node options cannot match. The trade is real operational weight; do not reach for it before you need the scale.

• Best zero-ops managed

  serverless

  Pinecone for the mature, fully-managed serverless default; turbopuffer when object-storage economics dominate your bill. Both are proprietary, which is the cost of handing off the operations.

• Best embedded / local-first

  embedded

  Chroma for fast prototyping and LanceDB for multimodal and edge. Both are Apache-2.0 and run in-process, with managed tiers when you outgrow a single node.

Methodology and conflict disclosure

If you build one of these databases and want to check that we have represented it fairly, or that a license or pricing detail has moved, we would genuinely welcome the correction. The goal of this page is to be the one map of the category that is not written by a database ranking itself first.

This is the retrieval layer that feeds the rest of your AI stack. Once your vector store is chosen, the next decisions live one layer up: the LLMOps stack (gateway, observability, evaluation, and guardrails around the model), the best AI agent frameworks that orchestrate retrieval, and the best AI coding assistants for the team building it.

Frequently asked questions

The bottom line

A vector database is not a leaderboard you win on recall; it is a deployment decision you match to your data. Hybrid search and filtering are standard now, so the engines are closer than the benchmarks suggest, and the real question is which of the four shapes (embedded, self-hosted, managed, serverless) fits your data gravity and ops capacity. Start where your data already lives: pgvector if you are on Postgres, Redis Query Engine if you run Redis, an embedded Chroma or LanceDB for prototypes. Reach for a dedicated database when you outgrow that, and pick by shape: Qdrant for fast self-hosted value, Weaviate for hybrid, Milvus for billion-scale, Pinecone or turbopuffer for zero-ops. The cheapest correct answer is almost always the system you do not have to add.

Sources

1. pgvector repository and license, github.com/pgvector/pgvector (PostgreSQL License, accessed June 2026).
2. Qdrant repository and pricing, github.com/qdrant/qdrant and qdrant.tech/pricing (Apache-2.0, usage plus perpetual free tier).
3. Weaviate repository and documentation, github.com/weaviate/weaviate and weaviate.io (BSD-3-Clause, native BM25 hybrid search).
4. Milvus and Zilliz documentation, milvus.io and zilliz.com (Apache-2.0, distributed billion-scale, sparse-dense hybrid from 2.4).
5. Pinecone documentation and pricing, pinecone.io (serverless, storage-compute separation, sparse-dense hybrid).
6. Chroma and LanceDB repositories, github.com/chroma-core/chroma and github.com/lancedb/lancedb (Apache-2.0, embedded).
7. turbopuffer documentation, turbopuffer.com (object-storage-first serverless; cost-savings figures per turbopuffer's own statements).
8. Vespa repository and documentation, github.com/vespa-engine/vespa and vespa.ai (Apache-2.0, unified ranking).
9. Marqo documentation, marqo.ai (Apache-2.0, end-to-end embedding and storage).
10. Redis repository and licensing notice, github.com/redis/redis (Redis 8 tri-license RSALv2/SSPLv1/AGPLv3) and Redis Query Engine vector documentation.