Qdrant Raised $50M, Pinecone Explored a Sale: Picking a Vector Database in 2026

#database #ai #programming #opensource

The two most useful facts about vector databases in 2026 are both business facts. Qdrant closed a $50M Series B in March 2026, taking total funding to about $87.8M. Pinecone, the company that turned "vector database" into a product category, reportedly hired bankers to explore a sale and replaced its founder-CEO with a hire from Google.

Meanwhile AWS, Google Cloud, Databricks, Snowflake and MongoDB all added vector search to databases they already sell, and Postgres does it with a free extension. The pure-play vendors are squeezed from both directions, so they are competing on latency, memory cost and hybrid search rather than on storing vectors at all. If you are building retrieval-augmented generation or agent memory, that competition is working in your favor, and the reflexive 2023 answer of "just use Pinecone" deserves rechecking.

I published a fuller version of this comparison on DevToolLab, Best Vector Databases in 2026, with the full pricing table and every source linked. Here is the compressed version.

The Search Problem in One Paragraph

An embedding model turns text, images or audio into a list of floats. Similar content lands close together in that space, so answering a question means embedding the question and finding the nearest stored vectors. Doing that exactly means scoring every vector you have, which is accurate and slow, so these systems use approximate nearest neighbor indexes, usually HNSW, and give up a sliver of recall for a large speedup. Everything that distinguishes one product from another sits around that: which indexes exist, how metadata filtering interacts with the index, how aggressively vectors can be quantized to cut RAM, and who runs the servers.

Three Shapes, Not Five Products

The market splits three ways, and that narrows the decision faster than any feature table.

Pinecone is managed and proprietary: no infrastructure to touch, no self-hosting escape hatch, usage-based bills. Weaviate, Qdrant and Milvus are open source with a managed cloud, which is where most of the current engineering effort is going. pgvector is a feature of a database you already operate, with vectors sitting beside your relational rows.

Pinecone

Fastest path from nothing to a working retrieval endpoint. Serverless separates storage from compute so idle indexes are cheap, namespaces handle multi-tenancy, and sparse-dense hybrid search is supported. Nothing to tune, which is the point.

The costs are strategic rather than technical. You cannot self-host, the index internals are undisclosed so you cannot swap algorithms or chase recall yourself, and the vendor is publicly in motion. The Starter tier is free up to 2GB with 1M read units and 2M write units a month. Builder is a flat $20/month; Standard carries a $50/month minimum and Enterprise $500/month, both pay-as-you-go above that. On Standard, usage lands around $16 to $18 per million read units, $4 to $4.50 per million write units and $0.33/GB/month of storage. Forecast your read volume before you commit, because read-heavy RAG is exactly where a usage meter surprises people.

Weaviate

Go, BSD-3-Clause, managed cloud and bring-your-own-cloud. Its real differentiator is hybrid search: dense similarity and BM25 keyword scoring fused natively, which beats pure vector search whenever exact tokens matter, and they matter more than people expect for SKUs, surnames and error strings.

Release 1.37.0 in April 2026 added a built-in MCP server in preview, so coding agents can query Weaviate over the Model Context Protocol, plus MMR diversity search, query profiling and incremental backups. Built-in vectorizer and reranker modules mean it can call your embedding model instead of making you embed client-side. The tradeoffs: the module system is configuration surface you have to learn, and single-node latency generally trails Qdrant. Self-hosting is free, the cloud free tier covers 100,000 objects, Flex starts at $45/month billed per million vector dimensions from $0.00465, and Premium starts at $400/month prepaid. That resource model replaced a $25/month serverless tier retired in October 2025, which annoyed a lot of small projects.

Qdrant

Rust and Apache 2.0, and the one I reach for when latency and a forecastable bill both matter. No garbage collector pauses, SIMD distance math, over 250 million package downloads and 29,000-plus GitHub stars, with Canva, HubSpot and Bosch in production.

Version 1.18 in May 2026 shipped TurboQuant, a quantization method derived from Google Research that claims roughly scalar-quantization recall at about half the memory, plus per-collection memory monitoring and named vectors you can add or drop without recreating the collection. That sits on top of scalar, product and binary quantization and filterable HNSW, so tight metadata filters do not destroy recall.

