For most teams the honest answer is pgvector, because the Postgres you already run will do the job and one less stateful service is worth a great deal. It caps out at 2,000 dimensions per index and does not shard, so a corpus past a few million vectors is where a dedicated engine starts to earn its keep. The seven below are ordered by when that moment arrives.
8 tools reviewedLast reviewed Ranked by us, not by votes
What counts as vector databases for RAG
A vector database stores embeddings (numeric arrays produced by an embedding model) alongside metadata, and answers nearest-neighbour queries over them, usually with approximate algorithms such as HNSW or IVF. In a retrieval-augmented generation pipeline it is the retrieval step: given an embedded user question, it returns the handful of source chunks that get placed into the prompt. The category covers dedicated engines built only for this job, general-purpose databases and search engines that have added vector indexes, and extensions that add vector search to a database you already run. It does not cover embedding models, chunking libraries, agent frameworks, or application hosting platforms.
How we judged them
Entries were judged first on whether a separate system is needed at all: for most teams the honest starting question is whether the Postgres already in production will do the job, and only workloads that outgrow it justify a dedicated engine. Beyond that we weighted filtered and hybrid search behaviour, whether you can self-host or must use a vendor cloud, licence terms, operational burden, and how predictable the bill stays as a corpus grows. Every entry was checked against the vendor's own site, pricing page, or source repository during research, and each limitation is drawn from documented behaviour and published limits rather than from benchmarks or opinion. Products that are not vector stores, including hosting platforms and application starter templates, were excluded.
All 8 vector databases for RAG in this guide, in ranked order.
github.com · No licence fee. Cost is whatever you already pay for the Postgres instance, and most managed Postgres services include the extension at no extra charge.
Best for Teams whose corpus fits comfortably on one Postgres instance and who would rather add a column than operate a second stateful service.
An open-source PostgreSQL extension that adds vector column types and approximate nearest-neighbour indexes to a database you may already be running.
Strengths
Keeps embeddings in the same transaction, backup, and point-in-time recovery story as the rest of your data, so there is no sync job between a primary database and a separate index
Supports both HNSW and IVFFlat indexes, and L2, inner product, cosine, L1, Hamming, and Jaccard distance
Filters are ordinary SQL, so metadata conditions, joins, and permission checks use the query planner you already understand
Released under the permissive PostgreSQL licence and offered at no additional charge by most managed Postgres providers
Handles half-precision, binary, and sparse vector types, which cuts storage for large corpora
Where it falls short
HNSW and IVFFlat indexes accept at most 2,000 dimensions for standard and half-precision vectors, so full-size embeddings from some models must be reduced, quantized, or left unindexed
The README documents that with approximate indexes filtering is applied after the index is scanned, so a selective WHERE clause can return fewer rows than requested unless iterative index scans are enabled
HNSW index builds are slow and want the graph to fit in maintenance_work_mem; the extension emits a notice once it no longer does
There is no native horizontal sharding for vector search, so scaling beyond one machine means Citus, read replicas, or manual partitioning
Hybrid keyword plus vector search must be assembled from Postgres full-text search yourself rather than called through one API
qdrant.tech · Free to self-host. Managed cloud has a free prototype tier, then resource-based hourly billing on vCPU, memory, and storage; premium, hybrid, and private tiers are quoted by sales with a minimum spend.
Best for Teams that have genuinely outgrown Postgres and want a dedicated engine they can also run themselves without a licence negotiation.
An Apache 2.0 licensed vector search engine written in Rust, available as self-hosted software, a managed cloud, or a Kubernetes-based hybrid deployment.
Strengths
Core engine is Apache 2.0, so self-hosting carries no licence restriction and there is a credible exit path from the managed service
Payload filtering is a first-class feature, with keyword, numeric range, and geo conditions applied alongside the vector search
Supports dense, sparse, and multi-vector search with configurable fusion, which covers hybrid retrieval without a second system
Built-in quantization reduces RAM requirements, and the engine supports SIMD and GPU acceleration
Deployment ladder runs from a single container to managed cloud, hybrid Kubernetes, private air-gapped, and on-device
Where it falls short
Hybrid Cloud and Private Cloud pricing is not published and requires contacting sales
Hybrid Cloud requires you to bring and operate your own Kubernetes cluster
The free cloud tier is a single small node intended for testing and prototypes, with no high availability
Self-hosting adds a second stateful service to back up, upgrade, and monitor alongside your primary database
Serverless is listed as coming soon rather than available, so usage-scaled managed billing is not yet an option
turbopuffer.com · Usage-based across storage, writes, and queries, with a monthly minimum spend on every tier and larger minimums at higher tiers. Enterprise terms including BYOC are quoted by sales.
Best for Large corpora and many-tenant workloads where storage cost dominates and a slower first query after idle is acceptable.
A managed vector and full-text search database built on object storage, with memory and SSD caching layered in front of S3.
Strengths
Object-storage architecture decouples storage from compute, which keeps the cost of large, mostly-cold corpora low compared with keeping everything in RAM
Handles vector and full-text search in one system, so hybrid retrieval does not need a second index
Namespace model suits per-tenant isolation, which is awkward to do cheaply on engines that provision per-index capacity
Published operational ceilings are high: up to 128 billion documents per namespace and documented write and query throughput per namespace
Where it falls short
There is no free tier: every plan carries a monthly minimum spend, so small workloads pay the floor regardless of usage
Closed source, with no self-hosting on lower tiers; single-tenancy and BYOC appear only on the enterprise plan
Cold namespaces are read from object storage, so the first queries after an idle period are slower than warm ones by design
Recall is approximate and the vendor documents vector search recall@10 in a 90 to 100 percent range rather than as exact search
Documented per-namespace limits include a cap of four embedded attributes, which constrains how much metadata can ride in the hot path
pinecone.io · Free starter tier, then usage-based billing on storage, read units, and write units, with monthly minimum usage commitments on paid tiers and a flat monthly builder plan. Inference and assistant features bill separately; BYOC is quoted by sales.
weaviate.io · Free to self-host under BSD-3. Managed cloud has a free sandbox, then billing based on total stored vector dimensions plus object and backup storage, split into a pay-as-you-go tier and a prepaid contract tier.
Best for Teams that want hybrid semantic plus keyword search and built-in vectorization in one system, with the option to self-host.
A BSD-3 licensed vector database written in Go, with managed shared and dedicated cloud tiers alongside self-hosted deployment.
Strengths
Hybrid search combining vector similarity with BM25 keyword scoring and filtering is a core query type rather than something you assemble
Integrated vectorizer modules can embed data at import time, which removes a step from the ingestion pipeline
Permissive BSD 3-Clause licence on the open-source core
Production features including horizontal scaling, multi-tenancy, replication, and role-based access control are present in the open-source project
Vector compression and object TTL help control memory cost and stale data in long-lived collections
Where it falls short
Cloud billing is based on the total count of stored vector dimensions, so cost scales with embedding width as well as record count and shifts if you change embedding models
The free tier is one cluster per user with capped objects, memory, and disk, and carries only best-effort availability
Dedicated deployments and enterprise features are quoted by sales rather than published
Pricing varies by cloud provider and region, which makes cross-vendor comparison harder
Self-hosting means running and tuning a second stateful service alongside your primary database
elastic.co · Both are free to self-host, with Elasticsearch subject to its licence choice. Managed options bill either on provisioned cluster resources or on serverless usage, depending on the vendor and tier.
Best for Organisations already operating one of these clusters for logs or site search, where adding vector fields avoids introducing a new system entirely.
Two forked search engines that both added dense vector fields and approximate nearest-neighbour search to an existing full-text search platform.
Strengths
Hybrid retrieval is a natural fit: lexical BM25, dense vectors, sparse vectors, filters, geo, and facets combine in a single query API
Quantization options are mature, with int8, int4, and binary variants trading accuracy for large reductions in memory footprint
Both can be self-hosted, including fully air-gapped, and both have managed offerings from multiple cloud vendors
OpenSearch is Apache 2.0 and governed by the OpenSearch Software Foundation under the Linux Foundation, which is a neutral licensing position
Existing cluster operations, monitoring, and access control extend to the vector workload rather than being rebuilt
Where it falls short
Elasticsearch is not permissively licensed: its source is offered under AGPLv3, SSPL 1.0, or the Elastic License v2, any of which may be unacceptable depending on your legal position
Elasticsearch caps a dense_vector field at 4,096 dimensions
HNSW indexes are memory hungry unless quantization is enabled, and every quantization option trades recall for footprint by design
The two projects have diverged since the 2021 fork, so APIs, plugins, and vector features are not interchangeable between them
Running a cluster involves shard sizing, heap configuration, and rebalancing that a single Postgres instance does not require
Adopting one purely for RAG means operating a distributed search cluster to solve a problem an extension might have solved
milvus.io · Free to self-host under Apache 2.0. Managed Zilliz Cloud is priced separately, with serverless and dedicated cluster options.
Best for Very large deployments, in the billions of vectors, where a distributed Kubernetes-native design is worth its operational cost.
An Apache 2.0 licensed vector database under the LF AI and Data Foundation, with a distributed architecture that separates compute from storage.
Strengths
Highest stated scale ceiling of the open-source options here, designed for tens of billions of vectors with horizontal scaling
Apache 2.0 with neutral foundation governance rather than single-vendor control, which reduces relicensing risk
Deployment ladder covers Milvus Lite for a laptop, Standalone for one machine, and Distributed for a cluster, sharing one client API
Compute and storage separation lets you scale query capacity independently of corpus size
Managed Zilliz Cloud exists for teams that want the engine without running the cluster
Where it falls short
Even standalone mode pulls in etcd, MinIO object storage, and a message queue, so this is several services rather than one process
Documented hardware minimums are 8 GB RAM for standalone and 32 GB for a cluster, with dedicated NVMe SSDs recommended for etcd and a stated target of over 500 IOPS
Milvus Lite is positioned for notebooks, laptops, learning, and prototyping rather than production
The managed Zilliz Cloud service is a separate commercial product from the open-source project, so the managed and self-hosted paths are not the same vendor relationship
The operational surface is substantially larger than a Postgres extension or a single-binary engine, which is hard to justify below very large corpus sizes
trychroma.com · Free to self-host under Apache 2.0. Chroma Cloud is usage-based across writes, storage, queries, and data returned, with starter credits, a paid tier adding a monthly platform fee on top of usage, and enterprise terms quoted by sales.
Best for Prototyping and small to mid-sized RAG applications, where a few lines of Python beat provisioning any infrastructure at all.
An Apache 2.0 licensed search engine for AI applications, built on object storage, with an embedded local mode and a hosted cloud service.
Strengths
Lowest setup cost of anything here: it runs in-process from a pip install, which makes it well suited to notebooks and early development
Apache 2.0 licensed with a large install base, so examples and framework integrations are easy to find
Covers vector, full-text, regex, and metadata search in one API rather than only nearest-neighbour lookup
Chroma Cloud is generally available with serverless usage-based billing, so the prototype-to-hosted path does not require rewriting queries
Where it falls short
Published Chroma Cloud ceilings include 5 million records per collection and 1 million collections per database, which caps how far a single collection can grow
Vendor-published latency figures show cold p99 query latency around 1.5 seconds against roughly 20 ms warm p50, so idle collections pay a noticeable first-query penalty
The hosted service reached general availability more recently than most competitors here, so there is less public operating history at large scale
The paid support tier is billed as a monthly platform fee on top of usage, and enterprise terms including single-tenant clusters are quoted by sales
Embedded local mode is a different operating profile from the hosted service, so local behaviour is not a reliable guide to production performance