7 Best Open-Source Vector Databases in 2026

Qdrant is the best balanced open-source vector database for most teams starting a dedicated retrieval service in 2026. It combines focused vector search, metadata filtering, hybrid retrieval, and a manageable path from one server to a distributed deployment.

That does not make Qdrant the right answer for every architecture. If your application already runs on PostgreSQL, pgvector may be the more sensible choice. Weaviate is strong when semantic and keyword retrieval belong in one system. Milvus fits distributed, vector-heavy workloads. Chroma is approachable for local development. LanceDB suits embedded multimodal data. OpenSearch makes sense when vector retrieval belongs inside a wider search and analytics platform.

This guide includes only projects whose relevant core repository uses an Open Source Initiative approved license. It compares the products by architecture, deployment, retrieval features, and operational burden. It also gives you a reproducible checklist for testing the final candidates against your workload.

Best Open-Source Vector Databases by Use Case

These recommendations are starting points, not benchmark winners. Your filtering patterns, write volume, concurrency, existing infrastructure, and operational skills can change the result.

What Counts as an Open-Source Vector Database?

Public source code does not automatically make a product open source. For this comparison, the relevant core software must use a license approved by the Open Source Initiative, and you must be able to run the software yourself.

That distinction removes proprietary managed systems such as Pinecone from the main list. It also separates an open-source engine from the commercial service built around it. Qdrant, Weaviate, Milvus, Chroma, and other projects offer hosted products, but their managed services have separate terms, pricing, and operational responsibilities.

License names also matter. Qdrant, Milvus, Chroma, LanceDB, and OpenSearch use the Apache License 2.0. Weaviate uses the BSD 3-Clause License, and pgvector uses the PostgreSQL License. All three are OSI-approved licenses.

This article reports the license used by each repository. It does not provide legal advice. Review the license text and your organization's requirements before distributing modified software or embedding it in a commercial product.

Database, extension, library, or search platform?

The products in this market do not all solve the same operational problem.

• Qdrant, Weaviate, Milvus, and Chroma are dedicated vector data systems.
• pgvector is an extension that adds vector types and search to PostgreSQL.
• LanceDB is an embedded retrieval and multimodal data library.
• OpenSearch is a search and analytics platform with vector capabilities.
• Faiss is a vector indexing and similarity-search library, not a complete database.

This classification matters more than feature-count tables. A team that already operates PostgreSQL may gain little from adding a new service. A team building an image-search pipeline may value an embedded multimodal layer more than cluster replication. A search team may need lexical search and analytics alongside embeddings.

If you are still deciding whether you need a specialized system at all, start with the broader guide on how to choose a vector database.

How These Databases Were Compared

Each product had to meet six requirements:

1. The relevant core repository uses an OSI-approved license.
2. The software can be self-hosted.
3. It stores or manages vectors rather than only generating embeddings.
4. It supports similarity retrieval.
5. It has current public documentation.
6. It has a defensible use case for developers or production teams.

The comparison then evaluates:

• Product category
• License
• Deployment model
• Dense and sparse retrieval
• Hybrid search
• Metadata filtering
• Distribution and replication
• SDK and integration support
• Operational burden
• Best fit and poor fit

Performance is intentionally not reduced to one ranking. A vector database can increase queries per second by accepting lower recall, using more memory, or changing index settings. Valid comparisons must hold the dataset, embedding dimensions, hardware, recall target, filters, concurrency, write workload, and software version reasonably constant.

VectorDBBench provides an open-source framework for reproducible tests, including search, insertion, filtering, latency, throughput, and recall scenarios. Zilliz, the company closely associated with Milvus, maintains it, so its methodology and product configurations should still be reviewed before treating a result as independent.

Open-Source Vector Database Comparison

“Native” means the project documents the retrieval and fusion workflow as part of its product. It does not mean the default configuration will produce the best relevance for your data.

1. Qdrant: Best Balanced Open-Source Vector Database

Qdrant is the best starting point when you want a dedicated vector service but do not yet have a constraint that clearly favors another product.

The Qdrant repository uses Apache License 2.0. Qdrant stores records as points containing one or more vectors plus an optional JSON payload. Those payload fields can be indexed and used as structured filters during similarity search.

