Vector Databases in 2026: Pinecone vs. Milvus/Zilliz vs. Qdrant vs. Weaviate vs. pgvector

Buyer's guide, verified November 8, 2026. Every price and product claim below was checked against the vendor's own pricing page, list price, changelog, or repository on this date — where a vendor publishes nothing, we say so instead of guessing. This category reprices and re-licenses continuously (two of the five changed their commercial model during 2026), so treat every number as the starting point of your own verification, not a quote.

You searched for vector databases because something specific hurts: a RAG proof of concept that works at 100,000 embeddings and falls over at 50 million, a retrieval bill nobody can explain, or a mandate to "add semantic search" that quietly means choosing a piece of infrastructure you will run for years. This guide compares the five options a platform team actually faces in November 2026 — Pinecone, Milvus via Zilliz Cloud, Qdrant, Weaviate, and pgvector on a managed Postgres — with honest weaknesses for each, because a page that reads like an ad does not help you spend money well.

One search query, three completely different purchases

Before you shortlist anything, understand the trap hiding in this query: "vector database" spans three different line items on three different budgets. Pinecone sells you a metered serverless service — you never see a cluster, and you pay in read units, write units, storage, and (since 2026) egress. Milvus, Qdrant, and Weaviate are engines — Apache-2.0 or BSD code you can run yourself, each with a managed cloud attached, and the interesting 2026 developments are in the engines: Milvus 3.0 went lake-native in July, Qdrant 1.20 shipped a new compressed vector datatype family in October, and Weaviate quietly split its repository into an open core and a license-keyed enterprise directory. pgvector is not a database at all — it is a Postgres extension that makes the database you already run do ANN search, billed at whatever your Postgres host charges for compute and disk.

Buying the wrong half of that sentence is the most expensive mistake in this market. If your data already lives in Postgres and you need 10 million vectors, buying a dedicated vector service is a new system, a new bill, and a new sync pipeline. If you are building a multi-tenant SaaS serving 500 million vectors across 30,000 tenants, running ANN search on your primary Postgres is a way to lose both your database and your customers. Start from the workload shape, not the vendor logos.

The 60-second comparison

All facts below verified against the vendors' own pages and repositories on November 8, 2026.

        PRODUCTION RAG STACK, NOVEMBER 2026 — WHERE THE VECTOR STORE SITS
        ==================================================================

  documents ──▶ chunking ──▶ embedding model ──▶ upsert      query path
                                                     │             │
                                                     ▼             ▼
     ┌──────────────────────── VECTOR STORE LAYER ────────────────┐
     │                                                            │
     │  [METERED SERVERLESS]      [ENGINE YOU OWN/RUN]   [POSTGRES]│
     │                                                            │
     │   Pinecone                Milvus (K8s/Docker)      pgvector │
     │   RU x namespace size     Qdrant (binary/container)  on the │
     │   WU + storage            Weaviate (core BSD)       primary│
     │   + egress metering                │                 or a  │
     │        │                          │                replica │
     │        ▼                          ▼                        │
     │   no cluster to see      managed cloud twins:              │
     │   (BYOC only at          Zilliz Cloud / Qdrant Cloud /     │
     │    Enterprise tier)      Weaviate Cloud (Flex/Premium)     │
     └────────────────────────────────────────────────────────────┘
                                                     │
                                                     ▼
                              retriever ──▶ reranker ──▶ LLM
                              (hybrid search + filters matter
                               more than raw ANN latency in
                               most RAG stacks)

One structural note before the vendor sections: in a typical RAG system the vector store is not the latency bottleneck — chunking, embedding, and reranking dominate the request path. That is precisely why the market is drifting toward features that reduce what you fetch (hybrid/BM25 search, reranking, compression) and toward billing models that reward shrewd data layout. You will see both dynamics below, and both show up on the invoice.

Pinecone: the metered serverless incumbent — and the namespace-size tax

