Vector Database Comparison for Sovereign RAG

pgvector is not a standalone database -- it is an extension to PostgreSQL that adds vector types and vector similarity search. This is its defining advantage and its defining limitation. The advantage: if you already run PostgreSQL, you add vector search with CREATE EXTENSION vector and you have a vector database. No new database to deploy, no new query language to learn, no new backup strategy, no new monitoring tool. Your existing Postgres DBA, your existing pg_dump backups, your existing replication setup, and your existing SQL queries all work with vectors as first-class citizens.

pgvector supports two index types. HNSW (Hierarchical Navigable Small World) is the default for most workloads: it builds a graph index that gives fast approximate search with tunable recall via the ef_search parameter. HNSW is the same algorithm Qdrant and many others use. IVFFlat (Inverted File with Flat quantization) is the older alternative: it partitions vectors into clusters and searches only the most relevant clusters. IVFFlat builds faster but has lower recall at high speeds than HNSW. For most sovereign RAG deployments, HNSW is the right choice.

When to Choose pgvector Over Qdrant

Two scenarios pull you toward pgvector. First: you need ACID transactions that include vector operations. If you want to insert a document, insert its chunks, insert their embeddings, and update a metadata table, all in one atomic transaction that either commits entirely or rolls back entirely, pgvector is the only option in this comparison that does that natively. Qdrant has no transactions across collections; neither does Chroma, Milvus, or Weaviate. For a medical records system where you must guarantee that a patient's record and its embeddings are written atomically, pgvector is the correct choice.

Second: you already have PostgreSQL infrastructure. If your application already runs on Postgres, adding a separate Qdrant container means a new database to monitor, back up, secure, and scale. If your vector count is under 10 million, pgvector with HNSW will perform well enough that the operational simplicity of one database outweighs Qdrant's raw speed advantage. For teams without a dedicated DBA or DevOps engineer, running one database instead of two is a significant reduction in operational risk.

Chroma is the easiest vector database to start with. It is Python-native, ships as a pip install (pip install chromadb), and runs in-process or as a small server. Under the hood, it uses DuckDB as its storage and query engine -- DuckDB is an embedded analytical database (like SQLite for analytics), which means Chroma has no external dependencies, no separate server process required for single-node use, and no network configuration for local development.

This makes Chroma the ideal prototyping database. If you are building a proof-of-concept RAG system, testing chunking strategies, or developing an embedding-model evaluation pipeline, Chroma lets you go from pip install to storing and retrieving vectors in under five minutes. The Python SDK is clean and intuitive: collection.add(documents=[...], embeddings=[...], metadatas=[...]) and collection.query(query_embeddings=[...], n_results=5). No Docker, no YAML, no server config.

The trade-off is scale and performance. Chroma is not designed for production workloads at millions of vectors. DuckDB is an in-process analytical engine, not a high-concurrency transactional server. Chroma's server mode exists and works, but it does not have the distributed mode, the quantization, or the payload filtering sophistication of Qdrant. For a personal AI assistant with 50,000 chunks, Chroma is perfectly adequate. For a medical practice with 5 million patient-document chunks and 50 concurrent clinicians querying it, Chroma will struggle.

When to Use Chroma

• Quick prototypes and proof-of-concept RAG systems
• Small datasets (under ~500K vectors)
• Development environments where you want zero infrastructure
• Embedding-model evaluation pipelines (fast iteration)
• Single-user personal AI assistants with modest collections
• Notebooks and tutorials (Chroma is the default in many LangChain tutorials)

Weaviate is a Go-based vector database distinguished by two features: a GraphQL API and a module system. The GraphQL API lets you query vectors and their metadata through typed GraphQL schemas, which is more expressive than REST for complex queries ("find documents about cardiology, return their text and their source file, filter by date range and department, limit to 10 results"). The module system is Weaviate's answer to the "you bring your own embedding model" problem: Weaviate can automatically call a configured embedding model (text2vec, text2vec-contextionary, multi2vec, image2vec) when you insert text or images, so you can insert raw documents and let Weaviate handle embedding.