Its retrieval model supports dense vectors, sparse vectors, and multivectors. Qdrant's hybrid-query interface can combine retrieval stages using techniques such as reciprocal rank fusion. This is useful for RAG systems that need semantic similarity and exact term matching.

Qdrant can run as a single service, but it is not limited to one node. Its distributed deployment divides collections into shards and can replicate those shards across cluster nodes. Replication supports read scaling and node-failure tolerance.

Choose Qdrant when:

• You want a focused vector-retrieval service.
• Metadata filtering is central to the workload.
• You need dense and sparse retrieval.
• You want a path from a simple deployment to a distributed cluster.
• You want both open-source and managed deployment choices.

Avoid Qdrant when:

• PostgreSQL already meets the retrieval requirement.
• You need a full search and analytics suite.
• Operating another service would create more cost than value.

If this is your preferred option, use the Qdrant getting-started guide for the implementation steps.

2. pgvector: Best When You Already Use PostgreSQL

pgvector is the practical default when PostgreSQL already stores the records connected to your embeddings.

The pgvector project adds vector columns and distance operations to PostgreSQL. It supports exact and approximate nearest-neighbor search, single-precision and half-precision vectors, binary vectors, sparse vectors, and several distance functions. Its approximate index choices include HNSW and IVFFlat.

The architectural benefit is consolidation. Your vectors can live beside users, documents, permissions, product records, or other relational data. You keep PostgreSQL joins, transactions, backups, point-in-time recovery, access controls, and existing client libraries.

That does not mean pgvector always matches a purpose-built service. PostgreSQL must handle the vector workload alongside its other responsibilities. Heavy ingestion, strict tail-latency targets, or independently scaled search traffic may justify a separate retrieval system.

Choose pgvector when:

• Your application already runs on PostgreSQL.
• Related relational data and vector data must stay together.
• SQL filters, joins, and transactions matter.
• Your team wants to minimize infrastructure components.

Avoid pgvector when:

• Vector retrieval dominates the system.
• Ingestion and queries need independent scaling.
• You need a distributed architecture designed specifically around vector workloads.

Before adding a separate database, test the real workload with PostgreSQL. The complete pgvector guide covers indexes, queries, filtering, and tuning in more depth.

3. Weaviate: Best for Integrated Hybrid Search

Weaviate is a strong choice when your retrieval layer must combine semantic similarity with exact keyword relevance.

The Weaviate repository uses the BSD 3-Clause License. Weaviate stores objects and their vectors, supports structured filtering, and exposes vector, keyword, and hybrid retrieval through its APIs.

Its hybrid search runs vector search and BM25 keyword search in parallel, then combines their results. This helps with queries that contain product codes, names, legal clauses, or technical identifiers that dense embeddings may not retrieve reliably.

Weaviate also provides optional vectorizer and reranker modules. Those modules reduce application code when their supported providers and workflow fit your project. Teams that want full control over embedding generation and reranking can supply their own vectors and keep those steps outside the database.

Choose Weaviate when:

• Semantic and keyword retrieval must work together.
• Built-in retrieval modules reduce useful application work.
• You want one system for objects, vectors, filters, and hybrid search.

Avoid Weaviate when:

• You need only a narrow vector-search service.
• Your application already has a capable PostgreSQL or OpenSearch layer.
• You want every embedding and reranking step controlled in application code.

Weaviate's feature breadth is useful, but it also creates more configuration choices. Evaluate relevance with your actual queries rather than assuming native hybrid search needs no tuning.

4. Milvus: Best for Distributed Vector-Heavy Workloads

Milvus is designed for teams whose workload justifies a distributed vector architecture and the platform engineering that comes with it.

The Milvus repository uses Apache License 2.0 and sits under the LF AI & Data Foundation. It provides Milvus Lite for a local workflow, a standalone server, and a distributed deployment.

In its distributed architecture, compute and storage are separated. Query nodes can be scaled for read-heavy workloads, while data nodes handle write-heavy work. This is a useful design when search and ingestion grow at different rates.

Milvus supports dense vectors, sparse vectors, full-text search with BM25, filtering, and hybrid retrieval. It also exposes multiple index and quantization choices. That flexibility helps specialized workloads, but it gives teams more settings and components to understand.

Choose Milvus when:

• You need a distributed vector-focused platform.
• Search and ingestion need separate scaling controls.
• Your team already understands Kubernetes and distributed data operations.
• Multiple index strategies are valuable for the workload.

