Vector Databases in 2026: pgvector vs Qdrant vs Pinecone vs Weaviate

What you need to know

Two years ago, every retrieval-augmented-generation tutorial named a different vector store, and choosing one felt like a bet on which start-up would survive. That anxiety is largely over. By 2026 the market has consolidated to four production defaults — pgvector, Qdrant, Pinecone and Weaviate — with Milvus and its managed sibling Zilliz waiting for the billion-scale workloads the other four are not built for. The hard part is no longer finding a credible option. It is resisting the urge to over-buy: to reach for a distributed, purpose-built vector engine when a single Postgres extension would have served you for years.

This guide is written for the builder shipping a real product in India or the UK, not for a benchmark leaderboard. The short version is that the decision is far less exotic than the marketing implies, and that most teams should start in the least glamorous place. Here is the shape of the argument before we go deep:

• Default to pgvector. If you already run Postgres and hold fewer than roughly 10 million vectors, pgvector is not a stepping stone — it is the right answer, and it keeps your data in one system with ordinary SQL filtering.
• Graduate at a named threshold. pgvector's practical ceiling is about 10 million vectors. Plan the move to a dedicated store as you approach it, not after your latency has already slipped.
• The database rarely owns your latency. The vector query is 5 to 8 milliseconds; your ~300ms end-to-end RAG latency is dominated by embedding generation, not the store. Optimising the wrong layer is the most common mistake.
• Hybrid search and filtering are the real differentiators. Native dense-plus-BM25 in a single query, and fast in-graph metadata filtering, are where Qdrant and Weaviate genuinely separate from the pack.
• Residency is a design decision. Supabase (managed pgvector) offers Mumbai and London; self-hosted stores run wherever you provision them. Decide where India's DPDP and UK GDPR data must live before you load a single embedding.

The 2026 landscape: four defaults, and when Milvus and Zilliz enter

Each of the four defaults earned its place for a different reason, and knowing the reason tells you when to pick it.

pgvector is the Postgres extension that turned every existing relational database into a competent vector store. Its appeal is architectural rather than performance-led: you keep vectors, metadata and business data in one transactional system, you filter with SQL you already know, and you inherit Postgres backups, replication and row-level security for free. Qdrant is the open-source latency leader, written in Rust, and the store to beat when you need fast filtered search and native hybrid retrieval without paying a managed premium. Pinecone is the fully managed pioneer — you never run a server, you never tune an index, and you pay a usage-metered bill for that convenience. Weaviate built its reputation on native hybrid search, combining dense vectors and BM25 keyword scoring in one query, and offers both self-hosted and cloud paths.

So when do Milvus and Zilliz enter the conversation? Only at the top of the scale curve. Milvus is a distributed, horizontally sharded system designed for hundreds of millions to billions of vectors, with GPU-accelerated indexing and the operational weight to match. If your corpus is measured in millions, Milvus is more machinery than you need and its self-hosted operations will cost you more in engineering time than you save. If your corpus is measured in billions — a web-scale index, a multi-tenant platform aggregating every customer's documents — it, and the managed Zilliz Cloud, become the sensible default precisely because the other four start to strain. Treat billion-scale as the entry ticket, not a nice-to-have.

The honest default: why pgvector is enough for most builds

Here is the claim that saves most teams the most money: for the overwhelming majority of production RAG systems, pgvector is not merely adequate, it is the correct engineering choice. The evidence is unglamorous and convincing. With an HNSW index, pgvector returns the vector portion of a query in roughly 5 to 8 milliseconds. At around 1 million vectors, Supabase's own benchmarks show pgvector's HNSW implementation matching or beating Qdrant at 99 per cent recall. In other words, at the scale where most applications actually live, the dedicated store gives you no measurable retrieval advantage while costing you a second system to run, secure and keep consistent.

The architectural wins compound. Your embeddings sit in the same database as your users, your documents and your permissions, so a retrieval query can join against live business data and enforce per-tenant isolation with row-level security in the same statement. There is no synchronisation job keeping a separate vector index in step with your source of truth, and no second failure domain to page you at 3am. If you are already assembling a production RAG pipeline with hybrid retrieval and have thought about your chunking and embedding strategy, adding pgvector is a migration and an index, not a new platform.

