cloudparts

turbopuffer

A managed vector and full-text search engine that keeps every index in object storage and caches the active parts on NVMe and in memory, trading occasional slow cold queries for a much lower price per GB.

What it is
Vector databases
Used for
Search indexes
Type
Commercial product
Made by
turbopuffer
License
Proprietary; managed service, or run in your own AWS, GCP or Azure account (BYOC)
Facts checked
23 October 2026
Website

What it is

turbopuffer stores documents in namespaces: each has an id, optional dense or sparse vectors and attributes, and lives under its own prefix in S3 or Google Cloud Storage. Object storage is the only source of truth. A write appends a file to the namespace’s write-ahead log in the bucket and returns once it is durable there, which takes about 200 ms, and concurrent writes are batched into at most one log entry per second per namespace. The log is then indexed in the background: vectors into a centroid-based approximate-nearest-neighbour index derived from SPFresh, text into a BM25 inverted index, and attributes into exact indexes for filters. Data not yet indexed is still found by scanning the recent log.

The query nodes are stateless Rust binaries. The first query to a namespace reads straight from object storage in as few round trips as possible (p50 of about 874 ms for a million documents); after that the namespace sits in an NVMe and memory cache on the node it is routed to, and queries take about 14 ms. Reads are consistent by default, which costs one metadata check against the bucket (about 10 ms); eventually consistent reads skip it. A query can rank by vector similarity, by BM25 over one or more fields, or by combinations of them, filter on attributes, aggregate, and use hosted embedding and reranking models. turbopuffer runs as a multi-tenant service in AWS and GCP regions, with Azure in private preview, as single-tenant clusters, or inside your own cloud account (BYOC).

Why teams pick it

  • Cheap at scale: storage is $0.33 per GB-month, because data lives in object storage and only the active part is cached; the founders estimate about $70 per TB-month, against $600 for triple-replicated SSD and $3,600 with RAM on top
  • Built for many tenants: unlimited namespaces (250 million seen), each searched on its own, so a namespace per customer keeps queries small
  • Vector, BM25 full-text, hybrid search, filters and aggregations in one API, with hosted embedding and reranking models
  • Large proven scale: more than a trillion documents and 10 million writes per second across customers, up to 128 billion documents in one sharded namespace, with copy-on-write namespace branching

Watch out for

  • Cold namespaces are slow: the first query after data leaves the cache costs hundreds of milliseconds, so latency-sensitive apps call the warm-cache endpoint ahead of time
  • Writes are high-latency (about 200 ms to commit, at most one log entry per second per namespace), so it suits search workloads, not transactional ones
  • Closed source with no free tier: plans start at a $16 monthly minimum (Launch), $256 (Scale) and $4,096 (Enterprise), and there are no migration tools
  • Deliberately limited ranking: it is built for first-stage retrieval, and complex ranking is left to a reranker or your own code

Good for

Specs

Compare with alternatives →
Data model
Namespaces of documents with an id, dense or sparse vectors and attributes
Query language
HTTP API and SDKs: rank by vector, BM25 or both, with filters and aggregations
Consistency
Consistent reads by default; eventually consistent reads skip a metadata check
How it scales
Stateless query nodes; namespaces can be sharded up to 128 billion documents
Storage format
Write-ahead log and indexes in S3 or GCS, cached on NVMe and in memory
Written in
Rust
Ways to run it
Managed on AWS and GCP (Azure in preview), single-tenant clusters, or BYOC
Pricing model
Usage-based with a monthly minimum per plan; storage per GB-month

Alternatives