Avoid Milvus when:

• The project is small or early.
• Operational simplicity is a higher priority.
• PostgreSQL or a focused single-service deployment solves the task.

Do not choose Milvus because a page attaches an arbitrary vector-count threshold to it. Choose it when your measured workload and operating model justify its architecture.

5. Chroma: Best for Beginners and Local Development

Chroma offers the most approachable path for developers learning vector retrieval or building an early application.

The Chroma repository uses Apache License 2.0. Its API can store documents, embeddings, and metadata in collections. You can let Chroma generate embeddings through an embedding function or supply vectors created elsewhere.

Chroma supports several ways to run. An in-memory client is useful for experiments. A persistent client writes data to a local path. The official client documentation positions that persistent local client for local use, while client-server mode runs Chroma as a separate process for applications that need a server-backed deployment.

This makes “Chroma is only for prototypes” too broad. Local Chroma is easy to prototype with, but the project also documents self-hosted server operation and offers a managed cloud product. The correct question is whether its server architecture and operational controls meet your production requirements.

Choose Chroma when:

• You want to start locally with little setup.
• You are learning embeddings and retrieval.
• Your application has a straightforward document and metadata model.
• You want a path from an in-process workflow to a separate server.

Avoid Chroma when:

• You already know you need a complex distributed self-hosted architecture.
• Your organization needs the wider search features of OpenSearch.
• Relational transactions make PostgreSQL a better home for the data.

Chroma wins this category because it reduces the distance between an idea and a working retrieval loop, not because local defaults should be copied directly into production.

6. LanceDB: Best for Embedded Multimodal Data

LanceDB is the most distinct option in this comparison. It is an embedded retrieval library and multimodal data layer rather than a conventional client-server vector database.

The LanceDB repository uses Apache License 2.0 and builds on the Lance columnar format. Its open-source edition runs locally or in your cloud and supports Python, TypeScript, and Rust workflows.

The LanceDB search documentation covers vector search, multivector search, BM25 full-text search, hybrid retrieval, metadata filtering, and SQL queries. Multivector support is useful for late-interaction models and multimodal representations where one item may have several embeddings.

Embedding LanceDB close to application or data-science code can simplify local analysis, model training, agent memory, and multimodal search. The trade-off is that distributed service capabilities belong to LanceDB's commercial products rather than the local open-source library.

Choose LanceDB when:

• Retrieval should run inside or close to application code.
• Your data includes text, images, audio, video, or other multimodal records.
• The same data layer supports retrieval and model-training workflows.
• A local columnar format is useful.

Avoid LanceDB when:

• You need an open-source distributed server architecture.
• Every language needs identical local and remote capabilities.
• Your organization already standardizes on PostgreSQL or OpenSearch.

LanceDB should not be judged by the same operational checklist as Milvus. They occupy different layers of an AI system.

7. OpenSearch: Best for Search, Analytics, and Vectors Together

OpenSearch is the right candidate when vector retrieval is one part of a wider search and analytics requirement.

The OpenSearch core repository uses Apache License 2.0. Its knn_vector field stores embeddings and supports vector search through configurable methods and engines.

OpenSearch provides exact and approximate k-nearest-neighbor search, filtering, and radial search. Its hybrid-search pipeline combines keyword and semantic search results by normalizing and combining scores.

The advantage is consolidation for search teams. The same platform can support lexical search, vector search, analytics, dashboards, and observability use cases. The cost is scope. Operating OpenSearch for a small RAG application can be more work than operating a focused vector service.

Choose OpenSearch when:

• Your organization already runs OpenSearch.
• Keyword search, analytics, and vector retrieval belong together.
• The application needs broader search capabilities than a dedicated vector API.

Avoid OpenSearch when:

• You need only a focused retrieval service.
• You want the simplest local development path.
• The wider platform creates unnecessary operational work.

If you are comparing a search platform with a dedicated vector system, read the guide to Elasticsearch and dedicated vector databases. The architectural questions also apply to OpenSearch, although their licenses and product roadmaps differ.

Is Faiss a Vector Database?

No. Faiss is an MIT-licensed library for similarity search and clustering of dense vectors.

Faiss provides exact and approximate index algorithms, CPU and GPU implementations, parameter tuning, and support for datasets that may not fit entirely in memory. These capabilities make it an important building block for vector systems.