Pinecone is the most SaaS-like option here and, as of November 2026, the most aggressively repriced. The 2026 changelog shows a platform that changed its commercial surface three times in one year: a new Builder plan at $20/month flat (introduced May 2026), egress metering with per-plan allowances (reads that return record data are metered, and on Starter and Builder reads are blocked — not billed — once the allowance is exhausted), and the retirement of the $250 bulk-import credit (remaining balances expired November 1, 2026; imports now bill at $0.25/GB).

Now the part that decides whether Pinecone is cheap or catastrophic for you: read units scale with the size of the namespace you query, not with the size of your answer. Per the cost documentation, a query uses 1 RU for every 1 GB of namespace size, with a 0.25 RU minimum — the docs' own table runs 1 GB → 1 RU, 10 GB → 10 RUs, 100 GB → 100 RUs. A top-k=10 query against a 61 GB namespace bills the same 61-ish RUs whether it returns 10 vectors or 100 metadata fields. The mitigation is architectural, and it is the single highest-leverage decision on this page: put each tenant (or each shard) in its own namespace, because RU consumption is computed per namespace queried. Pinecone's plan matrix itself tells you this is the intended pattern — Standard includes 100,000 namespaces per index for a reason.

from pinecone import Pinecone

pc = Pinecone(api_key="...")
idx = pc.Index("rag-prod")

# ANTI-PATTERN: one giant namespace. RU cost per query ~= namespace
# size in GB, so a 61 GB namespace burns ~61 RUs per query. At 10 QPS
# that is ~1.59B RUs/mo -> about $25,480/mo at the $16/M low-end rate.
idx.upsert(vectors=batch, namespace="")            # default ns

# PATTERN: tenant-per-namespace. 61 GB split across 100 tenant
# namespaces = 0.61 GB each -> 0.61 RUs per query, ~15.9M RUs/mo
# -> about $255/mo for the identical query load. Same data,
# same plan, ~100x difference on the invoice.
idx.upsert(vectors=batch, namespace=f"tenant-{tenant_id}")
hits = idx.query(
    vector=query_embedding,
    top_k=10,
    namespace=f"tenant-{tenant_id}",   # RUs scale with THIS size
    include_metadata=True,
)

Honest weaknesses. On-demand RU pricing is hostile to large single namespaces and to high-QPS workloads — at real scale you end up negotiating Dedicated Read Nodes (Standard tier) instead of reading a price list, and DRN pricing is quote-based. There is no self-host exit: your data, your index, and your operational telemetry all live behind Pinecone's API (BYOC exists only at Enterprise). Starter is locked to AWS us-east-1, so the free tier is not a residency test bed. Pods — the old fixed-capacity deployment model — are explicitly the legacy path; if you are still on pods, the platform will migrate you, on its schedule. And the 2026 billing changes (egress metering with hard blocking, dead import credits) show a vendor willing to change the meter mid-year; budget reviews are not optional.

Who should buy it: teams that want zero operational surface, are multi-tenant by design (namespace-per-tenant), and would rather pay a premium than own index tuning. Who should skip it: single-namespace, high-QPS, or very large indexes — the RU model punishes exactly that shape.

Milvus and Zilliz Cloud: the lake-native turn

Milvus is the largest of the open-source engines here (46.6k GitHub stars, Apache-2.0, a graduated LF AI & Data project), and 2026 was the biggest architectural year in its history. Milvus 3.0 (July 2026) made the engine lake-native: External Collections define collections over data that stays in object storage and open table formats — Lance, Iceberg, Parquet, or Vortex — and Milvus builds vector, full-text, JSON, and scalar indexes over the files without copying the source data into Milvus, kept current by incremental synchronization. Underneath sits Loon, a new manifest-based storage engine that uses Vortex (an Arrow-compatible columnar format) as its default storage format and is designed to cut the read amplification of low-latency point access on object storage. Third-party analysis (elest.io) notes External Collections are read-only and that at 3.0.0 Loon is off by default — treat the lake-native path as a young architecture, not a settled one.