For sovereign RAG, the module system is a double-edged sword. The convenience of inserting raw text and letting Weaviate embed it is appealing, but the default modules call cloud embedding APIs (OpenAI, Cohere). To keep embeddings on-premise, you must configure the modules to call a local embedding service (a local sentence-transformers model served via TorchServe, vLLM, or a custom HTTP endpoint). This is entirely possible -- Weaviate supports custom modules and local model servers -- but it requires more configuration than Qdrant, where you embed with your own model and insert the vectors directly.

Weaviate's multi-modal support is its strongest differentiator. The multi2vec module can store text and image vectors in the same collection and perform cross-modal search ("find images similar to this text description"). For a multi-modal RAG system that retrieves across text, images, and potentially audio, Weaviate is a strong contender. However, as the multi-modal RAG page explains, you can achieve the same thing with Qdrant by storing text and image vectors in the same collection with a modality field in the payload. The difference is that Weaviate has built-in support for the workflow, while Qdrant requires you to build it yourself.

When to Choose Weaviate

• Multi-modal RAG where you want built-in cross-modal search
• Teams that prefer GraphQL over REST for complex queries
• Use cases where automatic embedding (via configured modules) is preferred over bring-your-own-vectors
• Applications needing Weaviate's built-in question-answering and summarization modules

Milvus is the heavyweight of this comparison, in the literal sense. It is a C++ and Go-based vector database designed for billion-scale vectors across distributed clusters. If Qdrant is the lightweight single-node champion, Milvus is the distributed-systems champion. It was built by Zilliz (originally at Zilliz Cloud, now an independent open-source project under the LF AI & Data Foundation) specifically for the use case where you have 100 million to 10 billion vectors and need to search them across a cluster of machines.

Milvus supports multiple index types -- IVF_FLAT, IVF_PQ, IVF_SQ8, HNSW, ANNOY, DISKANN, and several GPU-accelerated indexes (GPU_IVF_FLAT, GPU_IVF_PQ, GPU_CAGRA). The GPU-accelerated indexes are Milvus's standout feature: if you have NVIDIA GPUs available, Milvus can use them for both indexing and search, achieving 10x+ throughput over CPU-only databases on large collections. For a sovereign deployment with a GPU-equipped server (which you likely already have for running the LLM), Milvus can repurpose that GPU for vector search during idle LLM time.

The cost of this power is operational complexity. A production Milvus deployment is not a single container. It requires Milvus itself plus etcd (configuration storage), MinIO or S3 (object storage for vector data), and Pulsar or Kafka (message queue for write operations). A standalone mode exists (single container with embedded dependencies) for development, but production deployments use the distributed mode with separate services. This is the right choice for an enterprise that already operates Kubernetes and has a DevOps team, and the wrong choice for a medical practice deploying RAG on a single server.

When to Choose Milvus

• Enterprise deployments with 100M+ vectors
• Use cases requiring GPU-accelerated vector search
• Organizations with Kubernetes infrastructure and DevOps capacity
• High-throughput ingestion (millions of vectors per hour)
• When horizontal scaling across multiple nodes is a hard requirement

LanceDB is the SQLite of vector databases. It is an embedded database -- no server process, no network port, no Docker container. You open a LanceDB database by pointing it at a directory on the filesystem, and you read and write vectors through a Python or Rust SDK. The data is stored in Lance format, a columnar format designed for machine learning workloads (like Parquet but optimized for random access and vector search). Under the hood, LanceDB uses a Rust core with an IVF-PQ index built on the Lance format.

This makes LanceDB the right choice for edge devices, single-user systems, and embedded RAG applications where you cannot or do not want to run a server. If you are building a personal AI assistant that runs on a laptop or a Raspberry Pi, LanceDB lets you store and search vectors without a database server. If you are building an embedded AI feature in a desktop application (a code search tool, a local document search app), LanceDB is the database that fits -- no server to install, no port to configure, no process to manage.

The Lance format is also notable: it is a columnar format, which means you can store vectors alongside structured metadata, images (as binary blobs or file paths), and text in the same table, and query any column without loading the others. For multi-modal RAG on resource- constrained devices, this is a meaningful advantage. LanceDB also supports disk-based indexes, so you can search collections larger than RAM without a server.

When to Choose LanceDB

