Turbopuffer

Turbopuffer builds vector and full-text search infrastructure for connecting AI applications to large collections of data. Founded by former Shopify engineers Simon Hørup Eskildsen and Justine Li, it began development in 2023. Its central architectural decision is to make object storage the durable source of truth, while using SSD and memory caches to accelerate searches—a design that lets infrequently accessed data remain cheap to store. Cursor became its first large customer, followed by Notion.[5][8][1]

The design grew out of earlier infrastructure work. Eskildsen spent almost a decade at Shopify, where he and Li worked together on database and compute scaling. In his March 2026 interview, he recalled self-hosted Elasticsearch around 2015 as particularly difficult to scale and operate. After leaving Shopify, he moved between friends’ companies in three-month stints he called “angel engineering,” including Readwise, Replicate and Causal.[1][3]

In late 2022, Eskildsen helped Readwise prepare its infrastructure for the launch of Reader, its read-it-later app. The team wanted article recommendations and semantic search using vector embeddings. In his founder account, Eskildsen estimated that vector search across the same 100 million-plus documents would cost more than $20,000 a month, compared with roughly $5,000 a month for Readwise’s relational database. The team shelved the features until costs came down; the problem prompted him to begin building Turbopuffer in 2023.[5]

Cursor’s workload supplied an early fit: it indexed codebases as vectors, but only a subset of those codebases was active at any moment. Keeping every index in memory made inactive data expensive. Turbopuffer reports that Cursor migrated in a few days in November 2023 and reduced its search costs by 95%. Eskildsen recalled recruiting Li as his co-founder during this period and working closely with her on the migration and subsequent reliability work. The company had no outside funding when Cursor came aboard.[5][1]

Turbopuffer’s storage engine commits writes durably to object storage. SSD and memory hold cached data rather than additional authoritative copies. Each search namespace occupies a prefix in object storage, and another node can serve it if a node fails, rebuilding its cache through a cold query. This separates compute from durable storage and allows active data to move into faster, more expensive tiers as needed.[5]

The tradeoff is latency when data is cold. Eskildsen’s architecture account describes cache recovery taking roughly 500 milliseconds and a goal of limiting vector searches to at most three object-storage round trips for sub-second cold latency. The query planner therefore balances fetching more data at once against making additional sequential requests. Warm searches use the SSD and memory caches; the design is especially suited to workloads where only some tenants or datasets are being queried at a time.[5]

Notion’s adoption tested that commitment. Eskildsen recalled that in mid-2024, Notion ran on AWS while Turbopuffer ran on GCP, whose object storage already offered the compare-and-swap operation Turbopuffer used to coordinate metadata updates. Rather than introduce a separate metadata consensus system, the team bought dark fiber, tuned TCP windows and prewarmed connections to reduce cross-cloud latency, while absorbing networking costs. He credited his and Li’s on-call experience for avoiding state spread across multiple systems. The discussed Notion workload still ran on GCP at the March 2026 interview.[1]

Eskildsen described vector search as Turbopuffer’s first act and full-text search as its second. By March 2026, the team was expanding full-text features and optimizing long queries generated or augmented by language models. He kept the product’s scope explicit: “Today, if you’re using Turbo Puffer, it should be because search is very important to you.” Aggregation, logging, time-series and graph features were possible future directions rather than committed product generations.[1]

Agents also changed the query workload. In March 2026, Eskildsen described a shift from one retrieval call before a model response to a single agent issuing many searches concurrently, using a warm dataset to gather context in fewer turns. He said Turbopuffer was reducing query pricing fivefold to accommodate the increased volume.[1]

ANN v3 expanded vector search to indexes containing up to 100 billion vectors. Chief architect Nathan VanBenschoten’s technical account, updated May 5, 2026, explains two complementary techniques: hierarchical clustering based on the prior SPFresh index, which narrows the search to promising clusters, and RaBitQ binary quantization, which compresses vectors to one bit per dimension. The system searches compressed vectors first, then fetches full-precision vectors to rerank candidates that could belong in the final results. Queries run across shards, whose results are merged into a global top-k.[6]

VanBenschoten reports thousands of queries per second with 200-millisecond p99 latency at 100 billion-vector scale. The described workload contains 1,024-dimensional f16 vectors, roughly 200 TiB of dense vector data, with the entire index tree cached on SSD across storage-dense machines. This is a result for that cached deployment, rather than an uncached object-storage latency figure. Eskildsen credited VanBenschoten with leading the implementation over roughly six to eight weeks, with substantial help from the team.[6][1]

The work also exposed CPU bottlenecks after compression reduced data movement. Switching a distance-estimation kernel to AVX-512 enabled accelerated bit counting; VanBenschoten reports a 30% improvement in kernel microbenchmarks and about a 5% improvement in end-to-end production throughput.[6]

Readwise later adopted the infrastructure its earlier problem had inspired. Turbopuffer’s customer log dates Chat with Highlights to January 2025 and reports implementation in less than a month, with more than 150 million vectors ingested. The feature combines vector and full-text matching so readers can query saved highlights using both semantic and exact keyword retrieval.[7]

In July 2026, Readwise moved query embedding generation to Turbopuffer’s native embeddings without re-embedding its indexed documents. Its columns used qwen3-embedding-8b with dimensions truncated from 4,096 to 1,536; Turbopuffer automatically matched query embeddings to the column dimensions. The company-hosted account reports median embedding latency falling from 1.58 seconds to approximately 0.20 seconds, an eightfold improvement in embedding generation rather than end-to-end chat latency.[7]

In December 2025, Turbopuffer secured funding of undisclosed size from existing backer Lachy Groom and new investor Thrive Capital. BetaKit’s December 19 report attributed to Eskildsen tenfold sales growth and fivefold headcount growth during 2025, alongside management of trillions of vectors and tens of petabytes. It also reported 22 employees based on the company’s website.[8]

Eskildsen said he chose Groom because he could speak candidly with him and wanted help with candidates and customers alongside the team’s own database expertise. He recalled telling Groom that he and Li would return the money if the company failed to reach product-market fit by year-end. Taking that investment marked his deliberate commitment to building the company beyond the initial project.[1]

Latent Space’s May 22, 2026 roundup reported that Eskildsen said Turbopuffer crossed a $100 million run-rate in March, 19 months after reaching $1 million, while profitable. The figure was a reported run-rate, not recognized revenue over a completed year.[2]