best 20 vector databases

the case for pgvector is not that it wins benchmarks. it is that it adds no new system to operate, costs nothing, and keeps your embeddings transactionally consistent with the business data they describe. no dedicated vector database can do that second thing at all.

the historical objection was filtered search. before version 0.8.0 a query with a selective WHERE clause could silently return fewer than k results — the index returned its candidates, the filter removed most of them, and you got quiet recall collapse. iterative index scans fixed exactly that in october 2024. every comparison written before then is testing a materially different product, and a lot of the folklore about pgvector dates from that era.

it supports ivfflat and hnsw, half-precision vectors and binary quantization, which matters more than it sounds: halving precision halves your footprint and binary quantization with rescoring cuts it by roughly thirty-two times. that moves your scaling wall further than switching vendors would.

the real limits are honest ones. index builds are slow and lock-heavy at scale, there is no native distributed sharding, and you own the tuning. recent releases have been correctness work — including fixes for a parallel build buffer overflow and an index-corruption risk during maintenance — which is what mature software looks like.

most vector databases apply metadata filters before or after the approximate search, and both are bad — pre-filtering breaks the index, post-filtering throws away results you already paid for. qdrant applies filters inside the hnsw traversal using a payload index. if your queries filter heavily, which most production rag does, this is the single most important design difference in the category.

quantization is the other strength: scalar for four times compression at roughly a percent of accuracy, binary for up to thirty-two times, product for up to sixty-four, and turboquant, which gets binary-level compression with noticeably better recall. that range gives you real control over the memory-versus-accuracy trade.

it is a single rust binary with sensible defaults and snapshot backups, which makes it the least painful thing here to run yourself at scale.

the complaint is commercial rather than technical. the free tier is small, and qdrant cloud bills hourly on compute, memory and storage without publishing the per-unit rates — you are routed to a calculator or to sales. for the most permissively licensed product in the category, that is an odd place to be opaque.

milvus supports more index types than anything else here: the ivf family, hnsw with several quantization variants, diskann for on-disk, gpu indexes including cagra, binary and sparse indexes. at very large scale that breadth is the point — you need diskann or gpu when memory-resident hnsw stops being affordable.

version 2.6 is the most consequential release in this category recently. hot and cold tiered storage with on-demand loading, one-bit rabitq quantization, int8 hnsw, support for over a hundred thousand collections for multi-tenancy, and — most importantly — a new internal write-ahead log that removes the kafka or pulsar dependency. that dependency was the main reason people avoided self-hosting it.

it is still the heaviest thing here to operate, with etcd, object storage and several node roles. milvus lite exists for local development.

one thing to keep in mind when reading comparisons: the most-cited public benchmark harness in this category is maintained by zilliz, the company behind milvus. that does not make the numbers wrong, but any leaderboard where milvus wins and milvus's vendor maintains the harness needs labelling as such.

the widespread belief that elasticsearch vector search requires a commercial licence is wrong, and it is worth stating plainly because it has steered a lot of teams away. the dense and sparse vector field mappers live in the main server tree, which carries the triple licence including agplv3. they are not in the elastic-licensed extension tree. the learned-sparse elser model is a separate matter and is restricted, but ordinary vector search is not.

on capability it is close to the top of the category for hybrid. real bm25, reciprocal rank fusion, mature filtering and aggregations — this is a full search engine rather than a vector store with keyword search bolted on. its better binary quantization work has been strong.

serverless pricing is unusually legible: separate ingest, search and machine-learning compute units billed hourly, storage per gigabyte retained, and fifty gigabytes free on vector profiles.

the costs are the usual elasticsearch ones — jvm heap tuning, operational weight, and a licence structure that is genuinely complicated even once you know vector search is available under agpl. if you already run it, adding vectors is close to free operationally.

tenants are a native primitive, implemented as isolated shards, with cold-tenant offloading. for a saas product where each customer's documents must not leak into another's results, that is the feature that decides it, and building the equivalent on postgres is genuinely unpleasant at five figures of tenants.