• Edge devices and embedded systems (no server process possible)
• Single-user personal AI assistants running on a laptop or mini-PC
• Desktop applications with built-in RAG (code search, document search)
• Use cases where no server process can be run (IoT, kiosk, offline device)
• Prototyping where you want the simplicity of Chroma with better performance
• Columnar storage is a requirement (ML feature stores, multi-modal data)

FAISS is not a database. It is a C++ library (with Python bindings) for dense vector similarity search, developed by Facebook AI Research. It is the fastest pure vector search library in this comparison -- possibly the fastest in existence. FAISS implements every major ANN algorithm (IVF, IVF-PQ, HNSW, and GPU-accelerated variants) and is the algorithmic foundation that several other databases build on or benchmark against.

But FAISS has no CRUD operations, no persistence layer, no API server, no authentication, no metadata filtering, no replication, and no distributed mode. You load vectors into a FAISS index in memory, search them, and save/load the index to/from a file. If you want to add a vector, you rebuild the index (or use an incremental index type, which has limitations). If you want to delete a vector, you rebuild the index. If you want to filter by metadata, you do it yourself in Python after FAISS returns results. If you want the index to survive a process restart, you write code to serialize and deserialize it.

This means FAISS is the right choice when you want to build your own vector database. If you have a custom system with specific requirements that no existing database meets -- unusual index types, extreme performance requirements, integration with a custom storage layer -- you build it on FAISS. FAISS gives you the search engine; you build the database around it (persistence, CRUD, API, metadata, auth). This is the most work but gives you the most control.

For most sovereign RAG deployments, this is the wrong choice. The work of building a database around FAISS (persistence, concurrent access, metadata, backups, API) is exactly the work that Qdrant, pgvector, and Milvus have already done. Choose FAISS only when you have a specific need that requires custom engineering and you have the engineering capacity to build and maintain a database layer.

When to Choose FAISS

• Custom systems where you need maximum control over the search engine
• Research projects where you are experimenting with novel index types
• Embedded use where FAISS is wrapped in a larger application (not exposed as a database)
• Batch processing pipelines (index once, search many, no updates)
• When you need GPU-accelerated search and want to manage it yourself
• As a building block -- many other databases use FAISS internally

Redis is an in-memory data structure store. With the RediSearch module (now called Redis Search), it gained vector similarity search capabilities alongside its existing full-text search, geospatial, and key-value features. Redis Vector is fast -- everything is in RAM -- and it can do hybrid search (full-text + vector) in a single query, like Elasticsearch. The HNSW index is used for ANN search.

The defining characteristic of Redis is that it is in-memory by default. This is a strength (speed) and a weakness (persistence). Redis can persist to disk via RDB snapshots or AOF (append-only file) logs, but by default, if Redis crashes, you lose everything since the last snapshot. For a vector database holding the index of your RAG corpus, this means you must configure persistence carefully, or accept that a crash requires re-indexing from the source documents. Redis is not the right choice for the primary, durable store of your RAG embeddings -- but it is an excellent choice for a caching layer, a real-time retrieval layer, or an ephemeral search index that can be rebuilt from a durable source.

When to Choose Redis Vector

• Caching layer for hot vectors in front of a durable database
• Real-time retrieval where sub-millisecond latency is required
• Ephemeral search indices that can be rebuilt from source
• You already run Redis and want to add vector search without a new service
• Hybrid search (full-text + vector) with in-memory speed
• Session-based RAG where vectors are temporary (per-conversation context)

Elasticsearch (and its Apache 2.0 fork, OpenSearch) is a full-text search engine that added vector search (kNN) support. This makes it the only database in this comparison that does dense vector search and sparse (BM25) full-text search natively, in the same engine, in the same query. For hybrid search RAG -- where you combine semantic vector retrieval with keyword BM25 retrieval and fuse the results -- Elasticsearch/OpenSearch is the most integrated solution. You issue one query, it does both retrievals, and returns fused results.

The cost of this integration is weight. Elasticsearch is a JVM application. A single Elasticsearch node idles at 1-2GB RAM just for the JVM heap, before you load any data. A production cluster is at least three nodes for high availability, each with its own JVM. For a team that already runs Elasticsearch (for log search, product search, or analytics), adding vector search is a natural extension. For a team starting from scratch, standing up an Elasticsearch cluster for vector search alone is heavyweight compared to Qdrant.

