Simon Eskildsen built Turbopuffer after finding that existing search systems were hard to operate and often failed his napkin-math checks.
2
Turbopuffer uses S3 for durable, cheap storage and organizes vector data into clusters, while caching objects to reduce the cost of repeated reads.
3
Eskildsen raises capital only for specific reasons, such as funding R&D or giving employees liquidity, and considers raising for founder status a dangerous choice.
Summary
Simon Eskildsen describes how a childhood interest in web development led to competitive programming, Shopify, and eventually Turbopuffer. At Shopify, he worked on sharding, multi-datacenter systems, database scaling, and failure testing with a proxy that could simulate outages and slowdowns. His napkin-math project grew from a need to check whether infrastructure benchmarks made sense from first principles. After leaving Shopify, he used that approach to build a cheap vector search system on S3. The first version was deliberately simple, with clustered files, centroid IDs, and an Nginx cache in front of S3. Cursor became the first customer after Eskildsen helped diagnose its Postgres and Aurora problems, then migrated its workload to Turbopuffer. He also discusses CPU shortages caused by AI and reinforcement-learning workloads, his six reasons for raising capital, and Turbopuffer's remote culture, including optional employee gatherings called campfires.
Simon learned programming by peeling back layers of web tools
Simon Eskildsen first encountered programming through PowerPoint diagrams, FrontPage, HTML, and PHP. After discovering that Danish-language programming advice on the internet was limited, he spent four years playing World of Warcraft and learned English. He later says he looks for engineers who cannot stop themselves from asking how things work. At Shopify, he wrote down unfamiliar terms such as TCP, then studied them at home. That habit took him from product work toward infrastructure, where he kept asking questions about reverse proxies and systems close to the metal.
Competitive programming taught Simon that difficult computer science can be self-taught
In high school, Simon found the International Olympiad in Informatics through an online friend on the Australian team. The problems were different from the HTML and PHP work he had done. He describes problems involving trucks and packages where the goal is to find the best assignment, even when the problem is NP-complete and cannot be solved perfectly at scale. The competition rewards finding a better answer than other competitors. He says the experience gave him a crash course in computer science and taught him that he could read a paper and work out the material if he spent enough time on it.
Shopify gave Simon a front-row view of infrastructure scaling
Simon joined Shopify in 2013 after a story about switching from an iPhone to an old Nokia phone appeared in the New York Times. At Shopify, he worked on infrastructure during a period of rapid growth, containerization with Docker, physical hardware planning, sharding, and multiple datacenters. He describes a sharding cutover completed a week before Black Friday. When a large Redis server failed, the team split out the workloads that had been treated as a single key-value store. He also helped define how services should behave when components such as session storage fail, rather than allowing one dependency failure to bring down everything.
Failure simulation exposed database and framework bugs before production did
To test dependency failures, Simon experimented with entering a process through GDB and closing its database file descriptor. That approach was too unusual to ship in CI, but it uncovered many problems in Rails and database drivers. He then built Toxyroxy, a proxy between applications and databases that could make a database slow, take it down, simulate corruption, or trigger other failure modes through an API. Tests could run real application actions, such as loading a page or completing checkout, while the sessions table was unavailable. This revealed issues that were difficult to see during a production outage, when teams are focused on restoring service.
Napkin math replaced weak infrastructure benchmarks with first-principles checks
Simon maintained a GitHub table of system numbers, including DRAM bandwidth, S3 latency, NVMe and EBS bandwidth, and the cost of memory and storage. He used these figures to question benchmarks that did not match what the hardware should achieve. For a search query, he would estimate the matching data size, list intersections, memory bandwidth, and expected latency, then investigate the gap between that estimate and the benchmark. He gives a similar example with MySQL writes: a one-millisecond fsync appears to limit a system to a thousand writes per second, until batching explains how a small machine can reach 10,000 writes per second.
Turbopuffer started as a simple answer to expensive vector storage
Three things pushed Simon toward Turbopuffer: a difficult search project at Shopify, the napkin-math work, and repeated exposure to companies that needed cheaper search for AI applications. Readwise had a recommendation system that worked well, but running it for all users would have cost about $30,000 per month while the rest of its infrastructure cost about $5,000. Simon then calculated whether vectors could live in S3 with clustering and organized files. He spent the summer of 2023 trying to reach the latency he wanted, released the product in October, and began with a simple design rather than a fully developed database architecture.
The first Turbopuffer design traded sophistication for cheap, durable storage
S3 offered durability and low storage cost, but a 256 or 512 kilobyte object had a P99 latency of around 200 milliseconds. Simon says systems built on S3 must limit round trips because a search may require many requests and can quickly encounter tail latency. The initial design clustered vectors, stored clusters in files, kept cluster centroids in another file, and searched by downloading the centroids before fetching the nearest clusters. Simon added an Nginx reverse-proxy cache in front of S3, initially running the whole system on one server. He released it as a SaaS project and planned to improve the infrastructure if someone actually used it.
Cursor became the first customer because Turbopuffer matched its unit economics
Cursor contacted Simon after he announced Turbopuffer on Twitter. Its vector data had been kept in memory, while the company wanted active codebases to stay fast and less-active data to sit in cheaper storage. Simon visited Cursor in San Francisco and helped diagnose a Postgres problem involving autovacuum and inefficient scans. That work built enough trust for Cursor to try the database. Simon and Justine migrated the workload and reduced Cursor's bill by 95%, matching the pricing promise they had made. Cursor was willing to take the risk of relying on a very small vendor because the technical and financial case was clear.
"I think I'm a very pragmatic person. I didn't get buried. I barely read any of the literature on LSM."26:48
Who should watch
You are building a database or search system and need practical guidance on storage economics, tail latency, caching, and failure testing.
You are deciding whether to raise venture capital and want a candid framework based on R&D, growth, employee liquidity, partnerships, or acquisitions.
You run a remote engineering company and want an example of optional in-person gatherings that does not require everyone to travel regularly.
