Originally published at heycc.cn. This is a mirrored copy — the canonical version is kept up to date at the source.

Vector Database Comparison 2026: pgvector, Pinecone, Qdrant, Weaviate, and Chroma

Here is the uncomfortable truth for anyone building retrieval-augmented generation (RAG) in 2026: the vector database is almost never the hard part. Embedding quality, chunking, metadata hygiene, and reranking move your answer accuracy far more than which store you pick. By the time you are choosing a vector database, you have mostly already decided how good your retrieval will be.

So treat this as a decision, not a feature beauty contest. The figures here reflect each vendor's published state as of 2026-06-28. For a large share of teams, the right answer is the unglamorous one: use the Postgres you already run. What follows defines what you are actually choosing between, lays out a comparison table and decision tree, walks one worked example against pgvector, and then goes tool by tool so you know where each one genuinely wins.

What you are actually choosing between

Strip away the marketing and three capabilities matter for almost every RAG workload:

• Dense ANN index. Embeddings are high-dimensional vectors, and exact nearest-neighbor search does not scale. So every system uses an approximate nearest neighbor (ANN) index. In 2026, almost everyone has converged on HNSW (Hierarchical Navigable Small World), a multilayer graph that trades a little recall for a lot of query speed. The relevant trade-off is captured by ANN-Benchmarks, which plots recall against queries-per-second — on the standard glove-100-angular set, a well-tuned HNSW implementation reaches roughly 0.99 recall at thousands of queries per second on a single core, while pushing recall from 0.99 to 0.999 can cost an order of magnitude in throughput. That curve, not a vendor's headline number, is the shape you are buying into.
• Metadata / payload filtering. Real queries are rarely "find similar text." They are "find similar text where tenant = X, status = published, and date > 2026-01-01." How a database combines a WHERE-style filter with the ANN search — without quietly destroying recall — is where products differ most.
• Hybrid search. Pure vector search misses exact keywords, product codes, and rare terms. Hybrid search fuses a dense (semantic) signal with a sparse/lexical signal (BM25 or sparse vectors), usually followed by reranking. If your corpus has jargon, IDs, or acronyms, you want this.

With those three columns defined, the table makes sense.

The 2026 comparison table

Database	Managed / Self-host	ANN index	Hybrid search?	Best for
pgvector	Self-host, or any managed Postgres (Supabase, Neon, RDS)	HNSW + IVFFlat	Yes — vector + Postgres full-text / sparsevec	You already run Postgres and vectors are one feature, not the product
Pinecone	Fully managed only (no self-host)	Proprietary (serverless)	Yes — dense + BM25/sparse, with reranking	Zero-ops, pay-per-use, vector search is core
Qdrant	Self-host (open source) or Qdrant Cloud	HNSW (filterable)	Yes — sparse vectors + hybrid queries	Heavy filtering, want open-source control plus a managed option
Weaviate	Self-host (Docker) or Weaviate Cloud	HNSW / flat / dynamic	Yes — native vector + BM25F fusion	Built-in hybrid and schema-driven collections
Chroma	Embedded / self-host / Chroma Cloud	HNSW-based	Yes — dense, sparse, hybrid + full-text/regex	Local prototyping that can graduate to managed

Now the detail, because "best for" hides a lot.

pgvector — the default

pgvector is an open-source Postgres extension (latest release 0.8.5, released 2026-07-08). You install it into a database you already operate, or into any managed Postgres — Supabase, Neon, Amazon RDS, and most others ship it. It supports two ANN index types: HNSW (better query performance) and IVFFlat (faster to build, lower memory, lower recall).

Its superpower is not the index — it is that your vectors live next to your real data. Metadata filtering is just a SQL WHERE clause, and you can join transactionally against your users, documents, and permissions tables in the same query. No separate sync pipeline, no two sources of truth. For hybrid search, pgvector adds a sparsevec type and combines cleanly with PostgreSQL's built-in full-text search. One precision note that matters for hybrid design: a sparsevec column can store up to 16,000 non-zero elements, but an HNSW index over sparsevec is limited to 1,000 non-zero elements — so if you are indexing sparse lexical vectors for fast hybrid retrieval, plan around the 1,000 figure, not the 16,000 storage ceiling.

A worked example: the filtered-recall cliff, measured

The classic objection to pgvector was filtered recall: an HNSW graph walk finds candidates, then your WHERE clause deletes most of them, leaving too few results. A small local reproduction makes the failure mode concrete rather than theoretical — Postgres 16, pgvector 0.8.3, ~500k OpenAI text-embedding-3-small vectors at 1536 dims, the HNSW index built with defaults and queried with hnsw.ef_search = 100:

-- Tenant filter that removes ~97% of rows before ranking
SET hnsw.ef_search = 100;
SELECT id FROM docs
WHERE tenant_id = 42            -- highly selective filter
ORDER BY embedding <=> :query_vec
LIMIT 10;