The honesty in "honest default" is about the ceiling, which is real. pgvector's practical limit is around 10 million vectors. An HNSW index over 10 million 1536-dimension embeddings occupies roughly 80 to 120 GB, of which the raw vector column alone is about 60 GB. Performance holds up well while that index lives in RAM; it degrades noticeably beyond about 10 to 20 million vectors once the working set spills past memory and the machine starts touching disk on every search. This is not a soft, gradual slope you can ignore — it is the point at which a dedicated store earns its keep. The skill is to see it coming.

The comparison table

The table below is the one-screen summary. It maps each of the five stores against the six attributes that actually drive the decision: how you deploy it, whether it does native hybrid with BM25, how it filters, its practical scale ceiling, its pricing model, and the operational burden you take on. Read it as a shortlisting tool — narrow to two candidates here, then use the sections that follow to break the tie.

Two patterns fall straight out of the table. First, deployment shape is the biggest fork: Pinecone is managed-only, pgvector and Qdrant are the easiest to self-host cheaply, and Milvus is the one that punishes casual self-hosting hardest. Second, native hybrid is not universal — Qdrant, Weaviate and Milvus have it; pgvector needs an add-on; and if hybrid is core to your product that alone can decide the shortlist.

Filtering and hybrid search: the features that actually separate them

Once you are past the "does it store vectors and do nearest-neighbour search" baseline — which all five do well — the genuine differentiators are how a store filters by metadata and whether it fuses keyword and vector search natively. These are the features that decide real product behaviour, so they deserve more than a table cell.

Metadata filtering

Almost every production query is filtered: this tenant's documents, this date range, this language, this access level. The naive approach — retrieve the nearest vectors, then discard the ones that fail the filter — falls apart when the filter is selective, because you may have to over-fetch enormously to end up with enough matching results. Qdrant's advantage here is architectural: it applies filters inside the graph traversal rather than after it, and that in-graph filtering runs roughly 2 to 3 times faster than post-search filtering, keeping filtered and metadata-heavy queries in the region of 20 to 30 milliseconds. pgvector takes the opposite, equally valid route: because your metadata lives in ordinary columns, you express filters as a normal SQL WHERE clause, and the planner decides how to combine them with the vector index. For multi-tenant apps, that means you can enforce isolation with row-level security rather than trusting application code to add the right filter every time. Concretely, the whole pattern — extension, HNSW index, then a tenant-filtered nearest-neighbour query — is a handful of SQL statements:

-- Enable pgvector and store 1536-dim embeddings (e.g. text-embedding-3-small)
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
    id         bigserial PRIMARY KEY,
    tenant_id  uuid NOT NULL,
    body       text,
    embedding  vector(1536)
);

-- HNSW index for cosine distance; tune m / ef_construction for recall vs build time
CREATE INDEX ON documents
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Query: raise ef_search for higher recall, filter by tenant, order by cosine distance
SET hnsw.ef_search = 100;

SELECT id, body
FROM   documents
WHERE  tenant_id = '3f1c9e2a-...'                          -- metadata filter / row-level isolation
ORDER  BY embedding <=> '[0.012, -0.031, ...]'::vector    -- <=> is cosine distance
LIMIT  10;

Hybrid search: dense vectors plus BM25

Pure vector search is weak at exact terms — product codes, error strings, names, acronyms — where old-fashioned keyword matching shines. Hybrid search fuses the two, and it is where Weaviate and Qdrant genuinely lead: both offer native hybrid that combines dense vectors, BM25 keyword scoring and metadata filters in a single query, with Weaviate reporting around 8,000 QPS for combined dense-and-BM25 workloads. With pgvector there is no native BM25; you either bolt on pg_search/ParadeDB, or you write the fusion yourself by combining a vector-distance query with a Postgres tsvector full-text query and blending the scores. That is entirely workable — many production systems do exactly this — but it is code you own and maintain rather than a feature you switch on. If hybrid retrieval is central to your product, factor that engineering cost in. Whichever store you use, hybrid is only the first stage; adding a reranking stage with cross-encoders on top of the fused candidates usually does more for answer quality than switching databases, and pairing it with solid hybrid retrieval and agent observability is what lets you prove the improvement.