hybrid search is first-class — bm25 and dense fused with configurable strategies — and the documentation is among the best in the category.

the pricing model is unusual and worth understanding before you commit. weaviate bills per million vector dimensions, so cost scales with objects multiplied by dimensions. switching your embedding model from 768 to 1536 dimensions doubles your bill at exactly the same object count. no other vendor here works this way. it rewards small embeddings and matryoshka truncation, which is a reasonable engineering incentive but an easy budgeting surprise.

bsd-3 licensed, well funded, and historically memory-hungry — quantization options exist and you will want them.

chroma is the easiest thing here to start with by a wide margin, which is why it dominates tutorials and prototypes. that matters more than it sounds: most rag projects die from friction rather than from scaling limits.

the pricing is unusually honest — storage, writes, queries and returned data each priced per unit with no minimum base fee on the entry tier. after wrestling with vendors who route you to a sales form, that clarity is worth something.

the trade is depth. hnsw only, with a thin quantization and tuning surface compared with qdrant or milvus, and no diskann or gpu path. it is excellent to roughly a million vectors and credible to ten; independent evidence above that is absent.

one caveat worth knowing: the local-mode ergonomics that make chroma lovely are not the same code path as the distributed cloud product. validate on the deployment you intend to ship.

general availability arrived in december 2025 with two billion vectors per index, and it reached thirty-one regions by march 2026. storage is six cents per gigabyte per month, queries are priced per million with a tiered data-processing charge that falls as your index grows, and the first half-megabyte returned per query is free.

against premium managed vector databases charging around thirty-three cents a gigabyte, that is a structural change rather than a discount, and aws has been pointed about calling it complementary to dedicated vector databases rather than a replacement.

the catch is latency, and it should not be buried: this is sub-second, not single-digit milliseconds. for an interactive agent loop that is the wrong shape. for archival retrieval, compliance search or a long-tail knowledge base queried occasionally, it is close to unbeatable on cost.

one operational detail with real cost impact: writes carry a 128 kilobyte minimum per request. a six-kilobyte vector written individually bills as 128 kilobytes, a roughly twenty-one-fold markup. batch your writes or the economics invert. the index algorithm itself is undocumented.

object storage first with ssd and memory caching, and namespace-per-tenant as the native isolation model. for a product where every customer needs their own corpus, that primitive is well designed and cheap to run.

plan minimums are sixteen dollars a month for launch, two hundred and fifty-six for scale — which adds a business-associate agreement, single sign-on, audit logs and ip allowlisting — and upwards of four thousand for enterprise, which carries a thirty-five percent usage premium in exchange for single-tenant deployment and a 99.95% uptime commitment.

note that several comparison sites state a sixty-four dollar starting price. the vendor's own page says sixteen. it is a small thing and a useful demonstration of why we read primary sources.

the per-unit rates for storage, writes and queries live in a javascript calculator that does not render to a fetch, so we are not publishing figures for them. combined with no free tier and no self-host escape hatch, that opacity is the main reason it sits here rather than higher.

opensearch is apache-2.0 throughout, which in a category with this many licence traps is worth real money in avoided legal review. the k-nn plugin supports hnsw and ivf across both faiss and lucene engines, plus disk-based modes and binary and byte quantization.

the important 2026 change is on the serverless side. previously the smallest classic collection carried a two-unit minimum that cost hundreds of dollars a month even at zero traffic, which made 'serverless' something of a misnomer. nextgen collections have no minimum and scale to zero after ten minutes idle.

one architectural detail that surprises people: a vector search collection cannot share compute units with search or time-series collections. vector workloads get their own units and therefore their own floor.

the downsides are forked-project ergonomics — documentation and tooling lag elasticsearch in places — and compute-unit accounting that takes a while to reason about.

vespa came out of yahoo and it shows in the best way: multi-phase ranking with real ranking expressions and machine-learned models is native, not an add-on. hybrid is not bm25 stapled to a vector index, it is a genuine tensor and ranking framework.