The retrieval engine grew up too: server-side sorting, aggregation, and faceted search (combine semantic relevance with price, freshness, tenant, category — in the engine instead of over-fetching into your app), StructList for native multi-vector entities (a document with per-chunk vectors, an image with per-patch vectors, including late-interaction models like ColBERT and ColPali), an optimized sparse index roughly 3× smaller at comparable recall, and a Spark DataSource V2 connector so Databricks/EMR pipelines read and write Milvus directly. Milvus v3.0.4 (Oct 26) and v3.0.5 (Oct 30) are the stabilization drumbeat for all this: faster bulk import, compaction, and filtered/grouped search, lazy column-group loading, and fixes for coordinator restarts, rolling upgrades, transient etcd errors, and access-control CVEs — the release notes themselves are the honest map of what still breaks.

Zilliz Cloud (the managed commercial twin) restructured its plans around the 3.0 generation: a Serverless option ("from $0/month"), Standard Dedicated from $126/mo, Enterprise Dedicated from $197/mo (99.95% SLA, SSO/SAML, granular RBAC, private endpoints, VPC peering), a Business Critical tier at contact-sales (global clusters, CMEK, HIPAA-eligible), BYOC, and a genuinely new billing primitive: On-demand Compute at $0.41/CU-hour for lake-scale query jobs and system-managed index builds over zero-copy external data — you pay only for active job runtime instead of an always-on cluster. The published SKU list prices (verified Nov 8, 2026): serving compute $0.273/CU-hr (performance- and capacity-optimized; tiered-storage $0.41/CU-hr), storage $0.025/GB-mo, backups $0.025/GB-mo, volumes $0.04/GB-mo, storage requests $5 per 1M class-1 and $0.40 per 1M class-2, and data transfer with the first 100 GB free, then $0.09/GB from North America/Europe and $0.14/GB from Asia/Oceania — private-endpoint API traffic is exempt from data-transfer charges entirely.

Honest weaknesses. Milvus OSS in cluster mode is a platform commitment, not a container: the 3.0.5 release notes fixing "coordinator restarts, rolling upgrades and transient etcd errors" describe a distributed system with real operational edges, and the press release positions Kubernetes or Docker with S3/GCS/Azure Blob as the substrate — you are running (or buying the operations of) coordinators, message queues, and object storage. The 3.0 architecture is young; the flagship Loon engine is default-off, which tells you how the project itself rates its production readiness. Serverless unit rates are only published in the docs' cost model — the list-price page renders Dedicated SKUs by default, so budgeting a Serverless workload means reading docs, not a price table. And Business Critical — the tier regulated industries will actually need — is contact-sales with no published floor.

Who should buy it: teams with a Kubernetes platform already, billion-vector ambitions, or a data-lakehouse story where "index the Parquet in place" kills a copy-and-sync pipeline — that is the one feature nobody else on this page ships. Who should skip it: sub-10M-vector workloads on a team with no platform engineering — you would be renting a cargo ship to cross a canal.

Qdrant: the engine with the best 2026 storage story — and no published rates

Qdrant (Apache-2.0, 35.5k stars) is the Rust-written engine that platform teams increasingly default to, and v1.20.0 (October 22, 2026) is a release with real cost consequences. The headline is TurboQuant datatypes: turbo16, turbo8, and turbo4 store vectors at 2, 1, and 0.5 bytes per dimension respectively (vs. 4 for float32), by rotating each vector so its values share a spread and then quantizing per-vector. The docs' own guidance: turbo16 if you want float32 recall at half the size, turbo8 (new in v1.20.0) for near-float32 recall at a quarter of the size, turbo4 when storage is the constraint and you accept lower recall. This matters commercially: on a 1B-vector 1536-dim corpus, turbo8 is the difference between ~5.7 TB and ~1.4 TB of raw vector data before you have bought a single hour of compute. Datatypes are distinct from Qdrant's quantization feature (which builds a separate quantized representation alongside originals), and v1.20 rounds it out with BM25 scoring directly on the full-text payload index (hybrid search without maintaining parallel sparse vectors), per-element nested payload indexes for arrays of objects, substring filter conditions (full-scan only), a configurable audit-log output, and a long list of HNSW build/heal/snapshot and AVX-512 VNNI kernel improvements.