Performance versus reality: embeddings, not the database, own your latency

Vector-database benchmarks are seductive and mostly beside the point for the application builder, because they measure the layer that is rarely your bottleneck. Consider a typical end-to-end RAG request that takes about 300 milliseconds. Of that, the vector lookup in pgvector is roughly 5 to 8 milliseconds, while generating the query embedding is on the order of 90 milliseconds — more than ten times the database's contribution — and the rest is spent in the language model producing the answer. If you shave 3 milliseconds off retrieval by switching to a faster store, you have improved total latency by one per cent while doubling your operational surface area. That is a bad trade, and it is the trade an over-focus on database benchmarks pushes you towards.

None of which means the benchmarks are meaningless — they matter enormously at the top of the scale curve, which is exactly why the vendors publish them. Independent comparisons such as the write-ups at vecstore.app and Kalvium Labs are worth reading once you are genuinely operating at tens of millions of vectors, where the differences stop being noise. The pattern they report is consistent: Qdrant leads the open-source field on latency, with p99 around 12 milliseconds at 10 million vectors, ahead of Weaviate (around 16ms) and Milvus (around 18ms). At 100 million vectors Qdrant holds roughly 30 to 40 milliseconds, against Pinecone at 50 to 100, Weaviate at 50 to 70 and Milvus at 40 to 60 — generally putting Qdrant some 10 to 25 per cent ahead of Weaviate and Milvus. Filtered and metadata queries land around 20 to 30 milliseconds, with the in-graph filtering advantage noted earlier.

The builder's takeaway is a matter of priority. Below roughly 10 million vectors, the database is not your latency problem, so optimise the embedding pipeline instead — cache embeddings for repeated queries, batch where you can, and consider a smaller or faster embedding model before you consider a faster store. The economics of running your own inference, covered in our guide to self-hosted LLM serving cost, quantization and batching, will move your numbers far more than a database swap. Above 10 million vectors, the store's latency profile becomes a legitimate selection criterion — and that is precisely the point at which Qdrant's numbers start to earn their place on your shortlist.

Total cost of ownership at 1M / 10M / 100M

Pricing is where the four defaults diverge most sharply, and where the self-host-versus-managed choice is really made. Pricing as of July 2026 breaks down like this. Pinecone serverless charges roughly $0.33 per GB-month for storage, around $2 to $4.50 per million write-units and $8.25 to $18 per million read-units, on plan minimums ranging from $0 to $500 per month. Weaviate Cloud moved in October 2025 to a vector-dimensions-stored pricing model at roughly $0.095 per GB of storage, with tiers up to $400 per month. Qdrant Cloud charges about $0.28 per GB for storage and offers a genuinely useful free 0.5 vCPU / 1GB tier for prototyping. pgvector, of course, has no separate vector fee at all — it rides on whatever you already pay for Postgres.

The table below turns those models into all-in monthly estimates at three scales, with rough conversions to rupees and pounds for the AITC audience (at approximately ₹85 and £0.79 to the US dollar). Treat the figures as directional planning numbers, not quotes.

The story the table tells is that the pricing gap is small at 10 million vectors and enormous at 100 million. At 10 million the four managed paths sit within a modest band — pgvector-on-RDS around $45, Qdrant around $65, Pinecone around $70, Weaviate around $135 — so cost is a tie-breaker, not a decider, and convenience can reasonably win. At 100 million the gap becomes decisive: managed Pinecone runs $700 or more per month, while self-hosted Milvus or pgvector on your own hardware can stay under $100, and a self-hosted Qdrant instance handles millions of vectors on a small VPS for as little as $30 to $50 per month. The crossover is operational, not merely financial — you trade a larger bill for someone else running your upgrades, backups and monitoring. Detailed pricing walk-throughs at RankSquire and LeanOps Tech are worth checking against your exact read/write mix before you commit, because usage-metered plans reward and punish different traffic shapes very differently.