It does not give your application the complete operational layer people normally expect from a database. You still need to design persistence for the associated records, metadata filtering, authentication, replication, backups, multi-user APIs, and monitoring.

Use Faiss when you need direct control over an in-process vector index and are prepared to build the surrounding system. Do not choose it as a drop-in replacement for Qdrant, Weaviate, Milvus, or another operational database.

How to Choose the Right Open-Source Vector Database

Start with the system you already operate.

• If PostgreSQL stores your application data, test pgvector first.
• If OpenSearch already powers search, test its vector features first.
• If retrieval belongs inside a multimodal application, test LanceDB.
• If you need a new dedicated retrieval service, begin with Qdrant.
• If native keyword and vector fusion is central, compare Weaviate and OpenSearch.
• If the workload needs independently scaled distributed components, evaluate Milvus.
• If you are learning or building locally, start with Chroma.

This order avoids a common infrastructure mistake. Teams sometimes add a specialized vector database before proving that their existing database cannot meet the requirement. The new service then adds deployment, monitoring, backup, security, and data-synchronization work without solving a measured problem.

The second step is to test the part of your workload most likely to break the system. For many RAG applications, that is not unfiltered nearest-neighbor search. It is filtered search under concurrent reads while new documents are being ingested.

If you need the wider retrieval context first, read how vector databases work in RAG.

Reproducible Vector Database Evaluation Checklist

A useful proof of concept starts with a written workload definition. Do this before installing the first candidate.

1. Define the data

• Number of records now and expected growth
• Embedding dimensions and numeric type
• Average document and metadata size
• Number and selectivity of metadata filters
• Update and deletion frequency
• Number and size of tenants
• Retention and backup requirements

Use real records where security policies allow it. Synthetic vectors can test the index, but they rarely reproduce your metadata distribution or query behavior.

2. Define retrieval quality

• Create exact-search ground truth for a representative subset.
• Measure recall@k for approximate search.
• Measure precision@k or relevance with labelled queries when the application cares about semantic usefulness.
• Test filtered recall, not only unfiltered recall.
• Evaluate dense, sparse, and hybrid retrieval separately.
• Include product codes, names, rare terms, and ambiguous questions.

ANN recall and end-user relevance are different measurements. High recall against exact vector search does not prove that the embedding model returns useful documents. It only shows how closely the approximate index reproduces the exact vector ranking.

3. Measure performance under load

• P50, P95, and P99 query latency
• Queries per second at fixed concurrency
• Index-build time
• Time until an inserted record becomes searchable
• Performance during continuous ingestion
• Performance with realistic filters
• Memory and disk use
• Recovery time after a process or node failure

Do not compare one database at 90 percent recall with another at 99 percent recall and call the faster result a winner.

4. Test operations

• Backup and restore
• Replication and failover
• Version upgrades
• Authentication and authorization
• Tenant isolation
• Monitoring and alerting
• Client compatibility
• Schema or collection migrations
• Deletes required by retention policies

An engine that wins a query benchmark can still lose the project if your team cannot restore it, debug it, or upgrade it safely.

5. Compare total ownership

Open-source software still consumes infrastructure and engineering time. Record:

• Compute, memory, disk, and network cost
• Setup time
• Routine maintenance
• Incident response
• Upgrade effort
• Backup storage
• Managed-service premium
• Expected migration cost

Run the same test definition against the final two candidates. Keep configurations public inside your team so the decision can be reproduced when the workload changes.

Final Recommendation

Use pgvector first when PostgreSQL already fits your architecture. It keeps embeddings with the data and avoids another service.

For a new dedicated retrieval system, Qdrant is the balanced default. It has a focused architecture, strong payload filtering, hybrid retrieval, and a path to distributed deployment without forcing every team to begin with a complex cluster.

Choose Weaviate when integrated keyword and vector retrieval is the priority. Choose Milvus when distributed vector infrastructure and independent component scaling justify the operational work. Choose Chroma for the easiest learning and local-development path. Choose LanceDB for embedded multimodal workflows. Choose OpenSearch when vector retrieval belongs inside a broader search and analytics platform.

Do not make the final decision from this article alone. Use it to narrow the list to two products, then run the evaluation checklist with your data and queries.

For a comparison that also includes proprietary managed services, continue with the complete guide on how to choose a vector database.