LabHub

Blog

Vector Databases 2026 Deep-Dive — Pinecone, Weaviate, Qdrant, Milvus, pgvector, LanceDB, Chroma, FAISS, DiskANN

2026-05-16 · 18 min read · #vector-database#pinecone#weaviate#qdrant#milvus#pgvector#lancedb#chroma#faiss#hnsw#embeddings#rag#semantic-search#ann

한국어English日本語

Intro — In May 2026, the vector DB has become commodity infra

Back in 2023, vector databases were the new category that answered "where do I put my embeddings if I want to build RAG?" By May 2026 that question is settled. RAG has matured, vector search has shown up as a default option in almost every OLTP/OLAP DB, and hybrid search (BM25 + dense vector + reranker) is the new standard.

This post is not a marketing matrix. It is an honest read on which vector DBs occupy which slot in production today. We compare Pinecone Serverless v3, Weaviate 1.30, Qdrant 1.13, Milvus 2.5 + Zilliz Cloud, Chroma, LanceDB, pgvector 0.8 + pgvectorscale 0.6 + ParadeDB, Vespa, OpenSearch k-NN, Redis Vector, MongoDB Atlas Vector, Couchbase, SingleStore, Turbopuffer, Marqo, Vald, NGT, FAISS, ScaNN, DiskANN, Annoy, DuckDB VSS, sqlite-vec, and jina HnswLib usage with concrete API examples.

The vector DB landscape in 2026 — five tracks

Here is the big picture. The 2026 market splits into five tracks:

  1. Pure-play vector DBs: Pinecone, Weaviate, Qdrant, Milvus, Chroma, LanceDB, Turbopuffer, Marqo
  2. Relational DB vector extensions: pgvector + pgvectorscale, ParadeDB, SingleStore, Oracle 23ai, SQL Server 2025
  3. Search engine vector extensions: Elasticsearch dense_vector, OpenSearch k-NN, Vespa, Solr
  4. General-purpose NoSQL extensions: MongoDB Atlas Vector, Redis Vector, Couchbase, DynamoDB (GA 2025)
  5. Embedded / library: FAISS, ScaNN, DiskANN, Annoy, NGT, HnswLib, Vald, DuckDB VSS, sqlite-vec

They use the same ANN algorithm in many cases (HNSW dominates) but diverge widely in operational model, pricing, multi-tenancy, and hybrid search support. We walk through each track below.

ANN algorithm 1 — why HNSW became the de facto standard

The 2026 default ANN algorithm is HNSW (Hierarchical Navigable Small World), from the 2016 paper by Yu. Malkov and D. Yashunin. It is greedy search over a multi-layer proximity graph.

The strength is that insert, delete, and search are all graph operations, so it copes with dynamic data. The weakness is memory footprint: 100M float32 vectors at 768d with HNSW (M=16) costs roughly 350 GB of RAM.

Pinecone, Weaviate, Qdrant, Milvus, pgvector 0.8, Elasticsearch, OpenSearch, Redis, Chroma, LanceDB, and Vespa all expose HNSW as default or option.

ANN algorithm 2 — the place for IVF, IVF-PQ, DiskANN, and ScaNN

HNSW may be the default, but the alternatives are still alive.

Simplified picker:

Recall vs latency vs cost — the ann-benchmarks reality

Compressed numbers from ann-benchmarks.com as of May 2026 on GIST-960-1M:

The point is "there is no free lunch." Lifting recall from 0.95 to 0.99 usually costs 2x to 5x latency and 1.5x to 3x memory. In production recall@10 = 0.95 is often plenty.

Pinecone Serverless v3 — the managed default

Pinecone went GA with Serverless in January 2024 and finished v3 in Q4 2025, fully splitting storage and compute. As of May 2026, it is the "just use it" managed option.

Typical Python usage:

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="pc-...")

pc.create_index(
    name="rag-prod-2026",
    dimension=1024,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="us-east-1"),
)

index = pc.Index("rag-prod-2026")

index.upsert(
    vectors=[
        {"id": "doc-1", "values": [0.01] * 1024, "metadata": {"tenant": "acme", "lang": "en"}},
    ],
    namespace="tenant-acme",
)

result = index.query(
    vector=[0.01] * 1024,
    top_k=10,
    namespace="tenant-acme",
    filter={"lang": {"$eq": "en"}},
    include_metadata=True,
)

Pinecone's biggest strength is "zero ops." The weakness is unpredictable pricing — RU/WU billing means a traffic spike turns into a bill spike.

Qdrant — the Rust-based self-hosting champion

Qdrant is a Rust-written OSS vector DB and is the most popular pick on the self-hosted track. Highlights of the 1.13 line as of May 2026:

Collection setup and query:

from qdrant_client import QdrantClient
from qdrant_client.models import (
    Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue,
)

client = QdrantClient(url="http://qdrant:6333", api_key="q-...")

client.create_collection(
    collection_name="rag_prod",
    vectors_config=VectorParams(size=1024, distance=Distance.COSINE),
)

