If you are comparing open source vector databases for a RAG system, start with where search should live. pgvector is usually the first choice when the application already depends on PostgreSQL. Relational joins, transactions, backups, and familiar SQL can matter more than a separate search service. (Source: pgvector README)

Qdrant is a strong fit for a dedicated vector search service with metadata filtering, hybrid retrieval, and self-hosting requirements. (Source: Qdrant documentation)

Milvus fits larger distributed workloads where search and application storage need to scale separately. (Source: Milvus documentation)

Weaviate is useful when integrated vector and keyword search features matter more than keeping the system minimal. (Source: Weaviate documentation)

There is no universal best open-source vector database for RAG. Choose from the matrix using your data model, filters, growth, updates, latency target, recovery process, and tolerance for another production system. Then run the comparison protocol before moving important data. (Source: Independent benchmark paper)

What "open source vector databases" means here

For this guide, "open source" means the core project is released under a named OSI-approved license and has a self-hosted distribution. A public repository alone is not enough. The license names in the table apply to the core projects; hosted services, plugins, and commercial add-ons may have separate terms. Running a self-hosted vector database still requires compute, storage, backups, monitoring, upgrades, and on-call time. (Source: Qdrant documentation)

The word "free" needs its own check. A project can have no software fee while still creating infrastructure and operator costs. Treat license permissions, hosted-service terms, and total operating effort as separate questions. (Source: Qdrant documentation)

DatabaseCore project licenseBest fitFiltering and hybrid searchDeployment modelPostgreSQL relationshipMain operational tradeoff
QdrantApache-2.0Filtered and hybrid retrievalPayload and boolean filters; dense and sparse Query API fusionDocker, Kubernetes, or managed CloudSeparate service; sync IDs and metadataSelf-hosting means owning storage, HA, backups, and monitoring. (Source: Qdrant documentation)
MilvusApache-2.0Distributed vector workloadsScalar filters, hybrid retrieval, and multiple index familiesLite, Standalone, or Distributed KubernetesSeparate system; joins stay elsewhereMore components and deployment planning as it grows. (Source: Milvus documentation)
WeaviateBSD 3-ClauseIntegrated vector and keyword searchStructured filters plus vector and BM25 hybrid searchHosted or self-managedSeparate store from PostgreSQLMore configuration than a minimal service. (Source: Weaviate documentation)
pgvectorPostgreSQL LicensePostgreSQL applications with vector searchSQL predicates, HNSW or IVFFlat, and full-text hybrid searchPostgreSQL extension, managed or self-hostedNative joins, transactions, and recoveryANN indexes share resources and need maintenance. (Source: pgvector README)

Decision criteria and the practical decision tree

Choose by workload shape, then answer these questions before choosing an engine.

  1. Start with PostgreSQL. Joins, authorization, transactions, and point-in-time recovery favor pgvector when PostgreSQL already owns the records. (Source: pgvector README)
  2. Describe filters before embeddings. Tenant, ACL, language, product, time, and document type affect query behavior. (Source: Qdrant documentation)
  3. Decide whether hybrid retrieval is required. Exact names, error codes, and product terms need lexical matching; check score fusion. (Source: Qdrant documentation)
  4. Estimate collection size and growth. Fast growth may justify separate storage and query workers, which Milvus documents as part of its architecture. (Source: Milvus documentation)
  5. Model updates and deletes. Measure freshness and background index work, especially for filtered approximate search. (Source: pgvector README)
  6. Set latency and recall targets together. Measure p50 and p95 against exact or judged relevance, not an index label. (Source: Independent benchmark paper)
  7. Include backup, restore, upgrades, and monitoring. Qdrant's self-managed path makes these responsibilities explicit. (Source: Qdrant documentation)
  8. Estimate migration risk. Compare dimensions, distances, IDs, metadata, filters, hybrid scoring, export, and rollback steps.

Practical decision tree

  • Choose pgvector when PostgreSQL already owns the data and you want one SQL and recovery path. (Source: pgvector README)
  • Choose Qdrant when retrieval needs a focused self-managed service with payload filters and dense plus sparse queries. (Source: Qdrant documentation)
  • Choose Milvus when growth justifies separated components, multiple indexes, and Kubernetes-based operation. (Source: Milvus documentation)
  • Choose Weaviate when an integrated vector and keyword platform is worth extra configuration. (Source: Weaviate documentation)

Qdrant: dedicated filtered and hybrid retrieval

Qdrant is a good starting point when search should sit beside the application database. Its payload model supports field, boolean, and nested filters. The Query API can prefetch named vectors and fuse dense and sparse retrieval. That matches RAG systems with tenant filters and exact-term recovery. (Source: Qdrant documentation)

The tradeoff is another stateful service. Qdrant's self-managed guidance calls out storage, security, high availability, backups, disaster recovery, monitoring, and logging. It is a poor fit when transactionally consistent joins matter or the team cannot operate a second datastore. (Source: Qdrant documentation)

Before adoption, check payload indexes, dense and sparse fusion, snapshot and restore, version upgrades, and which system owns changed metadata. (Source: Qdrant documentation)

Milvus: distributed vector search at larger scale

Milvus is aimed at teams that want vector search separate from the application database. Its architecture separates access, coordinator, worker, and storage responsibilities, with object storage and a write-ahead log. Deployments range from Lite and Standalone to Distributed Kubernetes. The docs cover HNSW, IVF, FLAT, SCANN, DiskANN, scalar filters, and sparse or full-text hybrid retrieval. (Source: Milvus documentation)

