Linear migrated search off Elasticsearch and pgvector onto turbopuffer and experienced:
- Single system for vector and full-text search
- Zero-ops search for terabytes of data
- 70% reduction in cost, unlocking indexing far more data
Linear replaced Elasticsearch & pgvector to cut down ops and unify their search infrastructure. Cost wasn't the focus, but 70% savings has Linear thinking about indexing far more data.
70%
cost reduction
2B+
documents
13ms
p50 latency
4M+
namespaces
Their responsiveness and shipping velocity make us feel like we are their only customer.
Tom Moor, Head of Engineering
Linear was drawn to turbopuffer for its ability to ingest 100s of millions of full-text search documents & vectors without having to think about machine types. Instead, Linear can focus on shipping features.
Linear does hybrid search (FTS + vector) on multiple
(org_id, table) namespaces, rank fuse, and re-rank:
┌──────────────────────────────┐
│ ┌──────┐ ┌────────────────┐ │
│ │Linear│─▶│ Cohere │ │
│ │Query │ │ Embedding │ │
│ └──────┘ └──────┬─────────┘ │
│ ▼ │
│ ┌─turbopuffer queries────┐ │
│ │ Issues Vector │ │
│ ├────────────────────────┤ │
│ │ Issues FTS │ │
│ ├────────────────────────┤ │
│ │ Document Vector │ │
│ ├────────────────────────┤ │
│ │ Document FTS │ │
│ ├────────────────────────┤ │
│ │ Project Vector │ │
│ ├────────────────────────┤ │
│ │ Project FTS │ │
│ └───────────┬────────────┘ │
│ ▼ │
│ ┌────────────┐ │
│ │ Rank Fuse │ │
│ └─────┬──────┘ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Cohere Rerank│ │
│ └──────────────┘ │
└──────────────────────────────┘Customer data security is critical to Linear. The ability to use customer managed encryption keys (CMEK) on a per namespace basis stood out.
When a user submits a search, Linear will issue parallel queries across multiple namespaces (documents, issues, projects, comments, attachments, and initiatives) using vector + FTS to return a list of results that then get passed into a reranker:
Linear also leverages turbopuffer for:
Linear plans to leverage turbopuffer to power all of their AI features.
Linear migrated search off Elasticsearch and pgvector onto turbopuffer and experienced:
Linear migrated from running its own embedding pipeline to turbopuffer's native embeddings. They no longer have to deal with juggling rate limits and SDK complexity across multiple embedding providers, and they also sped up their embedding pipeline:
We love working with turbopuffer. I've never felt sold to and I've always felt I know exactly what I'm buying. Which when you're buying critical infrastructure is absolutely crucial.
Peter Travers, Software Engineer
Linear rebuilt its delta sync read path on turbopuffer. A client returning online needs to catch up on workspace changes without downloading everything. The largest workspaces can produce close to one million sync actions per day, and the reconnect query has to evaluate which changes the client should be able to see — over terabytes of change history.
The previous Postgres path scanned the full set of sync actions since the last client checkpoint and tested array-overlap predicates for each action, so tail latency grew with the volume of workspace changes. turbopuffer represents sync groups and subscriptions as posting lists, so the query intersects those sets directly instead of testing each candidate row individually.
In production:
tail latency vs
workspace size
HIGH
│ ┌─── pg p99
│ ┌───┼┄┄┄ pg p95
│ ┌───┼┄┄┄┘
│ ┌───┼┄┄┄┘
│────┼┄┄┄┘
│┄┄┄┄┘
│
│──────────────────── tpuf p99
│┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄ tpuf p95
LOW
└┬──────────────────┬
SMALL ENTERPRISE
source:
linear.app/now/
rebuilding-delta-sync-
read-path
The biggest win for us with turbopuffer was flat p95 and p99. In general, tpuf has just been a lot more reliable than the Postgres solution.
Peter Travers, Software Engineer
We will continue to update this log as Linear's usage of turbopuffer evolves.