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.