Qdrant Cloud's structure is clean: a free tier (single node, 0.5 vCPU / 1 GB RAM / 4 GB disk, free cloud inference with selected models), a Standard tier (usage-based, dedicated resources, flexible vertical and horizontal scaling, HA setups, backup and disaster recovery, 99.5% uptime SLA, subscribed via the AWS/Azure/GCP marketplaces), a Premium tier (minimum spend; SSO, private VPC links, 99.9% uptime SLA), plus deployment models the others do not offer: Hybrid Cloud (managed Qdrant clusters running on your infrastructure — data stays in your network, operations come from Qdrant Cloud), Private Cloud (dedicated, air-gapped-capable), an Edge beta, and a Serverless waitlist.

Honest weaknesses. There is no published rate card: Standard-tier pricing requires the interactive calculator or a marketplace subscription quote, which makes procurement comparisons annoying and makes this guide unable to print a Qdrant line-item (we will not invent one). The free tier is a 4 GB-disk single node — smaller than Zilliz's 5 GB and useless for realistic evaluation. BM25 landed weeks ago, so hybrid-search maturity is one release deep. And the SLA ladder (99.5% Standard, 99.9% Premium) sits below Zilliz Enterprise's published 99.95%.

Who should buy it: teams who want a single engine to self-host, run on their own cloud via Hybrid Cloud, or rent — Qdrant's deployment spectrum is the widest here — and anyone for whom TurboQuant turns a storage problem into a non-problem. Who should skip it: buyers who need printed list prices for a procurement fight, and anyone needing a support org with a decade of enterprise scars.

Weaviate: the flexible data model, now with an open-core boundary

Weaviate's pitch is the AI-native feature set — built-in vectorizer modules, hybrid search, multi-tenancy, named vectors — and its 2026 pricing page is the most transparent about what the free tier is: 100,000 objects, 1 collection, up to 3 tenants, 1 GB memory, 10 GB disk, 2,000 embedding requests/day and 1,000 Query-Agent requests/month, free forever. The step up is Flex: pay-as-you-go from a $45/month minimum, which the page explicitly states "covers the baseline cluster cost and includes charges for Vector Dimensions and Storage" — note the billing unit: Weaviate meters by vector dimensions, so your cost scales with dimensionality (1536-d embeddings cost ~2× what 768-d costs) even before storage. Backups are charged on top, by data volume and retention (Flex gets 7-day retention; Premium shared/dedicated get 30/45 days). Premium — prepaid contract, shared or dedicated, "from $400/month" per the page FAQ — unlocks SSO/SAML, a metrics endpoint, PrivateLink, customer-key encryption, HIPAA (dedicated only), and up to 99.95% uptime with 1-hour Sev-1 support. Embedded services are separately metered: hosted embedding models at $0.025–$0.065 per 1M tokens, and the Query Agent at $30/organization/month with 4,000 requests included.

The structural 2026 story is the license. The repository now reads: "Source code in this repository is variously licensed under the BSD-3-Clause License, or the Weaviate License" — the core is BSD-3-Clause, but everything under the wl/ directory is "Copyright Weaviate BV 2026-present, all rights reserved," available only under a separate enterprise license, "enabled via license key," and the BSD license explicitly "does not grant the right to use these features or circumvent any license key." That is a full open-core split, and it happened this year. If your self-hosted Weaviate plan assumed every feature in the repo was yours to run, verify which of your dependencies live in wl/ before you standardize.

On the engineering side, Weaviate remains on the 1.x series (v1.40.4, November 5, 2026) and the release notes are dominated by runtime-reindex reliability work — making runtime reindex and replica movement mutually exclusive, refusing filterable-only tokenization changes when a searchable index exists, reindex-aware backup gates, frozen-tenant reporting, LSM-bucket flush fixes. Those are the right fixes to make, and they are also a map: if you plan to change tokenizer or reindex live collections, budget for care.