the pricing is the most transparent here — published per-vcpu, per-gb-memory, per-gb-disk and per-gb-gpu-memory hourly rates across four plan tiers, with unit prices declining as allocation grows and a discount for annual commitment.

it is proven at very large scale and apache-2.0 licensed.

two things hold it back for most readers. the learning curve is genuinely steep — application packages, schemas, ranking profiles — and it is a real engineering investment rather than a weekend integration. and the enterprise tier carries a twenty-thousand-dollar monthly minimum, which puts the supported path out of reach for most teams.

pinecone did more than anyone to create this category and its managed experience is genuinely frictionless. namespaces work well for multi-tenancy, sparse-dense hybrid is native, and the free tier gives you two gigabytes.

the pricing is the problem. reads and writes are billed in units that are pinecone's own abstraction rather than a physical quantity, and a read unit's cost depends on how much data the query touches. that means you cannot model your bill from vector count and query rate alone — you have to instrument and observe. of everything in this ranking it is the hardest to compare on price, which for a managed product is an odd weakness.

you also cannot tune the index. hnsw parameters are not exposed, so trading latency against recall yourself is not an option, and there is no self-hosted escape hatch if the economics stop working.

one thing a buyer signing a multi-year commitment should know: the founder moved from chief executive to chief scientist in september 2025, and reporting that august said the company had held early discussions with bankers about strategic options. the current chief executive has publicly said a sale is not on the table. we mention it because vendor direction is a legitimate input to a long-term dependency, not because we think anything is wrong.

everything true of pgvector is true here, plus authentication, object storage and edge functions in the same product. for a small team that consolidation removes several vendors and a lot of glue code, which is worth real money.

the trap is memory. the free tier gives five hundred megabytes of ram, and by the arithmetic in the introduction even a hundred thousand 1536-dimension vectors is around six hundred megabytes raw before index overhead. anything resembling production rag needs a paid compute add-on, and those add-ons — priced per instance per month and rising steeply with memory — are where the real cost sits rather than in the twenty-five dollar plan fee.

the pro plan includes a small amount of compute credit, which covers the smallest instance only.

if you are already building on supabase, adding vectors is close to free in effort terms. if you are choosing a vector store on its merits, you are really choosing pgvector, and where you run it is a separate question.

lancedb is built on the lance columnar format over object storage, which makes it closer to duckdb or sqlite in shape than to a server-based vector database. embedded mode needs no process to run, and zero-copy versioning of the underlying data is a genuinely useful property for ai datasets that change.

the positioning is a multimodal lakehouse rather than a vector store — if your vectors sit alongside images, audio and structured columns that you also want to query, this fits better than anything else here.

apache-2.0, disk-first, with ivf-pq and hnsw variants over the lance format.

two reasons it sits at thirteen rather than higher. the flagship repository is still cutting beta-tagged releases, which for a data store is a meaningful signal. and cloud pricing is entirely sales-gated — there is no published figure to compare against anything else on this page.

if your documents already live in atlas, keeping their embeddings in the same place removes a synchronisation problem that causes real bugs elsewhere. filtering through the aggregation pipeline is expressive, and hnsw with scalar and binary quantization is supported.

the cost surprise is the thing to lead with. vector search is not part of your cluster price — it requires dedicated search nodes billed at their own hourly rates, starting around twelve cents an hour for the smallest and rising steeply. teams price a modest cluster at well under a hundred dollars a month and discover vector search roughly triples it. this is the most commonly under-budgeted line item in the whole category.

the licence is sspl, which is not osi-approved and which some organisations' legal reviews reject outright.

vector search is also atlas-only — it is not available in the self-hosted community edition, so there is no self-host path.

it runs wherever sqlite runs, which is everywhere: mobile, edge functions, desktop applications, and the browser via webassembly. for local-first products that cannot call a server, there is no real alternative.

