▶ YouTube Summaries

• https://www.youtube.com/watch?v=h8TBLKyo7Rs
• Original title: From "napkin math" to turbopuffer

Gergely Orosz interviews Simon Eskildsen, founder and CEO of turbopuffer, on stage at AI Engineer's World Fair in San Francisco (July 2026). Eskildsen traces his path from a self-taught Danish teenager to eight years scaling infrastructure at Shopify, and then to building turbopuffer, a search/vector database that stores data cheaply on S3. The throughline is a first-principles habit he calls "napkin math": estimating from hardware limits what a system should cost and how fast it should run, and refusing to accept benchmarks that violate that intuition. The conversation deliberately stays off AI hype and instead dwells on engineering principles, curiosity, simplicity, an unusually cautious philosophy toward venture capital, and how to run a fully-remote company.

From PowerPoint to Shopify

Eskildsen fell into programming through PowerPoint animations, then Microsoft FrontPage (accidentally clicking "view HTML"), Dreamweaver, and PHP, hitting a wall when he exhausted Danish-language programming resources around age 11-12. World of Warcraft taught him English, which reopened the whole web. In high school he competed in the International Olympiad in Informatics (algorithmic problems like NP-complete packing), worked at a startup, and was found by a Shopify recruiter after an article he wrote about ditching his smartphone for a Nokia brick phone hit Hacker News and got featured by the New York Times. He moved to Ottawa in 2013 at 18, intending a gap year, and never went to university.

The insecurity that drove deep learning

