Vendor selection for a vector database is mostly about matching the tool to the team and the deadline, not about chasing the most impressive benchmark.
**Look at the constraints first.** Two million documents is small for a modern vector DB; any managed vendor handles that comfortably. One week is short; that rules out anything that needs infrastructure work before you can ingest. No DevOps headcount means whatever you pick has to run itself, with backups, monitoring, and scaling all handled by the vendor.
**The shape that fits is managed serverless.** Pinecone Serverless, Turbopuffer, Qdrant Cloud, and Weaviate Cloud all let you create an index from a dashboard, get an API key, and start upserting vectors within minutes. The first index is usually free or cheap enough to fit a startup budget. Operations are the vendor's problem; your team writes application code.
**Why the other options are wrong.** Self hosted Milvus on Kubernetes is a strong choice at hundreds of millions to billions of vectors with a platform team; for 2M docs with no DevOps, it is overbuilt by a factor of 10 to 100, and just standing up the K8s cluster will eat most of the week. Building your own FAISS service is a deeper version of the same trap. Vespa is powerful but operationally heavyweight; it shines for hybrid retrieval at LinkedIn-scale and is wrong for a startup launching in a week.
**Match the database to the binding constraint, which here is operational headcount, not capacity.** At 2M documents the corpus fits comfortably on every managed vendor's smallest tier; the deciding factor is days of work to a live index.
**Managed serverless wins this profile by a wide margin.** Pinecone Serverless, Turbopuffer, Qdrant Cloud, and Weaviate Cloud all expose: create-index from a dashboard, get an API key, upsert vectors, query. Time to first query is measured in minutes. Backups, replication, monitoring, scaling, and version upgrades are the vendor's responsibility. The team spends its week on chunking, embedding, retrieval evaluation, and product UX, which is what actually moves the launch.
**Self hosted Milvus** is operationally heavy. A production cluster wants etcd, MinIO or S3, the Milvus components themselves, observability, and a backup story. Standing this up on Kubernetes from scratch consumes a week of senior infra time before any document is ingested. Milvus genuinely shines from a few hundred million vectors upward with a platform team; that profile does not match 2M docs and no DevOps.
**Build your own on FAISS plus EC2** is the deepest version of the same trap. You inherit replication, failover, snapshotting, sharding, and SDK design. There is no business reason to take this on at 2M docs.
**Vespa** is a powerful hybrid retrieval system used at Yahoo, Spotify, and large media platforms. The operational surface is comparable to running Elasticsearch plus a custom retrieval layer. Wrong shape for a one week startup launch even though the engine is excellent.
The right answer for this scenario is unambiguously managed serverless. The lesson is to size the tool to the team.
Quick reference
TL;DR
With 2M docs, no DevOps, and one week, pick a managed serverless vendor (Pinecone Serverless or Turbopuffer). Self hosted Milvus or custom FAISS is the wrong shape for this team.
Imagine you need a place to live for a week and you have no time and no tools. You do not go buy land and start pouring concrete; you check into a hotel. Vector database choices work the same way. A small team with a tight deadline picks a managed service that runs itself; a giant team with millions of documents and a permanent platform crew can afford to build its own. Picking the right tool for the team you actually have, not the team you might have someday, is the whole skill here.
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.
Compliance requires keeping all data in a self managed environment with no third party SaaS Managed serverless is off the table even at small scale; self hosted Qdrant or Milvus becomes the right answer despite the operational cost.
The team already runs a Kubernetes platform with on-call rotation Self hosted Qdrant or Milvus is a reasonable choice because the marginal operational cost is small for a team that already does the work.
Corpus grows to hundreds of millions of vectors with predictable cost pressure At that scale the cost of managed serverless per vector per month can exceed the cost of a self hosted cluster, and the migration path starts to make sense.
Quick scan · 2–4 min
Everything important, quickly.
3 min: identify the binding constraint (headcount + deadline), why managed serverless is the right shape, why self hosted Milvus and Vespa are wrong sized, the credible shortlist (Pinecone Serverless, Turbopuffer, Qdrant Cloud, Weaviate Cloud), and the migration boundary where self hosted starts to make sense.
Side-by-side
Option
Time to first query
Fits this scenario?
Pinecone Serverless / Turbopuffer
Minutes
Yes, correct shape
Qdrant Cloud / Weaviate Cloud
Minutes
Yes, also correct shape
Self hosted Milvus on Kubernetes
Days, with platform expertise
No, overbuilt for 2M docs and no DevOps
Vespa
Days to weeks, with IR expertise
No, operationally heavyweight
FAISS + EC2 + custom replication
Weeks
No, custom infra eats the whole deadline
Real-world examples
Real products, models, and research that use this idea.
1Pinecone Serverless launched its current pricing model precisely to capture this small team profile; index creation to first query is under five minutes.
2Turbopuffer's object store backed architecture is unusually cheap at 1-10M vectors and is a popular pick for early stage RAG startups in 2026.
3Qdrant Cloud uses the same engine as self hosted Qdrant; teams often start on the managed tier and migrate to self hosted only when scale and team size justify it.
4Weaviate Cloud is widely used by teams that want hybrid sparse + dense retrieval with minimal infrastructure work, especially in content and media startups.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QHow would you decide between Pinecone Serverless and Turbopuffer for this scenario?
Sign in or go Pro to see the approach for this follow-up.
QAt what corpus size does self hosted Qdrant or Milvus become competitive on cost?
Sign in or go Pro to see the approach for this follow-up.
QWhat would change the answer if the scenario had a strict on-premise requirement?
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
Picking Milvus or Vespa because they win on billion-scale benchmarks, ignoring that the team has no DevOps to operate them and the corpus is two orders of magnitude smaller than where those systems start to matter.