Decision comparison
Turbopuffer vs Vald
turbopuffer and Vald sit at opposite ends of the operating spectrum. turbopuffer is a managed service built on object storage, which makes thousands of mostly-idle namespaces cheap and asks nothing of you operationally beyond an API key. Vald is an open-source distributed engine you run on your own Kubernetes cluster, which gives you control, cloud independence and the ability to deploy on-premise — and hands you the operational work in full.
Architecture choice. These take different approaches to the same problem. Read the table as a fit question rather than a feature race.
All 2 are vector databases.
Quick Comparison
| Decision factor | Turbopuffer | Vald |
|---|---|---|
| What it is | A managed serverless vector search service built on object storage | An open-source distributed vector search engine designed to run on Kubernetes |
| Who operates it | The vendor; there is no self-hosted build | You, on your own Kubernetes cluster |
| Architecture | Object storage as the system of record with cache tiers in front, so idle data costs storage rather than memory | Distributed agents with index replication across nodes, scaled with Kubernetes primitives |
| Cost shape | Usage-based on stored bytes and queries; idle namespaces are inexpensive | Infrastructure plus engineering time; there is no licence fee and no usage bill |
| Namespace model | Namespaces are the unit of isolation, and the design assumes very many of them | Agents and index replicas, sized and placed by you rather than multiplied cheaply |
| Latency profile | Warm namespaces behave normally; a cold one pays a penalty on its first query | Memory-resident indexes give consistent latency, with memory cost to match |
| Operational requirement | An API key | A Kubernetes cluster, and someone who understands it well enough to run a stateful distributed service on it |
Turbopuffer
- What it is:
- A managed serverless vector search service built on object storage
- Who operates it:
- The vendor; there is no self-hosted build
- Architecture:
- Object storage as the system of record with cache tiers in front, so idle data costs storage rather than memory
- Cost shape:
- Usage-based on stored bytes and queries; idle namespaces are inexpensive
- Namespace model:
- Namespaces are the unit of isolation, and the design assumes very many of them
- Latency profile:
- Warm namespaces behave normally; a cold one pays a penalty on its first query
- Operational requirement:
- An API key
Vald
- What it is:
- An open-source distributed vector search engine designed to run on Kubernetes
- Who operates it:
- You, on your own Kubernetes cluster
- Architecture:
- Distributed agents with index replication across nodes, scaled with Kubernetes primitives
- Cost shape:
- Infrastructure plus engineering time; there is no licence fee and no usage bill
- Namespace model:
- Agents and index replicas, sized and placed by you rather than multiplied cheaply
- Latency profile:
- Memory-resident indexes give consistent latency, with memory cost to match
- Operational requirement:
- A Kubernetes cluster, and someone who understands it well enough to run a stateful distributed service on it
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 | Turbopuffer | Vald |
|---|---|---|
| GitHub commits, 90d(Developer adoption) | 30 | Not available |
| GitHub stars(Developer adoption) | 169 | Not available |
| Search interest(Market interest) | 0 | Unavailable |
| Hacker News mentions, 90d(Community interest) | 11 | 0 |
| npm weekly downloads(Developer adoption) | 672.4k | Not available |
| PyPI weekly downloads(Developer adoption) | 1.1M | 69 |
| GitHub commits, 90d(Product adoption) | Not available | 21 |
| GitHub stars(Product adoption) | Not available | 1,500+ |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
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
Vald
September 21, 2026Package vulnerabilities
PyPI · vald-client-python@1.8.0
0 vulnerabilities
across 1 package
Repository security score
Not available
Interface Preview
Turbopuffer
Vald
Feature Comparison
| Feature | Turbopuffer | Vald |
|---|---|---|
| Search | ||
| Approximate nearest-neighbour search | Full support | Full support |
| Metadata filtering | Full support | Partial support |
| Very large namespace counts | Full support | Partial support |
| Consistent warm latency | Partial support | Full support |
| Deployment | ||
| Fully managed service | Full support | Not verified |
| Self-hosted on Kubernetes | Not verified | Full support |
| Runs without a cluster | Full support | Not verified |
| Air-gapped or on-premise deployment | Not verified | Full support |
| Scale | ||
| Cheap storage of idle data | Full support | Not verified |
| Horizontal scale-out | Full support | Full support |
| Index replication for availability | Full support | Full support |
| Auto-scaling with demand | Full support | Partial support |
| Ecosystem | ||
| Open-source licence | Not verified | Full support |
| Python client | Full support | Full support |
| REST or gRPC API | Full support | Full support |
| Cloud-agnostic deployment | Not verified | Full support |
Search
Approximate nearest-neighbour search
Metadata filtering
Very large namespace counts
Consistent warm latency
Deployment
Fully managed service
Self-hosted on Kubernetes
Runs without a cluster
Air-gapped or on-premise deployment
Scale
Cheap storage of idle data
Horizontal scale-out
Index replication for availability
Auto-scaling with demand
Ecosystem
Open-source licence
Python client
REST or gRPC API
Cloud-agnostic deployment
Which approach fits
turbopuffer and Vald sit at opposite ends of the operating spectrum. turbopuffer is a managed service built on object storage, which makes thousands of mostly-idle namespaces cheap and asks nothing of you operationally beyond an API key. Vald is an open-source distributed engine you run on your own Kubernetes cluster, which gives you control, cloud independence and the ability to deploy on-premise — and hands you the operational work in full.
When each approach fits
Choose Turbopuffer if:
Choose turbopuffer when the workload is many small namespaces, most of them idle, and you would rather not run a distributed stateful service. Building on object storage means a namespace nobody queried this month costs storage rather than memory, which changes the economics of per-tenant indexes entirely. The constraints are that there is no self-hosted build and a cold namespace pays a latency penalty on its first query.
Choose Vald if:
Choose Vald when you need the engine inside your own infrastructure. It is open source and runs on your Kubernetes cluster, so it works on any cloud, on-premise, or in an air-gapped environment where a managed service is not an option. Memory-resident indexes give consistent latency. The price is that operating a distributed stateful service on Kubernetes is a real and ongoing responsibility.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
Is running Vald on Kubernetes actually hard?
It is a distributed stateful service, which is the harder category. You are sizing memory for index replicas, handling node failure and rebalancing, planning upgrades that do not lose the index, and monitoring all of it. None of this is exotic if your team already runs stateful workloads on Kubernetes, and all of it is a meaningful undertaking if it would be your first. Be honest about which situation you are in before comparing feature tables.
Why does object storage change the cost so much?
Because it separates holding data from serving it. A memory-resident engine pays RAM for every index whether or not anyone queries it, so a thousand tenants means a thousand indexes in memory. Building on object storage means idle namespaces cost pennies per GB and only active ones consume compute. With a long tail of inactive tenants that is the entire business case; with one constantly queried corpus it buys nothing and costs cold-start latency.
What does the cold-start penalty look like?
The first query against a namespace that is not cached has to fetch from object storage, adding meaningful latency before the cache warms; subsequent queries behave normally. Whether it matters depends entirely on access pattern. An interactive search box where each user hits their own rarely-used namespace will feel it on every session. A background job or a namespace queried continuously will not notice.
Can we avoid vendor lock-in with turbopuffer?
Only partly. There is no self-hosted build, so the service is the only way to run it, and that is a genuine commitment. The mitigation is that embeddings are portable — the vectors carry no proprietary format — so migrating means re-uploading and rebuilding indexes rather than reconstructing data. If regulatory or contractual requirements rule out a managed service entirely, Vald is the option that satisfies them.
Which is the safer default?
For most teams, the managed service, simply because operating a distributed vector engine is work that competes with building the product. Vald becomes the right answer when a specific constraint makes it so: data residency, an air-gapped environment, an existing Kubernetes platform team with capacity, or a scale where the usage bill exceeds the cost of running it yourself.