With the default (pre-0.8.0) behavior, this query frequently returned fewer than 10 rows even though hundreds of matching documents existed for that tenant: the graph walk visited 100 candidates, almost all belonged to other tenants, and the filter discarded them. The recall against a brute-force baseline on the same query set sat well below acceptable — the "cliff" is real, and it is worst exactly when your filter is most selective.

pgvector 0.8.0 fixed this with iterative index scans (strict or relaxed ordering), which keep scanning the index until enough rows survive the filter. Turning them on closed the gap:

SET hnsw.iterative_scan = strict_order;   -- or relaxed_order for more speed
SET hnsw.max_scan_tuples = 20000;         -- ceiling so a bad filter can't run away

After enabling strict_order, the same selective-tenant query reliably returned a full top-10 that matched the brute-force ranking, at the cost of more tuples scanned per query. The lesson: on 0.8.x you can keep pgvector for filtered workloads, but you must turn iterative scans on and cap max_scan_tuples — leaving the defaults is how teams conclude "pgvector can't filter" when really they never enabled the fix.

AWS ran this at scale on Aurora PostgreSQL — 10M products, 384-dim vectors — and published the p99 numbers: a category-filtered query went from 128.5ms (0.7.4 baseline) to 85.7ms with relaxed_order (1.5x), and a more selective multi-filter query went from 127.4ms to 70.7ms (1.8x). The recall story is the bigger deal: completeness on those same two queries rose from 10% and 1% respectively, to 100%. That's the "0.8.0 fixed this" claim above, at a dataset size in the range this article's 10M-vector rule of thumb is actually talking about.

Why "~10M vectors" is the rough inflection point

The single most actionable rule of thumb in this piece — pgvector is the default under roughly 10M vectors — deserves its reasoning rather than a bare number. It is a heuristic, not a hard limit, and it falls out of memory and index-build economics, not a benchmark verdict:

• HNSW wants to sit in RAM. A 1536-dim float vector is ~6 KB, plus graph-edge overhead. At ~10M vectors you are in the low tens of gigabytes for the index — still comfortable on a single large Postgres instance you already pay for. Past that, you start provisioning RAM specifically for the vector index, which is the moment a purpose-built store's horizontal sharding begins to earn its operational cost.
• Build time and maintenance_work_mem. HNSW index builds are CPU- and memory-bound; beyond tens of millions of rows, rebuilds and maintenance_work_mem tuning stop being a footnote and become a planning concern.
• The trade you are weighing is "one database to operate" against "the last few percent of QPS." Below ~10M that trade overwhelmingly favors one database; above it, the dedicated systems' sharding and tiered storage start paying for their own complexity.

Treat 10M as the order of magnitude where you should re-evaluate, not a wall you hit. Plenty of teams run pgvector comfortably past it with good hardware; the point is that's where the question stops being obvious.

Where pgvector wins: under roughly 10M vectors, when vector search is a feature inside a larger product, and when "one database to operate" is worth more than squeezing out the last few percent of QPS. For most internal knowledge bases and SaaS features, this is the correct default.

Pinecone — managed serverless, zero ops

Pinecone is the opposite philosophy: fully managed, no self-hosting, ever. Its serverless index holds your data as JSON documents and auto-indexes metadata fields — you do not declare a schema up front. Filtering supports the operators you expect ($eq, $ne, $gt, $in, $and, $or), and hybrid search combines a lexical signal (BM25 / sparse, including a hosted pinecone-sparse-english-v0 model) with the dense signal, typically with reranking.

Pricing is serverless and usage-based rather than per-node. As of 2026-06-28 there is a free Starter tier, a Builder tier (a low flat monthly fee — currently $20/month — for small teams), a Standard tier, and an Enterprise tier with higher minimums and a 99.95% uptime SLA. Paid usage is billed on storage consumed (around $0.33/GB-month), plus read units and write units — you pay for what you store and the operations you run.

Where Pinecone wins: you want zero operational burden, you are comfortable with a closed managed service, vector search is core to the product, and pay-per-use beats provisioning. The trade-off is vendor lock-in and less control over index internals.

Qdrant — filtering-first, open source plus cloud

Qdrant uses HNSW for dense vectors and is both open source (self-host) and available as managed Qdrant Cloud. Its distinguishing strength is filtering. Payload (metadata) types cover keyword, integer, float, bool, geo, datetime, text, and uuid, and Qdrant builds a Filterable HNSW Index that adds extra graph edges based on indexed payload values — so heavily filtered searches stay fast instead of collapsing into a slow brute-force scan. This is the same filtered-recall problem pgvector solves with iterative scans, attacked from the index-structure side instead. It also supports sparse vectors and hybrid queries.

On cost, the core engine is free to self-host. Qdrant Cloud offers a "free forever" single-node tier, a usage-based Standard tier (99.5% SLA), and a Premium tier (SSO, private VPC, 99.9% SLA), billed on actual resource consumption.

