{
  "video": {
    "id": "jQDXzEVHMSE",
    "title": "Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)",
    "duration": 3390,
    "upload_date": null,
    "channel": "AI Engineer",
    "source": "AI Engineer"
  },
  "analysis": {
    "video_id": "jQDXzEVHMSE",
    "title": "Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)",
    "one_liner": "Simon Eskildsen explains how obsessive \"napkin math\" — knowing what hardware should actually be capable of — let him build Turbopuffer, a vector search engine on S3 that cut Cursor's bill by 95%, starting from a single-instance MVP with an nginx cache in front of S3.",
    "summary": "Gergely Orosz interviews Turbopuffer founder/CEO Simon Eskildsen about the path from self-taught Danish teenager to eight years on Shopify infrastructure to founding an object-storage-native search database. The through-line is napkin math: Simon maintains a table of ~50 hardware/cost constants (DRAM bandwidth, S3 round-trip latency and cost, NVMe throughput) with flashcards, and uses first-principles calculation instead of benchmarks to decide whether a system is performing as it should. He recounts shipping a deliberately crude first version of Turbopuffer in October 2023, landing Cursor as first customer by flying to SF and debugging their Postgres autovacuum problem, and now fighting for CPU allocation in a market where RL training and agents are consuming general-purpose compute. He closes with a candid taxonomy of the six reasons to raise venture capital — including founder ego — and how Turbopuffer runs fully remote via \"campfires.\"",
    "key_points": [
      "Napkin math over benchmarks: Simon maintains a GitHub table of ~50 hardware and cost numbers (a GB of RAM ≈ $2, a GB of S3 ≈ 2 cents, DRAM bandwidth ~100 GB/s across cores, a random SSD read ~1ms) plus flashcards, and uses it to challenge teams choosing databases on bad benchmarks — his example: a search query benchmarked at 10 seconds that the math says should take 10 milliseconds.",
      "At Shopify (2013–2021, joined at 18 out of high school after a NYT-featured article about switching to a Nokia brick phone) he built Toxiproxy, a layer 4/7 proxy that sits between the app and databases so CI can simulate failures — it uncovered tens of failure-handling bugs in the MySQL driver and Rails; an earlier version shelled out to GDB to close the DB file descriptor inside the process.",
      "S3-native design forces you to optimize the P99, not the P50: the P99 on a 256–512KB S3 object is ~200ms, and since one query walks multiple tree levels you compound that — so the architecture is built to minimize round trips, and you should design against P99/P999.",
      "The first Turbopuffer was intentionally crude: cluster the vectors, write each cluster to a file (cluster1, cluster2…) plus a centroids file, fetch centroids then the N nearest clusters. No real LSM, no caching layer — just an nginx reverse proxy caching S3 objects, with cache eviction done by shelling out to rm against the reverse-engineered nginx directory structure, all on a single 8-core GCP instance. Launched October 2023 at $1 per million vectors when the cheapest working alternative was ~$100 per million.",
      "Cursor was the first customer, reaching out after the Twitter launch when they were ~8 people. Simon flew from Canada to their office, found them debugging Postgres, set up pganalyze and traced it to autovacuum not running enough — that trust preceded the migration. He promised a 95% bill reduction and a ~$4K/month bill; the first Turbopuffer bill was 95% below their last bill with the previous vendor.",
      "CPUs are now scarce, not just GPUs: RL training environments (teaching models to search, use git, boot bash) and agent workloads consume enormous general-purpose compute, and NVMe/DRAM supply is tied up in GPU servers. Turbopuffer survives by running across many machine SKUs — favorites are GCP C4, Z4D, and ARM C4A — and works with clouds on which regions have power and therefore new CPUs.",
      "Six reasons to raise capital, named explicitly: (1) fund R&D, (2) fund growth, (3) founder ego, (4) reward//provide liquidity to employees, (5) strategic partnership, (6) M&A. Turbopuffer's first raise was ~$700K in January for reason 1 — pitched with an offer to return the money and shut down if there was no PMF by year-end — and the December raise was reason 4.",
      "The motivating economics came from Readwise: a recommendation engine Simon built worked well but would have cost $30K/month at a bootstrapped company spending ~$5K/month on all other infrastructure combined, so it never shipped — which sent him down the path of putting vectors in S3."
    ],
    "takeaways": [
      "Build and memorize your own napkin-math table (latency, bandwidth, and $/GB for DRAM, NVMe, EBS, S3) so you can predict what a query should cost before you trust anyone's benchmark — when the benchmark and the math disagree, one of them is wrong and it's worth finding out which.",
      "Test failure handling at the connection layer, not with mocks: put a controllable proxy (like Toxiproxy) between your app and its databases so CI can exercise \"sessions table is down\" and \"database is slow\" against the real drivers.",
      "When designing on object storage, budget for P99/P999 per round trip (~200ms for a small S3 object) and architect to minimize the number of round trips rather than optimizing average-case latency.",
      "Ship the MVP-of-MVP even for infrastructure — a single instance, an nginx cache, no LSM tree — as long as the durability invariants are real (all writes committed to object storage, no data loss if every VM dies); pride about doing databases 'properly' is what stops you from finding out whether anyone cares.",
      "Be explicit about which of the six reasons you're raising for, and treat founder ego as a real and dangerous one because it dilutes employees and prices future hires' upside."
    ],
    "topics": [
      "vector-databases",
      "object-storage",
      "database-infrastructure",
      "performance-engineering",
      "napkin-math",
      "startups",
      "fundraising",
      "remote-work"
    ],
    "tools": [
      "Turbopuffer",
      "Shopify",
      "Cursor",
      "Amazon S3",
      "AWS Aurora",
      "PostgreSQL",
      "MySQL",
      "pganalyze",
      "nginx",
      "Toxiproxy",
      "Redis",
      "Rails",
      "Docker",
      "GDB",
      "GCP",
      "Azure",
      "Nvidia",
      "Readwise",
      "ChatGPT",
      "Reflection",
      "eBPF",
      "AVX-512"
    ],
    "quotes": [
      {
        "text": "and I hate benchmarks so much because that's not a satisfying answer to me",
        "at": "17:19",
        "url": "https://www.youtube.com/watch?v=jQDXzEVHMSE&t=1039s"
      },
      {
        "text": "one of us is wrong. Either there's a gap in my understanding, which is very likely, or you would benchmark the wrong thing.",
        "at": "18:02",
        "url": "https://www.youtube.com/watch?v=jQDXzEVHMSE&t=1082s"
      },
      {
        "text": "the MVP of MVP. Anyone who's actually worked in the internal on databases would never have had like would have had too much pride to ship anything like that.",
        "at": "30:02",
        "url": "https://www.youtube.com/watch?v=jQDXzEVHMSE&t=1802s"
      },
      {
        "text": "um and I think this is a very very dangerous reason to raise money. And I wish that it was more talked about because you're diluting all of your employees when you do it.",
        "at": "50:06",
        "url": "https://www.youtube.com/watch?v=jQDXzEVHMSE&t=3006s"
      }
    ],
    "words": 13456
  },
  "summary_url": "/#jQDXzEVHMSE",
  "transcript": {
    "html": "/transcripts/jQDXzEVHMSE.html",
    "txt": "/transcripts/jQDXzEVHMSE.txt",
    "vtt": "/transcripts/jQDXzEVHMSE.vtt"
  }
}