From "napkin math" to turbopuffer

The Pragmatic Engineer 55min 5 min #96
From "napkin math" to turbopuffer
Watch on YouTube

Summary

  • Simon Ericson, founder and CEO of Turbopuffer, traces his path from building games in PowerPoint and FrontPage as a child in Denmark to competitive programming (IOI), dropping out of a university track to join Shopify at 18, spending eight years scaling its infrastructure, then founding Turbopuffer — a vector search engine built on object storage that dramatically lowers cost by keeping hot data in memory and cold data in S3.

Early path to programming

  • Got hooked on computers through PowerPoint’s clickable diagrams (Turing-complete), then FrontPage, Dreamweaver, PHP, and eventually hit the limit of Danish-language programming resources at age 11–12.
  • Learned English through four years of World of Warcraft, which unlocked the global internet of technical knowledge.
  • Discovered the International Olympiad in Informatics (IOI) via an Australian internet friend; competed for Denmark in high school, solving algorithmic optimization problems (e.g., truck/package packing).
  • A Hacker News / New York Times feature on his 2013 blog post about switching from iPhone to a Nokia brick phone caught a Shopify recruiter’s attention; interviewed in Ottawa while still in high school and joined Shopify in 2013.

Eight years at Shopify (2013–2021)

  • Treated the first year as a “gap year” but stayed after realizing he’d found what he wanted to do; systematically self-studied every unknown concept (TCP, TLS, reverse proxies) each evening to close the gap with CS-educated peers.
  • Gravitated to the infrastructure layer — containerizing with Docker, preparing for Black Friday traffic spikes (120–140% YoY growth), buying physical hardware, and sharding MySQL because “you can’t cache writes.”
  • Worked on multi-data-center rollout, splitting a mysterious 128 GB Redis server that had become a single point of failure, and building a failure-mode matrix so session-store outages wouldn’t take down the whole storefront.
  • Created Toxiproxy, a Layer 4/7 proxy that sits between app and database and can inject latency, errors, corruption, or connection drops on command; enabled realistic failure testing in CI and uncovered dozens of bugs in Rails and the MySQL driver (still running in Shopify CI today).
  • Rewrote the storefront (with Justine, later co-founder) to handle ~100% of traffic 18 months in; worked on caching, database scaling, and Kardashian-driven traffic surges.
  • Left in 2021 to “inject novelty” and learn faster; did “angel engineering” (vesting equity by working at friends’ startups) while exploring what to build next.

The Napkin Math project

  • Maintained a GitHub table of ~50 hardware cost/performance numbers (DRAM bandwidth, S3 round-trip latency, NVMe vs EBS throughput, $/GB for memory/S3/spot/committed) and made flash cards for every cell.
  • Used it to challenge infrastructure decisions based on poor benchmarks: e.g., a search query benchmarked at 10 s should take ~10 ms given DRAM bandwidth and posting-list intersection math — the gap reveals either a misunderstanding or a bad benchmark.
  • Discovered MySQL could do 10k writes/sec on a small box despite fsync taking 1 ms (theoretical 1k/sec) because fsync batches many 4 KB pages; traced via BPF and obscure German blog posts.

Starting Turbopuffer (summer 2023)

  • Three catalysts: (1) painful experience with a traditional search engine at Shopify that couldn’t hit napkin-math performance; (2) the Napkin Math project gave intuition for what hardware could do; (3) while angel-engineering at Readwise (read-later app), built a recommendation engine that worked but would cost $30k/mo on existing vector DBs vs. $5k total infra budget — so it wasn’t shipped.
  • Obsessed over “why is storing vectors so expensive?”; did napkin math on clustering vectors, writing clusters to S3 objects, and searching by downloading centroids + nearest clusters.
  • S3 latency: P99 ~200 ms for 256–512 KB objects; tree traversals multiply round-trips, so system must minimize requests and design for P99/P999.
  • First version (July–Oct 2023): simplest possible clustering → files named cluster1, cluster2… + centroids file; search = download centroids → pick N closest clusters → download those files; JSON merging for cost/performance control; no custom cache layer — just Nginx reverse proxy caching S3 objects, with cache invalidation via xargs rm on Nginx’s cache directory.
  • Ran on a single 8-core T-Mox instance in GCP; launched on Twitter (“1M vectors for $1” vs. ~$100/M elsewhere) with full durability invariants (writes committed directly to S3, shut down VMs → no data loss).

Cursor becomes first customer

  • Cursor (then ~8 people) reached out after the Twitter launch; they had hit unit-economics wall with in-memory vectors (Aurora/Postgres) and had already discussed “why hasn’t anyone put cold vectors in S3?”
  • Simon flew to SF, helped them debug an Aurora autovacuum issue (sequential scans instead of index scans) — built trust.
  • Justine (co-founder) replaced Nginx cache with a direct file-based cache; Cursor migrated over 1–2 weeks; bill dropped 95% (from previous vendor’s last bill to Turbopuffer’s first bill).
  • Cursor’s Swallow later said: “Never bet your business on a tiny startup where you’re their only/biggest customer — except Turbopuffer.”

CPU scarcity in the cloud

  • GPUs stay scarce, but CPUs are now also scarce because: (1) RL workloads need massive CPU for environment simulation (teaching models to search, use tools, run Bash); (2) agents run general-purpose code on CPUs; (3) applied AI reveals gaps (CAD, shipbuilding) → more RL environments → more CPU demand.
  • Big labs and cloud customers fight for allocations; even Turbopuffer competes with its own customers for CPU.
  • Turbopuffer mitigates by being SKU-agnostic: runs on many instance types (GCP C4D, Z4D, C4A ARM) — only needs CPUs + NVMe + S3.
  • Works with cloud providers on regional power/CPU availability; power constraints drive where new silicon lands.

Meeting Jensen Huang

  • At an Nvidia partner event, Simon opened with: “If everything goes south we can pivot into vapes.” Jensen replied: “Judging by your slide, maybe you should.”
  • Simon, nervous, asked: “Jensen, do you vape?” (No answer.) Nvidia team Slacked: “Simon just asked Jensen if he vapes.”
  • Despite pre-event coaching to avoid the “C-word” (CPUs), Simon couldn’t stop praising AVX-512, SIMD, and CPU abundance — Jensen took interest.

VC philosophy: six reasons to raise

  1. Fund R&D — first raise (Jan 2024, ~$700k) to hire Boyan (IOI “God” from North Macedonian team) and Morgan; Simon/Justine had gone 6 months no salary, paid GCP bills personally.
  2. Fund growth — spend to tell the world.
  3. Founder ego — status, press, big numbers; dangerous, dilutes employees, sets high strike price; not a valid reason.
  4. Reward employees — second raise (Dec 2024) for employee liquidity (tender) so early team doesn’t wait for IPO.
  5. Strategic partnership — rare but can make companies.
  6. M&A — acquisitions.
  • Simon only raised for reasons 1 and 4; wants to keep “playing with open cards” and only continue if venture-scale conviction solidifies.

Remote culture: campfires & TurboCredits

  • Fully remote since 2023 (Shopify was remote-first); whole company meets twice/year (Berlin, Mexico City, etc.).
  • Campfires: ad-hoc co-location — when a few people land in a city, call it a campfire, invite anyone to join (customer dinners, hacking sessions). No obligation; some attend only offsites, others fly every two weeks.
  • TurboCredits: earn by giving conference talks, writing blog posts, staffing expo floors → upgrade next flight to business class. Evolving into internal economy (central bank, interest rates, betting markets).
  • Goal: encourage in-person connection if people want it, without mandating travel.
Back to The Pragmatic Engineer