client.upsert(
    collection_name="rag_prod",
    points=[PointStruct(id=1, vector=[0.01] * 1024, payload={"lang": "en", "tenant": "acme"})],
)

hits = client.search(
    collection_name="rag_prod",
    query_vector=[0.01] * 1024,
    query_filter=Filter(must=[FieldCondition(key="lang", match=MatchValue(value="en"))]),
    limit=10,
)

Qdrant Cloud is managed on GCP / AWS / Azure with memory/disk-based pricing that is more predictable than Pinecone. Self-host with the Helm chart works well in K8s.

Weaviate — the modules + hybrid leader

Weaviate is a Go-written OSS vector DB. Its strengths are the module system and first-class hybrid search. As of May 2026, 1.30:

Schema and hybrid query:

import weaviate
from weaviate.classes.config import Configure, Property, DataType

client = weaviate.connect_to_local()

client.collections.create(
    name="Doc",
    properties=[
        Property(name="content", data_type=DataType.TEXT),
        Property(name="lang", data_type=DataType.TEXT),
    ],
    vectorizer_config=Configure.Vectorizer.text2vec_openai(model="text-embedding-3-large"),
    generative_config=Configure.Generative.openai(model="gpt-4.1-mini"),
)

docs = client.collections.get("Doc")
result = docs.query.hybrid(
    query="vector database comparison",
    alpha=0.5,
    limit=10,
)

Weaviate's strength is doing "embedding + search + generation" in one system. The weakness is module sprawl, which raises ops cost for self-hosting.

Milvus 2.5 + Zilliz Cloud — the large-scale and GPU champion

Milvus is the LF AI & Data Foundation's large-scale vector DB and is the most battle-tested option at billion-to-tens-of-billions scale. May 2026, 2.5 line:

Collection creation and hybrid search:

from pymilvus import MilvusClient, DataType

client = MilvusClient(uri="http://milvus:19530", token="root:Milvus")

schema = client.create_schema()
schema.add_field("id", DataType.INT64, is_primary=True, auto_id=True)
schema.add_field("dense", DataType.FLOAT_VECTOR, dim=1024)
schema.add_field("sparse", DataType.SPARSE_FLOAT_VECTOR)
schema.add_field("tenant", DataType.VARCHAR, max_length=64)

idx = client.prepare_index_params()
idx.add_index("dense", index_type="HNSW", metric_type="COSINE", params={"M": 16, "efConstruction": 200})
idx.add_index("sparse", index_type="SPARSE_INVERTED_INDEX", metric_type="IP")

client.create_collection("rag", schema=schema, index_params=idx)

Milvus's identity is "enterprise scale." For workloads under ~100M vectors the operational overhead may not pay off — Pinecone / Qdrant / Weaviate fit better there.

pgvector + pgvectorscale + ParadeDB — Postgres is "good enough"

The interesting trend of 2026 is that Postgres + pgvector has settled in as the "good-enough default" when you do not have special requirements.

Typical usage:

CREATE EXTENSION IF NOT EXISTS vector;
CREATE EXTENSION IF NOT EXISTS vectorscale;

CREATE TABLE doc (
    id bigserial PRIMARY KEY,
    tenant_id uuid NOT NULL,
    content text NOT NULL,
    embedding vector(1024) NOT NULL
);

CREATE INDEX ON doc USING diskann (embedding vector_cosine_ops);
CREATE INDEX ON doc (tenant_id);

SELECT id, content, 1 - (embedding <=> $1) AS score
FROM doc
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

The upside is that transactions, joins, permissions, and backup are simply Postgres. The downside is that HNSW memory pressure hurts above ~100M vectors, and RLS-based multi-tenancy can degrade index efficiency.

Chroma and LanceDB — the embedded / local track

The two most common picks for RAG prototypes on a laptop or single production node.

LanceDB's pitch is "one .lance file on S3, done." No standalone managed product yet, but LanceDB Cloud (beta) and SageMaker integration are expanding.

import lancedb

db = lancedb.connect("s3://my-bucket/lance-db")
tbl = db.create_table(
    "docs",
    data=[{"id": 1, "vector": [0.01] * 1024, "lang": "en"}],
    mode="overwrite",
)
tbl.create_index(metric="cosine", index_type="IVF_HNSW_SQ", num_partitions=256)

hits = tbl.search([0.01] * 1024).where("lang = 'en'").limit(10).to_list()

Elasticsearch, OpenSearch, Vespa — the search engine track

Existing BM25 engines now ship serious dense vector support, so many teams keep one cluster for both keyword and hybrid search instead of adding a dedicated vector DB.

This is the most natural path when an organization already runs a search cluster. The trade-off is that they do not match dedicated vector DBs on indexing throughput and RAM efficiency.

NoSQL vector extensions — Mongo, Redis, Couchbase, SingleStore, DuckDB, SQLite

When operational data already lives in a DB, having that DB do vector search is the simplest setup.