zero operations, zero cost, apache-2.0.

the design constraint is that it is brute-force only — there is no approximate index. that is fine to somewhere around a hundred thousand to a million vectors, where a linear scan is fast enough, and it degrades linearly after. know which side of that line you are on.

it has been pre-1.0 for a long time and is still cutting alpha-tagged releases. for a local cache that is acceptable; for a production multi-tenant service behind an api it is not what you want, and it is not what it is for.

the capability is solid — good hybrid search, a semantic ranker, and deep integration with the rest of the azure ai stack, where it now underpins microsoft's managed knowledge layer for agents.

the thing that belongs at the top of any review is the quota structure. vector index size is capped per partition at roughly thirty percent of total index storage — five gigabytes on basic, thirty-five on the first standard tier — and microsoft's documentation is explicit that this is a hard limit and that further indexing attempts once exceeded result in failure. teams size the service on total storage and hit a wall at a third of it. there are also caps of 4,096 dimensions per field and ten vector fields per query.

a serverless tier arrived in preview during 2026, but its limits are severe — a few hundred megabytes of vector index per index, no service-level agreement, no migration path to or from other tiers, and a handful of regions. treat it as evaluation only.

we could not verify usd rates: the global pricing page did not render reliably and we are not converting figures from a regional page into dollars.

if your vectors fit in ram and you already run redis, this is the fastest option in the category and the marginal cost is close to zero. hnsw and flat indexes are supported through the search module.

in-memory is also the constraint that decides everything. by the arithmetic in the introduction, a hundred million 1536-dimension vectors is roughly six hundred gigabytes — of ram. that makes redis the most expensive place per vector at scale by a wide margin, and the free tier's thirty megabytes is a toy rather than an evaluation.

the licence needs care. from redis 8 the project is tri-licensed and includes agplv3, which is a genuine open-source option. but the search module that actually provides vector search only gained that option from redis 8 — earlier versions are source-available only, under terms that forbid offering it as a managed service. if you are pinned to an older version, check what you are actually running.

for a hot cache of recent embeddings in front of something cheaper, it is a good component. as your primary vector store it rarely makes economic sense.

clickhouse added hnsw-based vector similarity indexes that became genuinely usable during 2025, but the more interesting property is its scan speed. with a selective filter reducing the candidate set, an exact brute-force scan in clickhouse can beat an approximate index elsewhere — and you get perfect recall rather than an approximation.

that makes it a strong fit for a specific shape of problem: semantic search over data you are also aggregating and filtering heavily, like logs, events or clickstream with embeddings attached.

apache-2.0, enormously mature as a database, and something a lot of teams already run for analytics.

for straightforward low-latency rag over a document corpus it is the wrong tool, and we did not verify clickhouse cloud pricing.

this is the productised descendant of google's scann work, and the retrieval quality reflects that. it scales enormously and is native to gcp.

the structural weakness holds regardless of what the rates turn out to be: billing is per node-hour and always-on, with no scale to zero. a low-traffic index costs the same as a busy one. that makes it poor value for anything intermittent and reasonable only at sustained high query rates — the opposite of the direction the rest of the category moved in during 2026.

we could not verify pricing. google's vertex pricing pages were reorganised during the review period and the documentation urls we followed either truncated or returned errors. figures circulating on aggregator sites exist but we are not repeating them as google's rates.

index rebuilds are also slow, which matters if your corpus changes frequently.

vald is a distributed, kubernetes-native vector search engine built on the ngt library, and the architecture is legitimately interesting if you already live in kubernetes.

it has not produced a tagged release in more than twelve months. commits continue, but they are consistent with automated dependency updates rather than feature work, and the two releases before that were also many months apart.

this is why we check release history rather than commit activity. a repository can look alive in a graph and be effectively frozen, and star counts tell you nothing at all about it.

it is apache-2.0 and it still works. we are not recommending it for anything new, and it is here so that a reader comparing options can rule it out on evidence rather than wonder.