Honest weaknesses. The free tier omits backups, HA, flexible index types, and the metrics endpoint — it is a feature tour, not a staging environment, and there is no self-serve published price between $45 and "contact sales" for dedicated. Dimension-based billing is invisible until your embedding model choice doubles your bill. The wl/ split means "open source" is no longer a simple sentence in this category. And with v1.40 still stabilizing runtime reindex, treat live schema changes as risk items on your runbook.

Who should buy it: teams that want the managed cloud with the most forgiving on-ramp (the free tier is permanent, not a trial) and AI-native services (embeddings, query agent) bundled where the data lives. Who should skip it: buyers who need a published price for a dedicated production cluster this week, and self-hosters who have not audited the wl/ boundary against their feature list.

pgvector: the database you already run, doing a new job

Every option above is a new system to buy or operate. pgvector is a Postgres extension (PostgreSQL License, 23.6k stars) that adds ANN indexes to the database your application already uses — meaning vector search gains transactions, backups, row-level security, and your existing operators for free, and loses nothing you already rely on. The 2026 release record is boring in the best way: v0.8.7 (Oct 1, 2026) fixed a buffer overflow in IVFFlat index builds; v0.8.6 fixed a 32-bit build overflow and a nested-loop-join memory leak; v0.8.3 fixed possible HNSW index corruption during vacuuming; v0.8.2 fixed a parallel-build overflow. The engineering lesson is two-sided — the project is in careful maintenance mode, and two of those fixes are index-integrity-class, so pin and upgrade your pgvector version deliberately. The meaningful features are already shipped: iterative index scans (v0.8.0) fixed filtered-search recall, halfvec/sparsevec/binary quantization keep footprints down, and v0.9.0 (unreleased as of Nov 8, 2026) adds asynchronous HNSW I/O and drops Postgres 13/14.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE docs (
  id         bigserial PRIMARY KEY,
  tenant_id  bigint NOT NULL,
  body       text NOT NULL,
  embedding  vector(1536)          -- halfvec(1536) halves storage to ~2 bytes/dim
);

-- HNSW build: sized for maintenance_work_mem; build in one statement
-- or you pay a full rebuild (no online HNSW build in pgvector today).
SET maintenance_work_mem = '2GB';
CREATE INDEX docs_embedding_hnsw
  ON docs USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- Query: raise ef_search for recall, lower it for latency.
SET LOCAL hnsw.ef_search = 40;
SELECT id, body
FROM docs
WHERE tenant_id = $1                       -- filter + ANN in one engine:
  AND embedding <=> $2                    -- no sync pipeline, no second
ORDER BY embedding <=> $2                 -- source of truth to reconcile
LIMIT 10;

The hosting economics are where this becomes a real buyer's decision. On Neon (now "Lakebase Postgres, by Databricks" — object-storage-based with local caching, autoscaling and scale-to-zero, database branching): Free plan includes 100 projects, 100 CU-hrs/month per project and 1 GB storage; Launch bills $0.106/CU-hr and $0.35/GB-month (Neon's own example spend: $15/mo for intermittent load on 1 GB). On Supabase (pgvector ships as the built-in "Vector" module): Free is 500 MB database with shared CPU and projects paused after 1 week of inactivity (2 active projects); Pro is $25/month, then compute add-ons run from $10/month (Micro) to $3,730/month (16XL, 64 vCPU/256 GB RAM), with 8 GB disk included and $0.125/GB after.

Honest weaknesses. pgvector is a search index, not a search product: no built-in BM25/hybrid (you pair it with Postgres full-text search and fuse ranks yourself), no managed reranking, and recall/latency tuning is your problem (ef_search, m, lists). HNSW index builds on large corpora are slow and memory-hungry (maintenance_work_mem), there is no online build, and a reindex is downtime-planned work. Vector memory is not cleanly isolated from OLTP memory — one bad query plan can starve both workloads on the same instance. And the Postgres scale ceiling is real: past a few hundred million vectors, or with exotic filters, the dedicated engines justify themselves.