The common thread is "no separate cluster for vectors." When you are under 100M vectors and your business is OLTP, this is often the most rational choice.

Emerging track — Turbopuffer, Marqo, Vald, NGT, Tair Vector

Newer entrants are also growing in managed and specialized markets.

FAISS, ScaNN, DiskANN, Annoy, HnswLib — the library track

Not databases but libraries you wire in yourself. Still core for research and embedded use.

Library example with FAISS:

import numpy as np
import faiss

d = 1024
nb = 100000
xb = np.random.random((nb, d)).astype("float32")
xq = np.random.random((1, d)).astype("float32")

index = faiss.IndexHNSWFlat(d, 32)
index.hnsw.efConstruction = 200
index.add(xb)
index.hnsw.efSearch = 64

D, I = index.search(xq, 10)
print(I, D)

Hybrid search — why BM25 + dense + RRF + reranker became standard

A clear lesson since 2024: dense vectors alone are not enough. They struggle with keyword (names, IDs, code) matches and break down on out-of-domain queries. The 2026 standard is this four-step pipeline:

  1. BM25 search (sparse) for top-50 to 100.
  2. Dense vector search for top-50 to 100.
  3. RRF (Reciprocal Rank Fusion) or weighted blend to merge 100 to 200 candidates.
  4. Reranker (Cohere Rerank 3.5, Voyage Reranker 2, BGE Reranker v2-m3, Jina Reranker v2) to top-10.

The RRF formula is simple:

def rrf(rankings: list[list[str]], k: int = 60) -> dict[str, float]:
    scores: dict[str, float] = {}
    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return scores

The reranker is a cross-encoder that sees query and document together. Typical NDCG@10 lift is 5 to 15 percent. Cohere Rerank 3.5 reranks 100 docs in roughly 80 ms at about $2 per 1,000 queries.

Multi-vector, ColBERT, and ColPali — the new accuracy bar

Compressing a document into a single vector throws away detail, so multi-vector retrieval emerged.

The cost is storage: per-token vectors balloon the dataset 50x to 200x. Qdrant, Vespa, Weaviate, and ParadeDB ship multi-vector natively. Pinecone added a beta in Q1 2026.

Filtered search — pre-filter vs post-filter, and metadata indexes

Vector search is almost always paired with metadata filters ("tenant_id = X AND lang = en").

Pinecone, Weaviate, Qdrant, Milvus, and Elasticsearch all build native metadata indexes. pgvector leans on Postgres B-tree / GIN indexes. If multi-tenancy dominates the workload, always benchmark pre-filter performance.

Embedding model choice — OpenAI vs Cohere vs Voyage vs BGE vs E5 vs Jina

A great vector DB cannot save bad embeddings. Top of the MTEB leaderboard as of May 2026:

The picker is (1) do you need multilingual, (2) do you need matryoshka dimensions, (3) do you need to self-host, (4) what is your cost ceiling. For Korean and Japanese, BGE-M3, Cohere v4, Jina v3, and multilingual-e5-large are the safe picks.

RAG-specific patterns — chunking, contextual retrieval, parent-child

Standard patterns layered on top of a vector DB for RAG in 2026:

These patterns are DB-agnostic, but multi-vector and sparse support decide which patterns are easy to wire up.

GPU vector indexing — RAFT, cuVS, and NVIDIA acceleration

NVIDIA RAPIDS' cuVS (RAFT's successor) went GA in 2025 and brought GPU vector indexing into mainstream practice.

The 2025 to 2026 window is the inflection where GPUs matter beyond training. Cost-wise, under 100M vectors on a single node still favors CPU + HNSW.

Cost economics — Pinecone vs Weaviate Cloud vs self-hosted Qdrant

Rough monthly price comparison (May 2026, 100M vectors at 1024d, p50 target 50 ms):

Numbers fan out 4x to 10x depending on traffic shape. For cold RAG, Turbopuffer or pgvector wins. For always-hot traffic, self-hosted Qdrant is usually cheapest.

Adoption in Korea — Naver, Kakao, Toss, Karrot

Korean tech market snapshot as of May 2026:

For Korean embeddings, BGE-M3, Cohere Embed v4, and multilingual-e5-large are de facto standards. Korean-specialized models (KoSimCSE, etc.) still shine on narrow domains.

Adoption in Japan — Vald (LY), NGT (Yahoo), Mercari, LINE Search

NGT is known in Korea too, but running Vald clusters directly is mostly limited to LY / Naver-level operators inside Japan. Mercari's Vespa adoption is frequently cited in the search community.

Decision guide — recommendations by workload

A simplified picker by workload:

If you treat the defaults as (A) Postgres + pgvector + pgvectorscale or (B) managed Qdrant and move only the exceptions, you have the safest path for a fresh RAG project in May 2026.

References

Read the original: https://www.youngju.dev/blog/culture/2026-05-16-vector-databases-pinecone-weaviate-qdrant-milvus-pgvector-lancedb-chroma-faiss-2026-deep-dive.en

Comments

No comments yet.

Sign in to leave a comment