Decision comparison
Qdrant vs Turbopuffer
Qdrant and turbopuffer make opposite bets about where a vector index should live. Qdrant keeps it in memory for consistently low latency, with quantisation to keep that affordable, and can be self-hosted. turbopuffer keeps it on object storage, so a large corpus costs little to hold and you pay mainly when queries run — at the price of a slower first read against an idle collection.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 2 are vector databases.
Quick Comparison
| Decision factor | Qdrant | Turbopuffer |
|---|---|---|
| What it is | An open-source vector database written in Rust, with strong metadata filtering and a managed cloud alongside self-hosting | A serverless vector and full-text search engine built on object storage, priced so that large, rarely queried collections stay inexpensive |
| Index location | Memory-resident, with quantisation and disk options to reduce cost | Object storage, with caching for the parts being queried |
| Cost shape | Scales with corpus size, since searchable vectors occupy memory | Storage is cheap; you pay mainly when queries run |
| Latency profile | Consistently low, because the index is already in memory | Low when warm, higher on a cold read against an idle collection |
| Deployment | Self-hosted with Docker or Kubernetes, or Qdrant Cloud | Serverless managed service |
| Multi-tenancy | Collections and payload filtering, scaled by you | Designed for many collections where most are idle most of the time |
| Best fit | Hot corpora with strict latency targets | Many collections, large corpora, and a small searched fraction per day |
| Integration path | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support | Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support |
Qdrant
- What it is:
- An open-source vector database written in Rust, with strong metadata filtering and a managed cloud alongside self-hosting
- Index location:
- Memory-resident, with quantisation and disk options to reduce cost
- Cost shape:
- Scales with corpus size, since searchable vectors occupy memory
- Latency profile:
- Consistently low, because the index is already in memory
- Deployment:
- Self-hosted with Docker or Kubernetes, or Qdrant Cloud
- Multi-tenancy:
- Collections and payload filtering, scaled by you
- Best fit:
- Hot corpora with strict latency targets
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
Turbopuffer
- What it is:
- A serverless vector and full-text search engine built on object storage, priced so that large, rarely queried collections stay inexpensive
- Index location:
- Object storage, with caching for the parts being queried
- Cost shape:
- Storage is cheap; you pay mainly when queries run
- Latency profile:
- Low when warm, higher on a cold read against an idle collection
- Deployment:
- Serverless managed service
- Multi-tenancy:
- Designed for many collections where most are idle most of the time
- Best fit:
- Many collections, large corpora, and a small searched fraction per day
- Integration path:
- Python and JavaScript clients over a REST API, with LangChain and LlamaIndex support
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | Qdrant | Turbopuffer |
|---|---|---|
| Docker Hub pulls(Product adoption) | 46.6M | Not available |
| GitHub commits, 90d(Product adoption) | 754 | Not available |
| GitHub stars(Product adoption) | 34,000+ | Not available |
| Search interest(Market interest) | 3 | 0 |
| Hacker News mentions, 90d(Community interest) | 8 | 11 |
| Hugging Face downloads(Product adoption) | 3.9M | Not available |
| Hugging Face likes(Product adoption) | 69 | Not available |
| npm weekly downloads(Developer adoption) | 601.6k | 672.4k |
| PyPI weekly downloads(Developer adoption) | 2.7M | 1.1M |
| Stack Overflow questions(Community interest) | 60 | Not available |
| GitHub commits, 90d(Developer adoption) | Not available | 30 |
| GitHub stars(Developer adoption) | Not available | 169 |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
Qdrant
September 21, 2026Package vulnerabilities
npm · @qdrant/js-client-rest@1.19.0 · PyPI · qdrant-client@1.19.1
0 vulnerabilities
across 2 packages
Repository security score
Not available
Turbopuffer
September 21, 2026Package vulnerabilities
npm · @turbopuffer/turbopuffer@2.9.0 · PyPI · turbopuffer@2.10.1
0 vulnerabilities
across 2 packages
Repository security score
Not available
Interface Preview
Qdrant
Turbopuffer
Feature Comparison
| Feature | Qdrant | Turbopuffer |
|---|---|---|
| Storage | ||
| Memory-resident index | Full support | Partial support |
| Object storage backed | Partial support | Full support |
| Quantisation to reduce memory | Full support | Partial support |
| Cost independent of corpus size | Not verified | Full support |
| Search | ||
| Approximate nearest neighbour indexing | Full support | Full support |
| Filtering with selective predicates | Full support | Full support |
| Hybrid keyword and vector search | Full support | Full support |
| Consistent low latency when cold | Full support | Partial support |
| Operations | ||
| Self-hosted deployment | Full support | Not verified |
| Serverless, nothing to size | Partial support | Full support |
| Open source | Full support | Not verified |
| Many isolated collections | Partial support | Full support |
| Integration | ||
| Python and JavaScript clients | Full support | Full support |
| REST API | Full support | Full support |
| Metadata stored with vectors | Full support | Full support |
| Works with LangChain and LlamaIndex | Full support | Full support |
Storage
Memory-resident index
Object storage backed
Quantisation to reduce memory
Cost independent of corpus size
Search
Approximate nearest neighbour indexing
Filtering with selective predicates
Hybrid keyword and vector search
Consistent low latency when cold
Operations
Self-hosted deployment
Serverless, nothing to size
Open source
Many isolated collections
Integration
Python and JavaScript clients
REST API
Metadata stored with vectors
Works with LangChain and LlamaIndex
Which to choose
Qdrant and turbopuffer make opposite bets about where a vector index should live. Qdrant keeps it in memory for consistently low latency, with quantisation to keep that affordable, and can be self-hosted. turbopuffer keeps it on object storage, so a large corpus costs little to hold and you pay mainly when queries run — at the price of a slower first read against an idle collection.
Best-fit scenarios
Choose Qdrant if:
Choose Qdrant when latency is a contract and the corpus is hot. A memory-resident index answers consistently rather than variably, filtering stays fast with selective predicates, quantisation keeps memory tractable as the corpus grows, and self-hosting keeps the whole thing inside your infrastructure.
Choose Turbopuffer if:
Choose turbopuffer when most of your vectors are idle most of the time. Keeping the index on object storage means a large corpus — or thousands of per-customer collections — costs very little to hold, and the bill follows queries rather than data volume, which inverts the economics of long-tail retrieval.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
What fraction of our vectors are searched in a normal day?
It is the number that decides this comparison and most teams have never measured it. If nearly all of the corpus is searched daily, memory residency is honest value and you are paying for something you use. If a small fraction is — per-customer indexes, archived documents, a long tail nobody touches — keeping it all in memory is paying to keep cold data warm.
How bad is a cold read in practice?
It depends on whether a human is waiting. For a background job or an internal search used a few times an hour, the first-query penalty is irrelevant. For an interactive feature where a user is watching a spinner, it may be unacceptable on the first request and fine thereafter. Test it on your own access pattern rather than assuming either extreme.
How does filtering work on each?
Almost every real query is "similar to this, and belonging to this customer, and not archived", and a naive implementation filters after retrieving neighbours, which returns too few results when the predicate is selective. Qdrant addresses this directly: payload indexes and filtering are applied during graph traversal rather than afterwards, which is the main reason to choose it over a simpler store. turbopuffer leans on namespaces, so the common per-tenant filter becomes a choice of namespace and never reaches the search at all, with attribute filters available for the rest. Test both with your most selective predicate.
What keeps embeddings in step with the rows they describe?
Something you build, in both cases, because neither holds the source data. A document is edited, a product renamed, a record deleted, and each needs the embedding regenerated and the index updated in the right order. Qdrant makes the update side straightforward with upserts keyed by your own ids and payload updates that do not require re-embedding. turbopuffer's namespace model makes wholesale replacement of a tenant's data simple, which suits corpora rebuilt in batches. Budget the pipeline explicitly either way: it is the part of a vector deployment that fails quietly.
What do these need to run?
An embedding model and a client. Applications in Python or JavaScript call a REST API, embeddings come from an OpenAI, Cohere or open-source model, and the retrieval framework is usually LangChain or LlamaIndex. Self-hosted options run as containers on Docker or Kubernetes with S3 or compatible object storage behind them; managed options need only an API key. The infrastructure is unremarkable — the work is in chunking, embedding choice and keeping the index current.
How should we evaluate them?
With your own corpus and your own queries, measuring recall rather than latency alone. Approximate nearest neighbour search trades accuracy for speed, and the tuning knobs differ between engines, so a fast engine returning worse neighbours looks good on a benchmark and bad to a user. Build a small set of queries with known correct answers, then compare recall at the latency you actually need.