Vendor selection at billion-vector scale is a different question from vendor selection at million-vector scale. Most of the products in this list were designed for a specific scale band; pushing them past that band breaks the operational story.
**The three that scale to billions in 2026.**
*Milvus and its managed twin Zilliz Cloud.* The canonical open source choice for billion-scale vector search. Multi-shard architecture, multiple index types (IVF-PQ, HNSW, DiskANN), and public deployments at LinkedIn and Salesforce. This is the default reach for serious billion-scale work.
*Vespa.* A horizontally scaled IR engine used at Yahoo and Spotify for over a decade. Hybrid sparse + dense retrieval in a single index. Operationally heavy but designed from day one for billions of documents and high QPS.
*Pinecone enterprise.* Either pod based (the legacy enterprise tier) or serverless P2 (the newer offering). Managed, with compressed indexes designed for billions. The managed shape means you do not run the infrastructure yourself, in exchange for a per vector cost.
**The three that do not scale to billions.**
*Chroma.* Designed for embedded local use, RAG prototyping, and single machine workflows. Excellent at that job, completely wrong shape for billions.
*pgvector default config.* Postgres extension. Comfortable through about 10M vectors on a single Postgres instance; query latency drifts past interactive thresholds beyond that. Sharding Postgres for billion-vector workloads is possible but is no longer in pgvector's design intent.
*LanceDB.* Columnar on disk format aimed at analytical workflows. Strong for batch retrieval and analytical use cases at moderate scale, not optimized for billion-vector high QPS production retrieval.
**Billion-vector scale is an architectural property, not a marketing claim.** A vector DB credible at that scale needs multi-shard horizontal scaling, ANN index types that work in compressed form (PQ, BQ, or DiskANN), and a real operational track record. Three vendors clear that bar in 2026; three do not.
**Milvus / Zilliz Cloud (credible).** Multi-shard architecture with segment based storage, supports IVF-PQ, HNSW, and DiskANN. Open source Milvus is widely deployed at billion-scale; Zilliz Cloud is the managed offering from the same team. Public reference deployments at LinkedIn and Salesforce. Default reach for billion-scale work where the team can operate Kubernetes or pay for managed.
**Vespa (credible).** Yahoo originated, now open source, horizontally scaled retrieval engine that handles hybrid sparse + dense in a single index. Multi-tenant deployments at Yahoo serve billions of documents; Spotify, OkCupid, and several large media platforms run on it. Operationally heavyweight (more like Elasticsearch than like a managed vector DB) but the architecture is right for billion-vector workloads with hybrid retrieval requirements.
**Pinecone enterprise (credible).** The pod based enterprise tier and the newer serverless P2 are both designed for billion-scale managed workloads, with compressed indexes (Pinecone uses proprietary compression) and multi-region replication. The managed shape means no Kubernetes operations on the customer's side, in exchange for a per vector per month fee that becomes substantial at billions.
**Chroma (not credible at billions).** Designed for embedded use inside a single application process, optimized for RAG prototyping and small to medium workloads. Excellent at that job. Pushing Chroma to billions is a category error.
**pgvector default config (not credible at billions).** Postgres extension that runs ANN search inside the database.
Quick reference
TL;DR
Billion-scale credible: Milvus / Zilliz, Vespa, Pinecone enterprise. Not credible: Chroma (embedded), pgvector default (single instance Postgres), LanceDB (analytical workflows, not high QPS retrieval).
Imagine you need a warehouse for a billion small boxes. You would not pick a kitchen pantry, a single room storage unit, or a shed designed for garden tools. You would pick a multi-building logistics facility with forklifts, conveyors, and a staff that has run something this size before. Vector databases work the same way. Some products are designed for billions from day one (Milvus, Vespa, Pinecone enterprise); others are excellent at small scale but were never built to be split across many machines. The question is asking you to tell the categories apart by their architecture, not by their marketing.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Corpus is under 100M vectors with no clear path to billions The complexity of billion-scale vendors (Milvus operational surface, Vespa configuration depth, Pinecone enterprise cost) is unjustified; managed serverless options are the right fit.
Embedded use inside a single application process for RAG prototyping Chroma or LanceDB are the right architectural shape for that workload; reaching for Milvus or Vespa adds operational cost with no scale benefit.
Analytical workflows over an ML training data lake LanceDB or a columnar lake format is purpose-built for that pattern; using a billion-scale online retrieval engine is the wrong tool.
Quick scan · 2–4 min
Everything important, quickly.
4 min: architectural bar for billion-scale (multi-shard + compressed indexes + segment based + replication), the three credible vendors (Milvus / Zilliz, Vespa, Pinecone enterprise) with their reference deployments, and why Chroma / pgvector / LanceDB miss the bar by design.
Horizontally scaled IR engine, hybrid sparse + dense
Yes, Yahoo / Spotify deployments
Pinecone enterprise
Managed multi-region, compressed indexes
Yes, multi-tenant managed offering
Chroma
Embedded in-process library
No, single machine design
pgvector default
Postgres extension on single instance
No, peaks around 10-50M vectors
LanceDB
Columnar on disk analytical format
No, design center is data lake not online retrieval
Real-world examples
Real products, models, and research that use this idea.
1LinkedIn operates Milvus at billion-vector scale for embedding based recommendations across feed, search, and ads ranking.
2Salesforce Einstein uses Milvus for billion-scale embedding retrieval across customer facing AI features.
3Yahoo runs Vespa as the retrieval engine for Yahoo Mail, news, and finance, serving billions of documents per index across many production clusters.
4Spotify built its podcast and music search retrieval on Vespa for the same horizontal scaling reasons.
5Pinecone enterprise serves billion-scale workloads for several Fortune 500 customers on the pod based tier and increasingly on the serverless P2 offering in 2026.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does Milvus's segment based architecture help at billion scale compared to a monolithic HNSW index?
Sign in or go Pro to see the approach for this follow-up.
QWhy does pgvector hit a wall around 10-50M vectors on a single Postgres instance?
Sign in or go Pro to see the approach for this follow-up.
QWhen would you pick Vespa over Milvus at billion scale?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming any modern vector DB can scale to billions because the marketing says so. Architecture matters: embedded single machine stores and single instance Postgres extensions hit hard walls long before a billion vectors.