Open Source Vector Database: 8 Options and Their Licences

The best open source vector databases in 2026 are Milvus, Weaviate, Qdrant, pgvector, Chroma, LanceDB and OpenSearch, and the right one depends on three things: what the licence allows, how it self-hosts, and whether your vectors ever need to be queried alongside relationships. This list ranks eight options on those criteria. HelixDB is the pick when your vectors have relationships, and it's not the pick for a pure vector workload.

Most comparison pages read the licence off the GitHub sidebar. That field is an API guess and sometimes reads NOASSERTION. Here the licence comes from each project's LICENSE file, because "open source" is the first thing you need to be sure about before you ship a store inside a product.

Comparison table: licence, self-host modes, hybrid search, filtering, relationships

Here is the short version. "Relationships" means you can traverse connections between records in the same query as the vector search, not just filter on a metadata field.

Database	Licence	Self-host modes	Hybrid search	Filtering	Query relationships
Milvus	Apache-2.0	Self-hosted server	Yes	Metadata filtering	No
Weaviate	BSD-3-Clause outside wl/; separate licence for wl/ code	Docker, self-hosted	Yes	Yes	Cross-references only
Qdrant	Apache-2.0	Docker, distributed, Edge	Dense, sparse and multi-vector with fusion	JSON payload filters	No
pgvector	PostgreSQL License	Postgres extension	Via Postgres full-text	SQL WHERE	Via SQL joins
Chroma	Apache-2.0	Local and server	Yes	Metadata filters	No
LanceDB	Apache-2.0	Embedded	Yes	Yes	No
OpenSearch	Apache-2.0	Cluster	Yes (BM25 plus k-NN)	Yes	No
HelixDB	Apache-2.0	Embedded, Docker server, Cloud	Vector plus BM25 plus graph	Graph-scoped pre-filtering	Yes, multi-hop traversal

Licences for Weaviate and Qdrant are confirmed in their repositories. If you need a permissive Apache-2.0 vector store, six of the eight qualify.

1. Milvus

Milvus is the scale-first option, with an Apache-2.0 licence. It's built for large collections and distributed deployment, and it supports hybrid search and metadata filtering.

Pick it when your problem is billions of vectors and you have an ops team to run a multi-component cluster. The cost is operational weight, and a small RAG app doesn't need that machinery. Milvus has no relationship traversal, so connected context has to be rebuilt in application code.

2. Weaviate

Weaviate is the batteries-included option: collections, built-in vectorizer modules, hybrid search and several client libraries. Its repository contains a Community Edition and an Enterprise Edition.

Read the licence carefully. BSD-3-Clause covers code outside the wl/ directory, and code inside wl/ sits under a separate Weaviate License. That's permissive for most uses, but it isn't a single clean file, so have whoever signs off on licences read it. Weaviate lets you link objects with cross-references, which helps with simple connections but isn't multi-hop traversal.

3. Qdrant

Qdrant is the best pure vector engine on this list for filtered search, and it's Apache-2.0.

If your workload is similarity search with rich metadata filters, Qdrant is a strong default. It doesn't model relationships between records.

4. pgvector

pgvector is the right answer when you already run Postgres.

Its strength is that vectors live next to your relational data, so you get SQL filtering, joins and transactions for free. Its README is also candid about filtering: with approximate indexes, filtering is applied after the index is scanned, so a filtered query can return fewer results, and iterative index scans exist to mitigate that. It's the common first stop. Teams often outgrow it when recall under filters, hybrid retrieval or deep relationship traversal starts to matter.

5. Chroma

Chroma is the fastest way to get a prototype running, and it's Apache-2.0. It's popular as an open source vector store for LLM and RAG experiments because it runs locally with almost no setup.

It suits notebooks, demos and small production workloads. As data and concurrency grow, many teams move to a store with stronger distributed or filtering features. Like most on this list, it treats records as independent items. There are no relationships between them.

6. LanceDB

LanceDB is designed to run embedded within your application. That makes it a fit for local-first apps, data science workflows and pipelines where you don't want a separate server.

The trade-off is the usual one for embedded stores: you give up a managed server model and get zero network hops in return. It handles vector search and filtering, not relationship traversal.

7. OpenSearch

OpenSearch is the pick when you already run a search cluster. It supports vector search alongside traditional search capabilities, making hybrid queries straightforward.

If your team has OpenSearch operational muscle, adding vectors is cheaper than introducing a new database. It's a heavy footprint for a vector-only job, and it has no graph model.

8. HelixDB

HelixDB is an open source graph-vector database written in Rust, Apache-2.0 per the LICENSE file at github.com/HelixDB/helix-db. It puts graph traversal, vector search and BM25 full-text search in one engine. It's not the pick for a pure vector workload. If all you need is top-k similarity with metadata filters, Qdrant or pgvector will serve you with less to learn.

It is the pick when your vectors have relationships. Vectors are a property on nodes and edges, and the vector implementation is native. The practical gain is vector pre-filtering: a vector search can be scoped to entities related to each other, so similarity runs over a graph-filtered candidate set instead of the whole index. That's the case where top-k vector search returns orphaned chunks and you want the connected context around them. Documented limits apply: an unrestricted vector search caps at 800 effective results, and a candidate stream over 1,000,000 unique entities is a query error.

It runs embedded in your process (in memory or on disk), as a self-hosted Docker server (in memory, on disk, or against S3-compatible object storage), or on HelixDB Cloud, which is object-storage-backed with serializable snapshot-isolation transactions. In HelixDB's own benchmarks, vector performance is on par with Pinecone and Qdrant. Those are vendor numbers, not independent ones.

For how this plays out in practice, see Best Vector Database for RAG: 8 Options + When to Add Graph and the docs.

How we ranked them: licence from the LICENSE file, self-hosting, hybrid search, filtering, relationships

We ranked on five criteria, in this order.

Licence. Read from the LICENSE file, not the GitHub API field, which can read NOASSERTION. Apache-2.0 ranks above split or custom terms because it lets you embed and ship the engine without a legal review. If licence terms matter for a commercial product, our open source graph database licence guide covers the same question for graph engines.

Self-host modes. Can you run it embedded, in Docker and at cluster scale, or only one of those?

Hybrid search. Does vector search combine with keyword (BM25) retrieval in one query?

Filtering. Is metadata filtering part of the index search or applied afterwards? pgvector's README documents the post-filter behaviour, and Qdrant documents rich payload filtering.

Relationships. Can you traverse connections in the same query? This is where the list splits: seven options treat records as independent, and only HelixDB combines vector, text and multi-hop traversal in one engine. That criterion decides little for a plain similarity workload and a lot for agent memory and GraphRAG. See Agent Memory Graph vs Vector Store for Multi-Hop Reasoning.

Where Pinecone fits: a managed, not open-source, reference

Pinecone is a managed service and isn't open source, so it sits outside this ranking. It's the usual reference point because teams compare self-hosted options against its hosted convenience. If you can accept a vendor-run service and don't need source access or self-hosting, it belongs in your evaluation. If you need to own the deployment or embed the engine in your product, the eight options above are the relevant set.

Pick on licence first, then ask whether your vectors have relationships

For a pure vector workload, start with Qdrant if filtering matters, pgvector if you already run Postgres, and Milvus if scale is the constraint. If your RAG answers need connected context, or your agents need memory that follows relationships, one engine beats two databases kept in sync. Install HelixDB, run helix init local and helix start dev, and try a graph-scoped vector search against your own data. The repo is at github.com/HelixDB/helix-db, and a star helps others find it.