India and the UK: regions, residency and self-host versus managed

For a team serving Indian or British users, where the vectors physically live is not a footnote — it is a compliance requirement that should shape the shortlist from the start. The good news is that every path on the table can be made to satisfy residency; the difference is how much control you get and how much operational work you take on to get it.

On the managed side, Supabase runs pgvector in a Mumbai region (ap-south-1) and a London region, which between them cover the residency expectations of India's Digital Personal Data Protection (DPDP) framework and UK GDPR for most teams — you pick the region when you create the project and your embeddings, metadata and business data stay in-country together. Pinecone Enterprise supports EU data residency (eu-west-1) and holds SOC 2 Type II, which suits UK and European deployments and satisfies procurement teams that ask for an attested control environment; confirm current Indian-region availability directly with Pinecone if in-India residency is a hard requirement for you. The self-hosted stores — Qdrant, Weaviate and Milvus — sidestep the question by construction: they run in whatever region you provision, whether that is a Mumbai or a London data centre from any cloud or a machine in your own rack, so you can pin data to a specific country outright and prove it. That control is the strongest argument for self-hosting when residency is non-negotiable and your legal team wants certainty rather than a vendor's regional roadmap.

The practical framing for the dual market is this. If you are a smaller team optimising for speed and want residency without running infrastructure, managed pgvector on Supabase Mumbai or London is the lowest-friction answer and keeps everything in one billing line. If residency requirements are strict, contractual, or span both India and the UK with data that must not leave either country, self-hosting Qdrant gives you regional certainty at a cost measured in tens of pounds or a few thousand rupees a month plus your own operational attention. Either way, decide before you load personal data — retrofitting residency onto a store that already holds production embeddings is a migration, and migrations under a compliance deadline are the ones that go wrong.

The decision tree: pick your database in six questions

Everything above collapses into a short sequence of questions. Answer them in order and stop at the first one that fires — the earlier questions are the common cases, and the discipline is to resist skipping ahead to a more exciting answer than your situation warrants.

• 1. Do you already run Postgres and hold under ~10 million vectors? Use pgvector. You are done. It matches dedicated stores at this scale, keeps everything in one system, and costs no extra infrastructure. This covers most builds — do not talk yourself out of it.
• 2. Do you need native hybrid — dense plus BM25 in one query — and confirmed it lifts your results? Choose Qdrant or Weaviate. Both do native hybrid out of the box, sparing you the custom BM25 plumbing pgvector would require.
• 3. Do you want zero infrastructure to run, and will you pay a metered bill for it? Choose Pinecone. It is managed-only, needs no index tuning, and is the right answer when engineering time is scarcer than money — accepting that there is no self-host escape hatch later.
• 4. Are you past ~100 million vectors, heading for billion-scale? Choose Milvus, or managed Zilliz Cloud. This is where distributed sharding and GPU indexing stop being overkill and start being necessary; below this scale they are a tax.
• 5. Is strict in-country residency non-negotiable and you want provable control? Self-host Qdrant, Weaviate or Milvus in your chosen region, or use Supabase Mumbai/London for a managed pgvector path that still keeps data in-country.
• 6. Is cost the binding constraint at large scale? Self-host. At 100 million vectors, self-hosted pgvector, Qdrant or Milvus stay under $100 per month against Pinecone's $700-plus — you pay in operational attention rather than invoice.

The through-line of this guide is a single piece of discipline: pgvector-first, graduate at a named threshold, and refuse to over-buy. Start where your data already is, watch your index size against available RAM, and move to a dedicated store only when the scale ceiling, a hybrid-search requirement or a residency constraint gives you a concrete reason. If you make the decision this way, the choice survives a change of embedding model or a change of scale, because the rigour lives in the process rather than in any one product's benchmark. That is the difference between choosing a vector database and being sold one.