Who should buy it: teams whose vectors are a feature of an existing Postgres application — typically up to tens of millions of vectors — and who value one system to operate. Who should skip it: dedicated retrieval platforms at hundreds of millions of vectors, hybrid/BM25-first products that do not want to hand-roll ranking, and teams with zero Postgres competence (the extension inherits all of Postgres, including its operational demands).

What it costs at a real workload — Nov 8, 2026 math

One scenario, computed with a Decimal script against the list prices above (raw float32 vectors, 30-day month, 25.92M queries/month at 10 QPS): 10 million vectors at 1536 dimensions = 61.44 GB, excluding metadata and index overhead. Compute sizing for the Postgres options is an assumption (labeled); everything else is a published rate.

raw vector bytes : 61,440,000,000
raw size         : 61.44 GB (decimal, float32, excl. metadata + index overhead)
queries per month: 25,920,000

PINECONE STANDARD (on-demand, $16/M RU low-end region):
  storage                     : 61.44 GB x $0.33 = $20.28
  RU/query unsharded (1 ns)   : 61.44
  RUs/mo unsharded            : 1,592,524,800
  read cost unsharded         : $25480.40
  TOTAL unsharded (1 ns)      : $25500.67
  namespace size x100 sharded : 0.6144 GB -> RU/query 0.6144
  RUs/mo sharded              : 15,925,248
  read cost sharded           : $254.80
  TOTAL sharded               : $275.08
  sharding ratio              : 1E+2x

ZILLIZ CLOUD DEDICATED (Standard, list price):
  1 CU compute (730h x $0.273) : $199.29
  storage 61.44 GB x $0.025     : $1.54
  TOTAL (1 CU, excl. egress)    : $200.83

NEON (pgvector, Launch, ASSUMED 2 CU sustained):
  compute 2 CU x 730h x $0.106  : $154.76
  storage 61.44 GB x $0.35      : $21.50
  TOTAL                         : $176.26

SUPABASE (pgvector, Pro + compute add-on):
  Pro $25 + Large $110 + disk:  $141.68
  Pro $25 + XL $210 + same disk: $241.68

Read that first row twice. The difference between $25,500 and $275 on Pinecone is not a discount negotiation, a committed-use contract, or a region choice — it is the shape of your namespaces. No other vendor on this page has a billable unit that responds so violently to data layout. Conversely, no other vendor has a free tier as production-shaped as Zilliz's 5 GB / 2.5M vCUs, and none of the engine vendors will print you a quote without a conversation. The Postgres options are the cheapest at this size if your sizing assumptions hold — which is exactly the assumption a POC must test, because ANN on 61 GB with 8 GB of RAM is a quantization conversation, not a billing one.

Capability-by-capability

Hidden fees and the traps worth a line item each