Lacking a CS degree, Eskildsen felt insecure that colleagues surely understood things like the TCP three-way handshake in full detail (he suspects now that they didn't). So every time he heard a term he didn't know, he wrote it on a piece of paper and read about it that evening. The IOI had already taught him that you can sit down with a paper and figure anything out given enough time. This compulsion to "peel back the layers" pulled him toward the infrastructure team, closest to the metal, and is now the trait he looks for when interviewing engineers.

Infrastructure and toxiproxy at Shopify

On Shopify's infra team through the mid-2010s SaaS boom, he lived through Dockerizing everything and preparing each year for a Black Friday bigger than the last while ordering physical hardware ahead of time. Application-scaling problems consistently landed at the database layer; his boss Camilo's line "you can't cache writes" meant sharding was inevitable (the cutover reportedly happened a week before Black Friday). Because "state is where the gnarly problems live" and failures are hard to simulate before they happen, he built toxiproxy: a thin layer-4/7 proxy between the app and databases that can, via an API call, make a database slow, down, or corrupt. This let Shopify test driver and Rails failure handling in CI instead of mocking, uncovering tens of real bugs. He believes toxiproxy still runs in Shopify's CI today.

The napkin math project

After eight years (2013-2021) he left Shopify to inject novelty and learn faster. A side project became central: a GitHub table of ~50 hardware and cost numbers (DRAM bandwidth, S3 round-trip latency and cost, NVMe/EBS bandwidth, price per GB of memory vs S3, spot vs three-year commit), plus flashcards so he memorized every cell. It grew out of reviewing projects at Shopify where teams picked "database B" over "database A" on the strength of poor benchmarks. His objection: if the napkin math says a search query should take 10 ms and the benchmark says 10 seconds, one of them is wrong, usually the benchmark (e.g. unknowingly running a distributed query across 100 nodes, inflating P99). Napkin math gave him the "ammo" to reason about systems directly. A representative rabbit hole: MySQL should only manage ~1,000 writes/sec if each write is one fsync (1 ms each), yet a small box does 10,000, the answer is batching (fsync operates on ~4K pages), and the explanation lives in some obscure article "in a small town in Bavaria."

Starting turbopuffer

Three ingredients converged. First, his last Shopify project was search, using a traditional search engine he could never get to perform at napkin-math limits (no query planner, unpredictable behavior). Second, the napkin math project gave him deep intuition for what a perfectly-utilized machine could do. Third, "angel engineering" (joining friends' companies for equity) exposed him to the same problem repeatedly: at Readwise, connecting saved articles to early small-context LLMs required fast search over vectors, and his recommendation engine (good enough that it surfaced a co-founder's wife's pregnancy) would have cost $30K/month for a company spending $5K on all other infra. It didn't ship. He couldn't stop wondering why storing vectors was so expensive, did the napkin math on keeping everything in S3 with clustering, and in summer 2023 obsessively hammered on it. The hard part: S3 has great durability but ~200 ms P99 latency on a 256-512 KB object, and since navigating a tree means many sequential round-trips, you must design for P99 and minimize round-trips. He got something end-to-end working in July 2023 and released in October.

The deliberately simple MVP

The first version was the simplest possible thing: cluster the vectors, write each cluster to a file, keep a centroids file, and search by downloading centroids then the N closest clusters (plus a few merges to control cost). He barely read the LSM literature. For speed he didn't even write a caching layer, he put an nginx reverse proxy in front of S3 to cache objects, deleting cache entries by shelling out to rm and reverse-engineering nginx's directory layout, all on a single 8-core GCP node in a tmux session. His attitude: run a database like a SaaS project, if anyone actually cares, do it properly then. Core invariants held from day one, shut down all VMs and no committed data is lost, everything commits to object storage. He priced it at a million vectors for a dollar, versus roughly $100/million for anything that worked before.

How Cursor became the first customer

Cursor reached out after the Twitter launch and became turbopuffer's very first customer, when Cursor was maybe eight people. They had reasoned (Eskildsen imagines over a dinner) that keeping all vectors in DRAM had broken unit economics, and that actively-used codebases could live in RAM while everything else sat in S3 and got hot-loaded, turbopuffer pattern-matched exactly. Not knowing B2B sales, he simply flew from Canada to San Francisco and showed up. They were fighting an AWS Aurora Postgres problem; he diagnosed the classic autovacuum-not-running-enough issue (sequential scans instead of index scans) using pganalyze, which built enough trust that maybe someone who can fix a database can also build one. His co-founder Justine (whom he considers the best engineer he saw at Shopify, together they rewrote Shopify's storefront to carry ~100% of traffic) replaced the nginx cache with a direct file-based cache. Cursor migrated within a week or two, and their first turbopuffer bill was 95% lower than their previous vendor's. Cursor's advice, per Eskildsen: never bet your business on a tiny startup where you're the biggest customer, "except for these guys."

Asking Jensen if he vapes, and the CPU shortage

At an Nvidia HQ event where companies pitched partnership opportunities, a nervous Eskildsen joked on stage that if turbopuffer fails "we can always pivot into vapes." Jensen Huang shot back "judging by your slide, maybe you should," and Eskildsen blurted "well Jensen, do you vape?" (no answer). Warned by his team not to say "CPU," he then couldn't stop enthusing about CPUs, AVX-512, and SIMD. The substance: CPUs are now scarce in the cloud too. RL workloads consume huge amounts of CPU (teaching models to search, use tools, boot bash, run real environments), and agents themselves run on CPUs, so as demand shifts toward applied work it feeds back into more RL environments and more CPU demand. turbopuffer needs CPUs, NVMe SSDs, and S3, and even competes for capacity against its own customers (some large AI labs are fully maxed out on their longest possible contracts). It comes down to power and which regions get new capacity. turbopuffer's advantage is flexibility, it runs well across many machine SKUs (it likes GCP's C4, Z4D, and ARM C4A types) rather than needing one specific instance type.

A cautious philosophy toward venture capital

Eskildsen frames himself as "an outsider squared" (Aarhus to Ottawa to San Francisco) reasoning from first principles: VC money carries an implicit obligation to return a big multiple on a timeline that works for a whole stack of investors down to Canadian pension funds. Early on he wasn't sure turbopuffer was venture-scale, and simple "business 101" logic (make the GCP bill lower than the customer bill and you're fine) suited him. In January he raised just $700K from one investor (Locky) to hire two engineers (Boyan, an old IOI competitor the North Macedonian team called "God," plus Morgan) while he and Justine still took no salary, telling the VC bluntly that if there was no PMF by year end they'd shut down and return every dime. West Coast VCs found that terrifying and read it as low ambition; he sees it as playing with open cards when he doesn't know the game. They became profitable that year. He lays out six reasons to raise capital: (1) fund R&D, (2) fund growth, (3) founder ego (very popular, very dangerous, it dilutes employees and turns into a status game), (4) reward employees, (5) strategic partnership, (6) M&A. turbopuffer raised for reason 1 (R&D) and later reason 4 (letting employees liquidate equity without waiting for an IPO). His recurring principle throughout: simplicity above everything, and simple software almost always wins over long tenures.

Running a fully-remote company: campfires and turbo credits

turbopuffer started remote in 2023 and stays fully remote, reasoning that database companies are usually built in SF or New York, so if you don't do that you must go all-in on a distributed model. It isn't the absence of in-person: the whole company gathers twice a year (recently Bali and Mexico City). Between those, they run "campfires", whenever a few people happen to congregate somewhere, they make an event of it and invite anyone who wants to come (this SF conference week is a campfire, with customer dinners). Attendance is optional: some people only make the two offsites and otherwise stay home with family, others fly every couple of weeks, and one teammate got so much FOMO from a New York campfire that she Ubered to Ottawa airport and flew there to join. To encourage extracurricular effort and time together, doing a talk, blog post, or manning a conference booth earns a "turbo credit" that upgrades your next flight to business class, a joke system the team is now half-seriously proposing to run with a central bank, interest rates, and a betting market. Orosz closes by noting that although so many AI companies build on turbopuffer, the conversation was mostly about engineering principles, curiosity, and human connection rather than AI.