That flexibility has a cost. A small RAG application with existing PostgreSQL may gain little from the extra components. Milvus is a poor fit when the team cannot explain ownership of ingestion, object storage, message flow, and recovery. (Source: Milvus documentation)

Before adoption, pin the deployment shape, storage and message dependencies, index settings, compaction plan, failure behavior, and clean restore test. (Source: Milvus documentation)

Weaviate: an integrated search platform

Weaviate fits a team that wants more of search in one product. Its filters combine property conditions with boolean operators. Hybrid search runs vector and BM25 retrieval together, then fuses scores through relative-score or ranked fusion. That suits RAG applications needing semantic recall, exact terms, and structured filters in one search layer. (Source: Weaviate documentation)

Weaviate can run hosted or self-managed. It is a poor fit when you only need a thin vector endpoint, or when PostgreSQL must remain the relational source of truth. The team may also not want to own schema, persistence, replica, and version decisions. The platform can save integration work, but it still needs operating discipline. (Source: Weaviate documentation)

Before adoption, settle vectorizer ownership, filter schema, fusion setting, replica and persistence plan, and upgrades. Test empty filters, highly selective filters, lexical terms, and mixed-language records. (Source: Weaviate documentation)

pgvector: vector search inside PostgreSQL

pgvector is the natural first test when searchable data already lives in PostgreSQL. It supports exact nearest-neighbor search plus HNSW and IVFFlat approximate indexes. SQL can apply predicates, joins, and authorization rules. The README also documents full-text hybrid patterns, replicas, point-in-time recovery, and PostgreSQL monitoring. (Source: pgvector README)

The cost is shared resource contention and maintenance. Approximate indexes can use more memory or take longer to build, and predicates may be applied after a scan. pgvector documents iterative scans, partial indexes, and partitioning for filtered workloads. It is a poor fit when vector-only traffic needs independent scaling or would compromise the application database. (Source: pgvector README)

Before adoption, choose exact, HNSW, or IVFFlat from measured recall and latency; test update churn, vacuum, reindex, and restore from PostgreSQL's normal backup path. The question is whether one database can meet both transaction and retrieval SLOs. (Source: pgvector README)

How to compare them fairly

Do not compare tuned Qdrant with default pgvector settings and call it a product verdict. Freeze retrieval variables, then report operational cost beside query numbers. The 2026 independent evaluation used multiple datasets and metrics for this reason. (Source: Independent benchmark paper)

Use this reproducible protocol:

  1. Use the same embedding model and version, vector dimension, distance function, and normalization rule.
  2. Use the same dataset, IDs, metadata, language mix, and chunking rules. Keep the chunk manifest.
  3. Use the same query set, top-k value, query order, and metadata filters, including broad and selective filters.
  4. Record index goals, engine parameters, build time, ingest throughput, and insert or delete visibility. Do not hide tuning behind "optimized."
  5. Run cold and warm query passes. Record p50 and p95 latency, timeouts, concurrency, and throughput.
  6. Measure recall against exact results where possible. Add judged relevance or NDCG when exact recall is insufficient.
  7. Record peak memory, steady-state memory, index size, raw storage, backup size, machine, versions, and replicas.
  8. Restore a backup on a clean target. Verify counts, filters, top-k results, restore time, and acceptable recovery point. This article contains no first-hand benchmark results. The protocol is a test plan, not a measurement performed for this guide. A real run can change the choice for your data and hardware.

Is an open-source vector database always necessary?

No. If PostgreSQL owns the records, PostgreSQL full-text search plus pgvector may cover semantic retrieval, exact terms, relational filters, and transactions with one recovery path. That is often the lowest-risk design for a smaller application if the combined workload meets its latency and availability targets. (Source: pgvector README)

An existing search system may be enough if it supports vector fields, metadata filters, lexical search, replicas, and the team's backup process. MongoDB is one document-database example with vector search. Add a dedicated engine only for a measured scaling, filter, recall, or isolation problem. (Source: MongoDB documentation)

If you are building RAG, first ask whether the current database meets the retrieval contract. Then compare a dedicated engine with the same dataset and queries. A tool with no software fee is not automatically cheaper than the database your team already monitors. (Source: Independent benchmark paper)

FAQ

Is there a free vector database?

Yes. Qdrant is one example with a self-managed distribution. "Free" usually means no hosted or software charge, not zero compute, storage, backups, monitoring, or engineering cost. (Source: Qdrant documentation)

Are vector databases dead?

No. The independent evaluation still measures vector search as a live workload across several systems. The practical question is whether a dedicated engine earns its operating cost for your application. (Source: Independent benchmark paper)

What is replacing a vector database?

There is no single replacement. PostgreSQL with pgvector can cover vector search inside a relational system, while other databases may expose vector fields as part of a broader search feature. Choose based on filters, recall, latency, recovery, and data model, not a category forecast. (Source: pgvector README)

Is MongoDB a vector DB?

MongoDB is primarily a document database with vector search. Its vectorSearch operator searches embeddings and supports pre-filtering, making it a valid choice for document-centric applications. It is not a dedicated vector database. Evaluate its document model, indexes, deployment mode, and recovery process. (Source: MongoDB documentation)

Recommendation summary

If PostgreSQL already owns your data, test pgvector first. Use Qdrant for a separate filtered and hybrid retrieval service. Move to Milvus when distributed growth justifies its operational shape. Pick Weaviate when its integrated search features reduce more work than they add. If two options remain close, run the protocol and compare restore behavior and operator effort, not just query latency. (Source: Independent benchmark paper)

Related coverage

References