What all vector databases have in common →Compare side by side →
PineconeCommercialAlso good for similarity search over embeddings and full-text search with relevance rankingA managed, serverless vector database that keeps its indexes in object storage and serves dense-vector, sparse-vector and BM25 full-text search from the same index.ChromaOpen sourceAlso good for similarity search over embeddingsAn open-source vector database for AI apps that runs inside a Python or JavaScript process, as a single server, or as a distributed service on object storage.ElasticsearchCommercialAlso good for full-text search with relevance ranking and similarity search over embeddingsThe distributed search and analytics engine built on Apache Lucene: JSON documents in, full-text, vector and log queries out, over a REST API.LanceOpen sourceAlso good for similarity search over embeddingsA file and table format for AI data: columnar like Parquet, but fast at fetching single rows, with vector and full-text indexes, versions and room for images and video.Deep LakeOpen sourceAlso good for similarity search over embeddingsActiveloop’s storage format and database for AI data: images, video, audio, text and embeddings stored as compressed columns on object storage, searchable by vector and streamable straight into PyTorch or TensorFlow.VectorizeCommercialAlso good for similarity search over embeddingsCloudflare’s serverless vector database for Workers, which stores embeddings in R2-backed indexes and bills only for vector dimensions stored and queried.

How it fits with other technologies

Write documents with a full-text and an auto-embedded field, then search them · python

import os, turbopuffer  # pip install turbopuffer

tpuf = turbopuffer.Turbopuffer(
    api_key=os.getenv("TURBOPUFFER_API_KEY"), region="gcp-us-east4")
ns = tpuf.namespace("docs-acme")  # created on first write

ns.write(
    upsert_rows=[
        {"id": 1, "category": ["mammal"], "public": True, "text": "walrus narwhal"},
        {"id": 2, "category": ["fish"], "public": False, "text": "pufferfish swordfish"},
    ],
    distance_metric="cosine_distance",
    schema={"text": {"type": "string", "full_text_search": True,
                     "embed": {"model": "nvidia/nemotron-3-embed-8b", "dims": 1024}}},
)

# Vector search, with a filter
ns.query(rank_by=("text", "ANN", ("Embed", "arctic sea mammal")),
         filters=("public", "Eq", True), limit=10)

# BM25 full-text search on the same namespace
ns.query(rank_by=("text", "BM25", "walrus"), limit=10)

See it in a real stack

No architecture uses turbopuffer yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2026

In late 2022 Simon Hørup Eskildsen, who had worked at Shopify, was helping Readwise add recommendations and semantic search over more than 100 million documents. The vector databases of the time kept data in memory at over $2 per GB, and he estimated the feature at more than $20,000 a month, four times what Readwise paid for its main database, so it was shelved. Object storage had become available everywhere and NVMe disks cheap and fast, so he designed a search engine that kept everything in object storage and cached only what was being queried.

He and Justine Li, also from Shopify, launched turbopuffer in October 2023. Cursor moved its search to it in November 2023 and, by turbopuffer’s account, cut its costs by 95%. The company stayed small and commercial-only, is backed by Lachy Groom and Thrive, opened public AWS regions in early 2025 and declared turbopuffer generally available in May 2025. Customers now include Anthropic, Notion, Linear and Atlassian; 2026 brought namespace branching, sharding of single namespaces and native embedding.

Why it’s built this way

Object storage as the only source of truth
Search writes look more like a data warehouse’s than a transactional database’s. Paying for replicated SSD or RAM for all of it made semantic search too expensive; object storage costs cents per GB, and a cache covers the data actually in use.
A centroid-based vector index instead of a graph
Graph indexes such as HNSW or DiskANN need many dependent reads. With clusters around centroids, a cold query downloads the small centroid index and then fetches the nearest clusters in one large round trip of about 100 ms.
No dependencies on the critical path besides object storage
Using the bucket itself as the write-ahead log keeps the query nodes stateless, so any node can serve any namespace and failures don’t lose data.
Accept cold queries
Keeping all data hot is what makes other systems expensive. Taking a few hundred milliseconds on the first query lets cost follow the data that is actually used.

Timeline

  1. 2022

    Vector search for Readwise proves too costly, prompting the design

  2. 2023

    Launch in October; Cursor moves to turbopuffer in November

  3. 2025

    Public AWS regions in March; generally available in May

  4. 2026

    Namespace branching in May, sharding and native embedding in July, an Azure region in preview in August

Sources9 · facts checked 23 October 2026

Improve this page on GitHub