Introduction

      ╔════════════╗
      ║   client   ║░
      ╚════════════╝░
       ░░░░░║░░░░░░░░
            ▼
╔═ turbopuffer ════════════╗
║  ┏━━━━━━━━━━━━━━━━━━━━┓  ║░
║  ┃    Memory/SSD      ┃  ║░
║  ┃      Cache         ┃  ║░
║  ┗━━━━━━━━┳━━━━━━━━━━━┛  ║░
║           ▼              ║░
║  ┏━━━━━━━━━━━━━━━━━━━━┓  ║░
║  ┃    Object Storage  ┃  ║░
║  ┃      (S3)          ┃  ║░
║  ┗━━━━━━━━━━━━━━━━━━━━┛  ║░
╚══════════════════════════╝░
 ░░░░░░░░░░░░░░░░░░░░░░░░░░░░

turbopuffer is a fast, object-storage native search engine. We service 1T+ documents, 10M+ writes/s, and 25k+ queries/s.

Using only object storage for state and NVMe SSD with memory cache for compute, turbopuffer scales low-latency queries to petabyte scale. This makes turbopuffer as fast as in-memory search engines when cached, but far cheaper to run.

turbopuffer has many features you'd expect from a database optimized for search, including:

  • Filters, against an inverted index
  • Text search, ranking and boosting
  • Vector search, >90% recall, combined with any filters, dense & sparse
  • Regex search, with fast trigram regex indexes
  • Branching, copy-on-write namespaces
  • Encryption, your key or your customer's
  • Multi-tenant (default), single-tenant, or BYOC deployments

turbopuffer's tradeoffs for its excellent economics and scalability are higher write latency (p90=248ms for 512KB upserts) from writing directly to object storage, and occasional cold queries for uncached or unpinned data (p90=1214ms on 1M documents). These are excellent tradeoffs for search.

Using object storage as the sole source of truth enables operations like branching — a copy-on-write clone of any namespace, created in constant time regardless of size, with fully independent reads and writes afterward.

To get started with turbopuffer, see the quickstart guide.