• Pinecone RU metering scales with namespace size per query — verified above at 100×. Also new in 2026: egress allowances (1/10/100 GB by plan) where Starter and Builder block reads that return record data when exhausted; bulk imports at $0.25/GB with the $250 credit program dead; restore at $0.15/GB plus cross-region transfer; HIPAA as a $190/month add-on on Standard.
• Zilliz bills storage while your cluster is suspended — compute stops, storage and backups keep billing until you delete the cluster (their FAQ's own words). Volumes cost $0.04/GB-mo (vs. $0.025 for cluster storage), storage-request operations are metered ($5/1M class-1), and the audit-log feature is an add-on at $0.034/CU-hr. The egress exemption for private-endpoint traffic is the discount to engineer for.
• Weaviate meters vector dimensions — a 1536-dim corpus costs ~2× a 768-dim one at the same object count, backups bill on top of the minimum, and the free tier has no backup, no HA, and no metrics endpoint.
• Supabase's compute ladder is the steepest cost cliff here — $10 to $3,730/month for compute add-ons, with the free tier pausing projects after one idle week (a nasty surprise for a staging environment that "mysteriously" lost data connectivity). Disk is 8 GB included then $0.125/GB.
• Neon's $0.106/CU-hr is an idle-and-both-ways rate — autoscaling bills only what you use (and scales to zero), which is the feature; it also means your 10-QPS assumption, not the price list, decides the invoice.
• pgvector upgrades are not cosmetic — 2026 shipped index-corruption and buffer-overflow fixes (v0.8.2/0.8.3/0.8.6/0.8.7); a stale pgvector is a data-integrity exposure, so put it on the patch calendar.

Who should pick what — the bottom line

• If you are multi-tenant SaaS with no platform team and want zero operational surface: pick Pinecone, architect namespace-per-tenant from day one (it is a billing decision, not just an isolation one), start on Standard's $50 minimum, and negotiate Dedicated Read Nodes when QPS outgrows on-demand RUs.
• If you are building on a lakehouse or need to search data where it lives: pick Milvus 3.0 / Zilliz Cloud. External Collections over Parquet/Iceberg/Lance is the only "index in place" story on this page, the published SKU list ($0.273/CU-hr, $0.025/GB-mo) is the most transparent dedicated pricing here, and the OSS exit is Apache-2.0. Treat Loon as early and the coordinator/etcd operational surface as real work.
• If storage cost or self-host sovereignty drives the decision: pick Qdrant. TurboQuant at 1–2 bytes per dimension is a genuine storage economics win, Hybrid Cloud runs managed Qdrant inside your own network, and the v1.20 BM25-on-payload-index removes the parallel-sparse-vector tax. Get the Standard-tier quote in writing before you compare it to the others.
• If you want the AI-native managed stack with the gentlest on-ramp: pick Weaviate Cloud. The permanent free tier, built-in embeddings and query agent, and native multi-tenancy are real product depth — just model dimension billing, read the wl/ license boundary before self-hosting, and expect Premium (from $400/mo) to be the production landing zone.
• If the vectors belong to an application that already runs on Postgres: pick pgvector first. At 10M×1536-d it is the cheapest verified option on this page ($141–$242/mo on Supabase, ~$176 assumed on Neon), with one system to back up, secure, and staff. Graduate to a dedicated engine when recall tuning, hybrid search, or the vector count — not the hype — forces it.

Who should skip this entire category

• Your vectors are a feature, not a product (under ~10M vectors, one team, no exotic filters): pgvector on the Postgres you already pay for beats every managed option on cost and on operational simplicity; a second database for a similarity endpoint is a sync pipeline you will maintain forever. See our LLM observability tools guide for the measurement layer you do need as the RAG stack matures.
• You have not chosen an embedding model yet: dimensionality is a first-class billing unit at Weaviate and a storage multiplier everywhere — choosing a 1536-dim model before you know whether 768-dim quality suffices is buying the seat before the plane.
• You need hybrid/BM25 only: if vectors have not earned their keep, Postgres full-text search (or OpenSearch) may serve the requirement with zero new infrastructure — do not buy a vector database to run keyword search badly.
• You are waiting on lake-native anyway: Milvus 3.0's external-index path is the future of this category, but at three months old with its storage engine default-off, teams without lakehouse infrastructure get more value from the boring, stable paths today — re-evaluate when your data platform owns the Parquet.

The skeptical summary: the 2026 vector database market is three markets wearing one name. Pinecone sells convenience at metered rates whose RU unit punishes bad namespace design by 100× — the same 61 GB costs $25,500 or $275 depending on how you shard it. Milvus/Zilliz sold the most interesting architecture (index the lake in place) and the most transparent dedicated rate card. Qdrant shipped the best storage economics (TurboQuant) and the widest deployment spectrum, but no printable prices. Weaviate is the most product-like managed stack, and its 2026 open-core split is the fine print every self-hoster must now read. pgvector is the option that quietly wins every cost model under 10M vectors — with your existing operators, backups, and pager rotation as the subsidy. Prices and limits verified November 8, 2026; this page gets refreshed when the rate cards move.