Where Qdrant wins: workloads with aggressive metadata filtering (multi-tenant apps, faceted search), teams that want open-source control but also a managed escape hatch, and anyone who has been burned by filtered-recall cliffs elsewhere.

Weaviate — schema-driven with native hybrid

Weaviate is open-source/self-hostable via Docker and also offered as managed Weaviate Cloud. It is more opinionated about structure: you define collections, and it gives you a choice of vector index. HNSW is the default; a flat index suits small collections and multi-tenancy; and a dynamic index starts flat and auto-transitions to HNSW once a collection passes roughly 10,000 objects — so you do not have to guess up front.

Hybrid search is native and mature. Weaviate fuses a vector search with a BM25F keyword search, and the fusion method (relative-score versus ranked) plus the alpha weighting between the dense and sparse signals are both configurable per query. In practice this is the most "batteries-included" hybrid story of the five: you do not assemble it from parts, you set two parameters and tune. The cost is the schema discipline — you commit to collections and properties up front, which is a feature if your data model is stable and friction if it is still moving.

Where Weaviate wins: teams that want hybrid search and reranking working out of the box, that are comfortable defining a schema, and that value a single configurable query API over wiring dense and sparse retrieval together themselves.

Chroma — the local-first prototype

Chroma optimizes for the start of the journey. It runs embedded in your Python or JavaScript process for a prototype, as a self-hosted server when you outgrow that, and as Chroma Cloud when you want someone else to operate it — with the same client API across all three, so graduating does not mean a rewrite. Its index is HNSW-based, and it supports dense, sparse, and hybrid retrieval alongside full-text and even regex matching, which is genuinely useful when you are still exploring what your queries should look like.

No spin on this one: Chroma's edge is developer experience at small scale, not raw throughput at large scale. If your goal this week is "get a working RAG loop on my machine in twenty minutes," Chroma is hard to beat. If your goal is "serve 50M vectors under a latency SLA," you are choosing it for the wrong reason.

Where Chroma wins: local prototyping, notebooks, and small apps where iteration speed matters more than scale, with a clean path to a managed tier when the prototype earns a production budget.

Matching a database to your situation

If you remember one thing, make it this: the binding constraint in your stack picks the database, not a leaderboard ranking.

• You already run Postgres and have under ~10M vectors → pgvector. Turn on iterative scans, cap max_scan_tuples, and move on. This covers most internal knowledge bases and SaaS features.
• You want zero operations and vector search is the product → Pinecone. Pay-per-use, no nodes to babysit, accept the lock-in.
• Filtering is aggressive and multi-tenant → Qdrant. The filterable HNSW index is built for exactly this, and you keep an open-source escape hatch.
• You want native, configurable hybrid out of the box → Weaviate, if you are comfortable committing to a schema.
• You are prototyping locally → Chroma, with a clear graduation path.

Notice that benchmarks settle almost none of these. The ANN-Benchmarks recall-vs-QPS curve tells you the shape of the speed/accuracy trade, but the decision is dominated by operational fit: how many databases you want to run, whether your filter is selective, and whether vector search is your product or a feature inside it. Pick for that, and the throughput numbers will be good enough. If you are still deciding whether you need a vector database at all, start with RAG vs long context in 2026 and run your own numbers through the RAG vs Long Context Cost Calculator; for one running in production, see how an AI support bot grounds its answers with retrieval.

Where the comparison numbers come from

Each vendor fact traces to that vendor's own pages. pgvector's 0.8.3 release, the 0.8.0 iterative-scan feature, and the split between the sparsevec 16,000-element storage limit and the 1,000-element HNSW-index limit are from the pgvector GitHub README, CHANGELOG, and filtering docs. Pinecone's tier names, the ~$0.33/GB-month storage figure, and the Enterprise 99.95% uptime SLA are from pinecone.io/pricing. Qdrant's free-forever, Standard (99.5% SLA) and Premium (99.9% SLA) tiers plus the payload types and Filterable HNSW index are from qdrant.tech. Weaviate's index types and BM25F fusion are from the Weaviate docs, and the recall-vs-QPS curve is ANN-Benchmarks' published glove-100-angular result. The pgvector walkthrough — the filtered-recall failure and the iterative-scan fix — is one local run on ~500k vectors; read it for the behavior, since the latency and recall you see will track your hardware, dimensions, and ef_search. Pricing and SLA tiers are the most volatile entries; the linked pricing pages are authoritative if a figure has since moved.

Sources

• pgvector — GitHub repository, README, and CHANGELOG
• pgvector iterative index scans (filtering documentation)
• Pinecone pricing (tiers, storage, SLA)
• Pinecone indexing and metadata filtering docs
• Qdrant indexing and filterable HNSW docs
• Qdrant Cloud pricing and SLAs
• Weaviate vector index and hybrid search docs
• Chroma documentation
• ANN-Benchmarks (recall vs queries-per-second)
• AWS — Supercharging vector search performance and relevance with pgvector 0.8.0 on Amazon Aurora PostgreSQL