Cloud pricing is per provisioned resource (vCPU, RAM, disk) rather than per query, which makes cost flat no matter how much traffic you send. Fewer AI modules than Weaviate, so bring your own embeddings, and the enterprise feature set is younger than the incumbents. Qdrant also publishes its own benchmark suite showing itself ahead on QPS and latency; the methodology is open source, but read any single-vendor benchmark as directional. The free managed cluster is 1GB with no card and no expiry, which is genuinely enough to prototype on.

Milvus

Apache 2.0, built by Zilliz for billion-scale work, compute separated from storage. It supports the widest index range here by a distance: HNSW, IVF variants, DiskANN and GPU indexes including NVIDIA CAGRA.

Milvus 2.6 went open source in June 2025 and reached general availability on Zilliz Cloud on January 20, 2026, themed entirely on cost at scale. Zilliz claims RaBitQ 1-bit quantization cuts memory up to 72%, that tiered storage cuts storage cost substantially, and that its BM25 full-text search beats Elasticsearch by several times. Those are vendor numbers.

The honest cost is operational. Self-hosting means etcd, an object store, and several coordinator and worker components, which is why most teams that pick Milvus end up on Zilliz Cloud anyway. For a few million vectors it is straightforwardly overkill. Self-hosting is free, Zilliz Cloud has a 5GB free tier, serverless starts at $0 and bills around $4 per million vCUs, and dedicated clusters run from roughly $126/GB/month. Storage dropped to $0.04/GB/month in January 2026, down 87% from $0.30.

pgvector

Not a database. An extension under the PostgreSQL License that adds a vector column type and similarity search to Postgres, and for a large share of applications it is the correct answer that gets skipped for being boring. Embeddings live next to your relational data, inside the same transactions and joins, with no new system to operate. Every managed Postgres supports it.

0.8.0 added iterative index scans, fixing the old over-filtering problem where a strict WHERE plus vector search returned too few rows. Note that 0.8.2, released February 26, 2026, was a security fix for a buffer overflow in parallel HNSW index builds, tracked as CVE-2026-3172, so self-managed Postgres should be upgraded. It will not reach billions of vectors as gracefully as Milvus or Qdrant, and high recall at high QPS lags the purpose-built engines. Hybrid search is assembly work with Postgres full-text search rather than a feature. pgvectorscale from Timescale adds a StreamingDiskANN index if you need to close part of that gap.

The rule I would apply: stay on pgvector until you can prove you have outgrown one large Postgres node. Plenty of teams never do.

Five Questions, In Order

Already on Postgres with fewer than a few million vectors? pgvector. Do not add infrastructure yet.
Want zero ops and accept usage billing plus lock-in? Pinecone.
Is keyword-plus-vector hybrid search core, or are you multi-tenant SaaS? Weaviate.
Need the lowest latency and a flat bill? Qdrant.
Hundreds of millions of vectors, or GPU search? Milvus, most likely on Zilliz Cloud.

Prototyping on pgvector or a free managed tier and migrating later is a legitimate plan, because embeddings are portable. Migration is mostly re-upserting vectors.

What the Database Is Actually Doing

Before an index makes it fast, retrieval is one similarity calculation. This runs with NumPy alone:

import numpy as np

def cosine_similarity(a, b):
    a, b = np.array(a), np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

query = [0.11, 0.92, 0.34]          # real embeddings are 768-3072 dims
docs = {"doc-a": [0.10, 0.90, 0.30], "doc-b": [0.88, 0.05, 0.42]}

for doc_id, vec in sorted(docs.items(), key=lambda kv: cosine_similarity(query, kv[1]), reverse=True):
    print(f"{doc_id}: {cosine_similarity(query, vec):.4f}")

doc-a: 0.9995
doc-b: 0.2964

doc-a wins because it points nearly the same direction as the query. On Postgres the same idea is plain SQL, where <=> is cosine distance and smaller means closer:

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id        bigserial PRIMARY KEY,
  content   text,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

SELECT id, content
FROM documents
ORDER BY embedding <=> '[0.11, 0.92, 0.34, ...]'
LIMIT 5;

Quantization, hybrid fusion, distributed indexing and multi-tenancy all exist to keep that query working at a scale where one ORDER BY collapses. Two things worth having open while you build: the Cosine Similarity Calculator for checking your distance math by hand, and the Docker Compose Generator for standing up self-hosted Qdrant, Weaviate or Milvus locally before you pay anyone.

There is no winner here, only clean best-fit answers. Pick for the scale you have today, prove retrieval quality on your real corpus, and move when you hit a concrete limit rather than a hypothetical one.