Simon Eskildsen

Simon Hørup Eskildsen is the co-founder and chief executive of turbopuffer, a search engine built around object storage. He wrote its first version and co-founded the company with Justine Li, with whom he had spent eight years scaling Shopify’s database and compute infrastructure. His work connects systems-performance estimates to product decisions: understanding what infrastructure should cost can make previously unaffordable features practical.

From Shopify’s infrastructure to turbopuffer

Eskildsen grew up in Aarhus, Denmark, and worked on Rails applications at the phone-support startup Relatel throughout high school. In 2012 and 2013, he represented Denmark at the International Olympiad in Informatics. He moved to Ottawa in 2013 to join Shopify, where he worked as a principal engineer and director across its infrastructure as the platform grew from roughly 1,000 to one million requests per second.

At Shopify, Eskildsen and Li worked closely on database and compute infrastructure, including the demands of flash sales and multi-tenancy. Years on the last-resort pager shaped their preference for operational simplicity: fewer stateful dependencies and systems that keep one customer’s workload from overwhelming another’s. Those lessons later informed turbopuffer’s storage architecture and its use of multi-tenancy and sharding from the outset.

After leaving Shopify in 2021, Eskildsen spent short stretches helping friends’ companies scale their infrastructure, including Replicate, Causal, Datafold, and Readwise. A problem at Readwise became the starting point for turbopuffer. In late 2022, while helping prepare Readwise Reader for launch, he wanted to add article recommendations and semantic search. Vector search across more than 100 million documents was projected to cost over $20,000 a month, compared with about $5,000 for the existing relational database. The team postponed the feature.

The decision stayed with him. Object storage had become widely available, NVMe drives had become faster and more affordable, and AI applications were asking search systems to retrieve more data. He began developing turbopuffer in 2023 and co-founded the company with Li that year. His account of its origins and design explains the ambition behind the architecture: bring retrieval costs down far enough that teams can build features they previously could not justify.

Estimating performance before building

Since 2019, Eskildsen has maintained Napkin Math, a collection of benchmarks, approximate performance and cost numbers, and techniques for reasoning about systems from first principles. The project helps engineers turn a broad question into a calculation they can inspect. To estimate the storage cost of logging for an application, for example, they can work through the size of a log line, the number produced each second, and the cost of storing that volume.

His Napkin Math newsletter gives readers problems to practise on: estimating Redis throughput, distinguishing MySQL transaction rates from filesystem synchronization rates, or predicting query latency when only some database pages are cached. The method starts with an approximate answer before writing code; measurements can then test the assumptions and reveal where the model breaks down.

Rounded numbers, explicit units, and a manageable set of assumptions make the reasoning usable. Eskildsen argues that first-principles thinking can help engineers move beyond incremental improvements toward changes of an order of magnitude. Turbopuffer applies that approach to the storage costs and performance requirements of search.

Designing search around its workload

• Use object storage as the source of truth. Turbopuffer durably commits writes to object storage and uses SSD and memory caches to accelerate queries. Its storage engine is designed around object storage, rather than moving only older data into a cheaper tier. That choice changes the engineering problem: storage capacity is inexpensive and throughput is high, but requests have substantial latency and individual writes carry costs. The query planner and storage engine therefore coordinate how much data to fetch with how many network round trips a query requires.

• Cache the active working set. Keeping every dataset warm can be wasteful when only some tenants are active at a given time. Turbopuffer accepts slower occasional cold queries in exchange for storing inactive data cheaply. Cursor, its first large customer, illustrated the fit: billions of vectors spread across millions of codebases, with only a subset being searched at once. Selective caching lets the system spend on the data being used instead of keeping every codebase in memory.

• Make recovery part of the storage design. With object storage holding the durable data, another node can serve a namespace after loading its data into cache. Turbopuffer routes traffic to consistent nodes to improve cache locality, but the architecture allows any node to serve any namespace. This carries forward Eskildsen and Li’s Shopify lesson that fewer stateful dependencies can simplify operation and improve reliability.

• Match infrastructure cost to product value. Eskildsen’s argument begins with what search applications need: responsive reads and high write throughput, often with more relaxed write latency and fewer transactional requirements than a relational database. Paying for storage characteristics the workload does not need can consume a product’s budget without improving its intended use. The Readwise experience gave that argument a concrete consequence—a desired feature left unbuilt.

Across Napkin Math and turbopuffer, Eskildsen asks what a system should cost and how fast it should be, given the hardware and the work it needs to perform. His educational work gives other engineers a way to reason through those questions; turbopuffer turns that reasoning into retrieval infrastructure for AI products.