OpenSearch vs. Elasticsearch: OpenSearch is the Apache 2.0 fork of Elasticsearch (created when Elastic changed its license in 2021). For sovereign deployments where license matters, OpenSearch is the better choice -- Apache 2.0 is unambiguously open source, while the Elastic License has restrictions on providing Elasticsearch as a managed service. Both support kNN vector search. OpenSearch is governed by the Linux Foundation and is vendor-neutral. We recommend OpenSearch over Elasticsearch for sovereign RAG.

When to Choose OpenSearch/Elasticsearch

• Hybrid search RAG (dense + sparse in one query) is the primary requirement
• You already run Elasticsearch/OpenSearch for full-text search
• Use cases requiring complex relevance tuning (scoring, boosting, function_score)
• Applications needing both vector search and aggregations/analytics on the same data
• Teams with JVM operations experience

Vespa is Yahoo's open-source search and ranking engine, designed for enterprise-scale real-time applications. It is the most powerful and the most complex database in this comparison. Vespa is not just a vector database -- it is a full search and ranking platform that supports vector search, full-text search, tensor computation (for ML model scoring at query time), and custom ranking pipelines written in Java or Rust. If your RAG system needs to rank retrieved documents by a custom ML model at query time (not just by vector distance), Vespa is the only option here that does that natively.

For example, a medical RAG system might retrieve 100 candidate chunks by vector similarity, then re-rank them by a custom model that considers document recency, clinician trust score, patient-specific relevance, and source authority -- all computed at query time inside the database. This is Vespa's sweet spot. No other database in this comparison supports custom ranking functions executed at query time against the retrieved results.

The cost is extreme complexity. Vespa has a steep learning curve, a complex deployment model (multiple services: config server, container, search node, log server), and requires understanding of its application package model (schemas, ranking expressions, services). A Vespa deployment is a multi-day engineering effort even for experienced teams. For most sovereign RAG deployments, this complexity is not justified -- Qdrant with a re-ranking cross-encoder in your application code achieves similar results with far less infrastructure. Choose Vespa when the query-time ranking pipeline is the core of your application and you have the engineering team to operate it.

When to Choose Vespa

• Large-scale production with custom ranking pipelines at query time
• Use cases requiring ML model scoring inside the database (tensor computation)
• Complex relevance tuning beyond what Elasticsearch scoring offers
• Organizations with search engineering teams and JVM operations experience
• Applications where ranking quality is the primary differentiator

Vald is a cloud-native vector database developed by Yahoo Japan. It is designed from the ground up for Kubernetes: it runs as a set of Kubernetes microservices, uses Kubernetes for service discovery, scaling, and fault tolerance, and is deployed via Helm chart. Its ANN algorithm is NGT (Neighborhood Graph and Tree), developed by the AIST (National Institute of Advanced Industrial Science and Technology, Japan). NGT is known for high recall and fast search, particularly for high-dimensional vectors.

Vald is the right choice if and only if your infrastructure is Kubernetes-native. If you are deploying RAG as part of a Kubernetes-based platform and want a vector database that fits naturally into that ecosystem -- Helm deployment, Kubernetes-native scaling, microservice architecture, gRPC API -- Vald is purpose-built for it. If you are not on Kubernetes, Vald is the wrong choice. It does not have a simple single-container deployment like Qdrant; it expects a Kubernetes cluster.

The NGT algorithm is Vald's technical differentiator. NGT builds a graph-based index that achieves high recall at high speeds, especially for high-dimensional vectors (768d, 1024d, 1536d). For RAG systems using modern embedding models (which produce high-dimensional vectors), this is a meaningful advantage over IVF-based indexes. However, HNSW (used by Qdrant, pgvector, and others) is also a graph-based index with similar characteristics, so the practical advantage of NGT over HNSW is modest in most workloads.

When to Choose Vald

• Kubernetes-native deployments (this is a hard requirement)
• Organizations with Kubernetes operations expertise
• Use cases wanting NGT's high-recall high-dimensional search
• Microservice architectures where gRPC and Helm fit naturally
• Teams that want a vector database that scales with Kubernetes