Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)
Description
This fireside chat between Gergely Orosz and Simon Eskildsen explores the technical journey and engineering philosophy behind the database company Turbopuffer. Video Timestamps 0:00 Introduction and Simon’s early history with computers 3:02 The International Olympiad in Informatics and early competitive programming 4:13 How Simon was recruited by Shopify while still in high school 8:46 Engineering challenges and scaling infrastructure at Shopify 14:56 Decision to leave Shopify and the creation of the "napkin math" project 20:40 The origin and technical motivations behind Turbopuffer 24:46 Design challenges of building a database on top of S3 28:41 Cursor becoming the first major customer 35:36 The meeting with Jensen Huang and Nvidia’s push for GPUs 39:01 The competitive reality of cloud infrastructure and CPU scarcity 43:06 Philosophical perspective on venture capital and funding 51:45 Building a remote-first culture with the "campfire" concept Quotes (19:49) "Because you batch. So an f-sync happens on usually a 4K... it's not intuitive. It's actually—I got caught—I just got obsessed with this question." (30:33) "Yeah, you could do a million vectors for a dollar. And before that, I think the cheapest was maybe $100 per million for something that actually worked." (36:56) "[Jensen Huang] said, 'Judging by your slide, maybe you should [pivot into vapes].'" (43:53) "I promised Cursor that Justine and I could get their bill to 4K a month... that's the pricing we ship with." (49:54) "The third reason to raise capital is for the founder's ego... I wish that it was more talked about because you're diluting all of your employees when you do it." ## Speakers ### Gergely Orosz Author / Founder, The Pragmatic Engineer · The Pragmatic Engineer [X/Twitter](https://twitter.com/gergelyorosz) · [LinkedIn](https://www.linkedin.com/in/gergelyorosz/) · [Website](https://pragmaticengineer.com) Software engineer, engineering leader, and author of The Software Engineer's Guidebook
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: Turbopuffer was built by applying first-principles performance and cost modeling to vector search: keep durable data cheaply in object storage, use compute and cache selectively, and validate demand with a deliberately simple but reliable product before scaling the organization or capital base.
- Why it matters: The interview contains reusable patterns for AI-agent retrieval infrastructure, cost-aware systems design, resilience testing, capacity planning, technical founder-led sales, and disciplined company building.
- Best use: Use it as a technical-founder operating case study: extract its S3-backed retrieval architecture, napkin-math discipline, failure-testing approach, and infrastructure-capacity implications for agent and AI systems.
Executive Summary
Simon Eskildsen describes a career shaped by self-directed systems learning at Shopify, where he worked through scaling, sharding, multi-datacenter operations, cache failures, and database reliability. His core engineering habit is to keep peeling back abstractions until he can estimate what a system should cost and how fast it should run from hardware and network fundamentals. He argues that benchmarks alone are not an adequate basis for infrastructure decisions: when a measured result conflicts with first-principles expectations, teams should identify the hidden architectural trade-off, bad query plan, distributed-tail-latency effect, or implementation defect.
That discipline became Turbopuffer. Eskildsen encountered recurring cases where vector-search economics did not work: at Readwise, a recommendation/search workload was projected to cost roughly $30,000 per month versus about $5,000 for the company’s entire existing infrastructure. He built an object-storage-backed vector database around the premise that most vectors do not need to reside permanently in expensive DRAM. The initial system clustered vectors, stored clusters and centroids as S3 objects, selected nearby clusters at query time, and cached hot objects. The central technical constraint was controlling S3 tail latency and minimizing serial object-store round trips.
The company’s first major customer, Cursor, came from shipping an unusually bare-bones but durable MVP publicly. Cursor adopted Turbopuffer after Eskildsen visited in person, helped diagnose unrelated Postgres autovacuum/query-path issues, established technical trust, and committed to sharply better economics. Turbopuffer reportedly reduced Cursor’s initial vector-storage bill by 95%, illustrating a sales motion in which deep operational competence and an economic guarantee mattered more than conventional enterprise maturity.
The latter portion broadens into operating lessons. Eskildsen warns that CPU availability is becoming a material AI constraint as reinforcement-learning environments and deployed agents consume general-purpose compute, NVMe, DRAM, and power—not only GPUs. He also presents a disciplined capital framework: raise for R&D, growth, employee liquidity, strategic partnership, or M&A, but avoid raising for founder status. Turbopuffer remains remote while deliberately creating optional in-person density through twice-yearly offsites, ad hoc "campfires," and incentives for customer-facing or public technical work.
Key Takeaways
- Claim: Use first-principles "napkin math" to challenge infrastructure benchmarks and expose the actual source of poor performance or cost. | Evidence: Eskildsen maintained a GitHub table and flashcards covering roughly 50 variables such as DRAM, NVMe, EBS and S3 bandwidth, latency, and pricing. For a search workload, he would estimate posting-list size, memory bandwidth, cores, and expected query time; if a benchmark said 10 seconds where the calculation suggested 10 milliseconds, he treated that discrepancy as an investigation target rather than accepting the benchmark. | Implication: For Ken’s agent and retrieval systems, require every major storage, vector DB, model-routing, or orchestration decision to include a back-of-the-envelope latency, throughput, and unit-cost model alongside vendor benchmarks. | Caveat: The speaker explicitly acknowledges that the modeler can be wrong; the point is not that estimates replace measurement, but that a large mismatch should force explanation.
- Claim: Reliability testing should simulate real dependency failures beneath the application abstraction, rather than merely mocking them. | Evidence: At Shopify, Eskildsen initially used GDB to attach to processes and close database file descriptors, exposing failures across the actual connection stack. He then created Toxiproxy, a pass-through L4 proxy that could make a dependency unavailable, slow, or failure-prone through an API; Shopify used it to test behavior such as checkout flows when sessions or MySQL were down. It reportedly uncovered tens of issues in Rails and MySQL drivers that normal ecosystem tests had missed. | Implication: Build chaos/failure tests for agent control planes and tool integrations at real connection boundaries: lost credentials, unavailable vector stores, slow APIs, dropped database connections, partial tool outages, and degraded session stores should yield intentional fallback behavior rather than total workflow failure. | Caveat: The original GDB-based approach was intentionally extreme and was not shipped in CI; Toxiproxy was the practical mechanism that made the failure matrix repeatable.
- Claim: Object storage can make vector retrieval economically viable when the architecture minimizes tail-latency-sensitive round trips and keeps only hot data in faster tiers. | Evidence: Turbopuffer’s original design clustered vectors, wrote cluster files plus centroid metadata to S3, downloaded centroids, selected the nearest clusters, and fetched those clusters for search. Eskildsen cites roughly 200 ms P99 latency for a 256–512 KB S3 object, making a multi-level tree traversal with sequential fetches unacceptably slow. The first cache was simply NGINX in front of S3; Turbopuffer’s early public claim was one million vectors for about $1, versus an estimated prior market floor near $100 per million. | Implication: For large agent memory, codebase retrieval, document embeddings, and long-tail knowledge stores, separate durability/capacity from hot-query serving. Model P99/P999 over the full fan-out path, not just a single object or median retrieval. | Caveat: The transcript describes the initial design and its rationale, not a complete current architecture or a universal replacement for memory-resident indexes. Workloads with strict latency guarantees, poor locality, or high write rates may require different tiering.
- Claim: A technically simple product can be safely launched early if its core durability invariants are sound and the team is prepared to operationalize it when demand appears. | Evidence: Turbopuffer launched as a single process in a Tmux session on a GCP node, with a reverse-proxy cache and some cache deletion implemented by shelling out and manipulating NGINX’s file cache. Eskildsen nevertheless considered the core reliable because committed writes went directly to object storage and data would survive shutting down all VMs. Cursor contacted him immediately after the public launch and became the first customer. | Implication: For new AI infrastructure products or internal agent platforms, identify the few non-negotiable invariants—data integrity, auth boundaries, auditability, recovery—and permit temporary simplicity elsewhere until real usage reveals which complexity is justified. | Caveat: This was not a recommendation to ship careless infrastructure: Eskildsen distinguishes operational immaturity from compromised data durability and explicitly relied on known invariants.
- Claim: Technical trust and concrete economic outcomes can overcome the usual risk of adopting a tiny infrastructure vendor. | Evidence: Cursor was Turbopuffer’s first customer despite Turbopuffer being a newly launched startup. Eskildsen flew from Canada to San Francisco, helped Cursor diagnose Postgres behavior involving insufficient autovacuum and undesirable heap versus index access patterns, and then helped migrate Cursor over one to two weeks. Turbopuffer reduced Cursor’s bill by 95%, from a promised target around $4,000 per month. | Implication: When selling or evaluating critical AI infrastructure, favor evidence of operator depth: can the vendor diagnose adjacent production problems, explain trade-offs, make a credible economic commitment, and personally support migration—not merely demonstrate a feature benchmark? | Caveat: The customer relationship was unusually high-conviction and founder-led; not every buyer can prudently make this concentration-risk bet.
- Claim: AI demand is creating a CPU, NVMe, DRAM, and power allocation problem in addition to the visible GPU shortage. | Evidence: Eskildsen argues that reinforcement learning requires large CPU fleets to run real environments such as search, grep, Bash, CAD, or other task simulators, while deployed agents also execute general-purpose workloads on CPUs. Turbopuffer works with cloud providers on available regions and machine allocations, and he says even larger customers can exhaust available capacity or require long-term allocation contracts. He highlights flexibility across machine SKUs as a resilience advantage. | Implication: Treat CPU-based agent execution, retrieval, sandboxing, tool environments, memory, and storage I/O as strategic capacity dependencies. Avoid architectures tied to one instance family, region, or cloud SKU; secure commitments before demand forces migration under pressure. | Caveat: This is the speaker’s market interpretation rather than quantified industry-wide capacity data; he explicitly avoids strong macro forecasting.
- Claim: Capital should be raised against an explicit operational purpose, not as a status signal, and profitability can preserve decision quality while conviction develops. | Evidence: Turbopuffer initially targeted a $700,000 raise to hire two engineers and accelerate R&D, while the founders had gone six months without salary and paid cloud bills themselves. It became profitable later that year. Eskildsen’s six stated reasons to raise are R&D, growth, founder ego, employee liquidity, strategic partnership, and M&A; he identifies ego as common and dangerous because it dilutes employees and shapes future equity upside. Turbopuffer’s later raise was for employee liquidity. | Implication: For Ken’s ventures and investments, demand a stated use-of-capital thesis with measurable milestones. Distinguish funding needed to accelerate a validated bottleneck from financing that mainly changes external perception. | Caveat: The framework is opinionated and does not address every valid financing scenario, such as capital-intensive defensibility or defensive balance-sheet needs.
Detailed Brief
Shopify as the systems-training ground
- Claims: High-growth SaaS forces repeated annual capacity planning and exposes application-layer design issues that ultimately surface in stateful systems and databases.; Simplicity tends to age better than elaborate software designs, particularly when teams operate a system over many years rather than only build its first version.
- Evidence: Shopify was growing approximately 120–140% year over year during Eskildsen’s early tenure, requiring preparations for increasingly severe Black Friday traffic while physical hardware capacity had to be ordered in advance.; Its scaling work included database sharding, multiple data centers, cache decomposition after a poorly understood 128 GB Redis server failed, and a service/component matrix defining intended degradation behavior.
- Caveats: The discussion is retrospective and does not provide Shopify’s current architecture or operational metrics.; The examples emphasize infrastructure-heavy SaaS; they may not transfer directly to lower-scale application teams.
- Implications: Designing explicit degraded-mode behavior is a first-class state-management practice, not an afterthought for incident response.; Long-tenured infrastructure operators often have useful intuition because they have observed which abstractions and operational workarounds survive repeated scale events.
Remote culture designed for optional, high-density contact
- Claims: A distributed company does not have to choose between fully asynchronous isolation and mandatory office attendance.; Turbopuffer uses voluntary social and customer-facing gatherings to create in-person collaboration without penalizing employees who prefer stable home-based work.
- Evidence: The company holds twice-yearly full-team offsites, including events in Banff and Mexico City.; A "campfire" is an ad hoc gathering around a location or event—such as a San Francisco conference week—where teammates can join customer dinners and shared work.; Employees can earn a "TurboCredit" for activities such as conference talks, blog posts, or substantial conference/customer engagement; it funds a business-class upgrade on a future flight.
- Caveats: The model’s effectiveness likely depends on a small, highly motivated team and may become harder to administer consistently at much larger scale.
- Implications: Remote operating models can use lightweight incentives and event-based coordination to create voluntary in-person density, while preserving autonomy for employees with family, location, or focus-work constraints.
Notable Concepts & Terms
- Napkin math: Eskildsen’s first-principles method for estimating feasible latency, throughput, and cost from hardware, storage, networking, and algorithmic work before accepting benchmarks.
- Toxiproxy: A proxy created at Shopify to inject network and dependency failures into real application paths, enabling CI tests for failure modes that mocks do not capture.
- P99/P999 design: The principle that systems involving fan-out or multiple serial requests must be designed against tail latency, because several object-store calls rapidly make median metrics irrelevant.
- Object-storage-backed vector search: Turbopuffer’s central storage-tiering premise: durable, cheap S3/object storage can hold long-tail vector data while caching and selective retrieval support query performance.
- Autovacuum: Postgres maintenance process referenced in Cursor’s early operational issue; insufficient vacuuming can lead to poor access paths and performance degradation.
- Angel engineering: Eskildsen’s post-Shopify practice of joining friends’ startups as an engineer in exchange for vesting equity, used to gain cross-company exposure and observe recurring problems.
- Campfires: Turbopuffer’s voluntary local gatherings that let a remote team form temporary in-person clusters around customer meetings, conferences, or other travel.
- TurboCredits: An internal incentive that rewards public technical contributions or customer-facing conference work with a business-class flight upgrade, encouraging optional team connection.
Operator Notes / Why Ken Should Care
- Create a mandatory architecture worksheet for retrieval and agent-memory systems: data volume, active versus cold working set, storage tier, request fan-out, P99/P999 path latency, CPU/NVMe/DRAM requirements, and unit economics per tenant or agent run.
- Add dependency-degradation tests to the agent platform roadmap using real network-level fault injection, beginning with vector store, session/state store, model provider, tool API, and credential-service failures.
- Review cloud capacity exposure across CPU, NVMe, DRAM, region, and instance family; identify components that cannot move across SKUs or regions and prioritize portability before allocation scarcity becomes an incident.
- For vendor diligence, add a production-operator interview or live troubleshooting exercise to evaluate whether an infrastructure provider can reason through real failure modes beyond product marketing.
- Adopt an explicit financing memo template that names the exact reason for a raise, the milestones it funds, and the alternative if the capital is not raised.
Source/Metadata
- Title: Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)
- Transcript words: 12162
- Duration seconds: 3389
- Timestamp note: No usable timestamps or chapter markers were present in the supplied transcript.
Transcript
It's great to be here. Today with me here, I'm Gergay, author of The Pragmatic Engineer, and I'm excited to have a chat with Simon Erickson, founder, CEO of Turbo Puffer, a very technical CEO, and we're going to have a pretty technical discussion. But before we jump into it, Simon, I wanted to ask, where did you fall in love with computers? Through PowerPoint. PowerPoint. I don't know if any of you know this, but in PowerPoint, you can make the diagrams and stuff, and when you click them, go to another slide. That becomes Turing complete real quick, right? You can create very complicated, convoluted games, and then, at some point, you make it through the Microsoft Office suite, and you discover FrontPage. Do you remember FrontPage? Yeah, I remember FrontPage. It was supposed to eliminate the need for all and any FrontPage developers. Exactly. And it only worked in Internet Explorer. I remember a heartbreak I had one day when someone opened a website I created in Firefox, and it just was all over the place. And then one day, I accidentally clicked the HTML thing in FrontPage, and it just showed all of this stuff that I couldn't make sense of. And I just started looking at it, and then going online and finding little snippets that you could add in to make the cursor change and all of these different things. And then it just escalated from there. Then you upgrade to Dreamweaver, and now you're coding. And then you're like, well, how do you make the pages dynamically? You learn PHP. And then, for me, I exhausted the Internet on Danish-language programming advice. Mm-hmm. And I was around 11 or 12. And so I just went and got addicted to World of Warcraft for four years. But that gets you really, really good at English. So you start hacking, get into deeper. Now, the logical step would have been to just go to university and learn properly about this stuff. But that's not what you did, did you? I just started just, then I learned video games, then I learned English, and then this massive arsenal of the web. Now it would be very interesting, because the LLMs would just speak Danish to me, and you wouldn't have hit the wall like I did. So that would have been very interesting. Maybe I would have been better at programming. That would have been nice. And then, yeah, I just started picking up jobs and things like that throughout high school. And when I was in high school as well, I got exposed to this thing called the International Olympiad in Informatics. Mm-hmm. You heard of this thing? Yeah. And I had an internet friend, and she lived in Australia, and she was on the Australian team. And she told me, oh, there's probably something for the Danish team as well, but I had never heard about it before. And so I found it on some little mysterious website, and then applied, and then solved these programming problems that look very different from the HTML and PHP things that I'd solved until then. Or it's like the algorithmic-ish programs. Exactly. It's like this is not actually the kind of problem you would see there, but I think it illustrates well the kind of problem that you might get, right? You could imagine something like, okay, here's N trucks. Here's M packages. The M packages have these dimensions. Give me which trucks, which packages should be in, right? And then do something optimal. That's an NP-complete problem. You can't solve that, but you could compete with everyone else in the competition of doing the best thing. Yeah. So it's these kinds of problems, right? Yeah. And so I started doing that in high school. I was working as well for a startup. And then Shopify found me while I was still in high school. And the whole Shopify found me, was it through your open source contributions? Was it something else? It was because I had written an article where I had dropped my iPhone and it was, the iPhones are a lot, there used to be a time where you drop your iPhone and you just knew it was over for the screen. Yeah. It doesn't really happen as much anymore. The screens have gotten a lot better. But back then it was like, yeah, one drop and it was dead. And you just couldn't use it anymore. And so I went back to one of these old Nokia brick phones. And this is back in 2013, and people hadn't really realized all the pernicious effects of smartphones at the time. And so I wrote this article about how, oh my God, I'm calling people, and I have my sense of direction back. And I wrote an article about it. And this article went on Hacker News briefly, and the New York Times decided to feature it. No way. Yeah. And so a lot of traffic was driven to it. And then some astute Shopify recruiter put it all together, and I had a call with them. And then I don't think they realized that I was still in high school. But I had a great call with them. They invited me on site to Ottawa, Canada. I had no idea what Ottawa, Canada, is. I think the email says something like, what's an Ottawa? I had no idea. And so I went there, and it was just like I walked into the building, and it just felt right. And so I interviewed with them and then said, well, I got to finish high school first. And then I moved to Canada to work at Shopify. Yeah. In 2013. Yeah. I think that's a legit excuse for not even worrying about college and university. But it crossed your mind. It did. I thought I was doing a gap year. I thought, okay, I'm going to go work at Shopify for a year, and then I'll probably go back and do it. But I was very insecure at the time about the fact that I hadn't studied computer science, and my only exposure had been all the IOI competitions. It was a pretty good crash course in a lot of computer science. And if nothing else, it had really taught me that you can just sit down and read a paper and just figure it out if you spend enough time on it. So I did that repeatedly. And in my first year at Shopify, every time I heard something that I didn't know what it was, I noted it down on a piece of paper. And then I went home, and then that evening, I would just read about it. Because I felt insecure that if someone mentions TCP, surely they know exactly what's in the three-way handshake and how TLS is layered on top, and they've looked at Wireshark and all of that. I don't think that's true, but that's what I thought. Yeah. So I went and did that for everything that I encountered. So that was a really good crash course. And then very quickly it became clear that I just want to continue doing this. I don't want to go somewhere else and then come back to this, because I felt like I'd already found what I wanted to do. So it sounds like it was a pretty good combination of you just having this very natural insecurity. You're young, you know you don't have the education that everyone else has, and inside the company that's just doing pretty cutting-edge stuff, even at the time. Even today, right? They're leading. And so you just kept self-teaching yourself, just catching up and going. And do I understand that you just went deep in every concept that you understood? You didn't just try to understand that surface level, but go as deep as you can, search on the internet, buy books, whatever that is. I think it was just that I wanted to keep learning how computers work. And I think that this is something that I now look for when we interview engineers, that you can't help yourself but trying to peel back the layers. And for me, that ended up with the infrastructure layer. That was the people closest to the metal at Shopify. And I would just always sit next to them at lunch, because I was working on the product side, but I couldn't help myself. I just wanted to learn what it was when they were talking about a reverse proxy. I'm like, why is it reverse? I still can't answer that. I mean, okay. What's in reverse? Because it's a proxy, right? I don't know. I don't know. It's like an inverted index. What's inverted? It's a terrible name anyway. Yeah. I mean, it's still better when you get the NAT, NAT tables, the lookups, some of those things. But yeah, I hear you. There's some weird names with this. And for me, that ended up with the infrastructure layer. That was the people closest to the metal at Shopify. And I would just always sit next to them at lunch because I was working on the product side, but I just couldn't help myself. I just wanted to learn what it was when they were talking about a reverse proxy. I'm like, why is it reverse? I still can't answer that. Okay. Well, what's in reverse? Because it's a proxy, right? I don't know. I don't know. It's an inverted index. What's inverted? It's a terrible name anyway. Yeah. It's still better when you get the NAT, NAT tables, the lookups, some of those things. But yeah, I hear you. There's some weird names with this. But at Shopify, what were some of the hard engineering challenges, engineering challenges, outages, learnings that defined you that were also fun at the time or interesting to learn, but would have been hard to get elsewhere? Yeah. So I think it was in the 2010s, there's a bunch of SaaS companies that scale really quickly. And I felt so fortunate to have a front row seat to that. And so I ended up on the infrastructure team. And this was back in 13, 14. And Docker was coming out, and so we were containerizing everything. And every single year, we had to, the growth rates of SaaS sometimes seem quaint in comparison to the growth rates of companies today. But it was a company that was growing at 120, 140% year over year. And so every year we were just preparing for a Black Friday that was going to be a lot worse than the last. And this is back in the day of buying physical hardware, right? We have to place an order at a particular point in time and do some interpolation based on that. And the software also had to scale. And when you're scaling most software, a lot of the application layer problems end up back at the database layer. And so I just naturally found myself at this layer between Rails and the databases. Shopify didn't, at the time at least, contribute many patches to the databases themselves, but mostly just spent time orchestrating. So we were doing sharding because, as my dear boss Camillo used to say, you can't cache writes. So there's a fundamental point where you have to move beyond a single shard. So I joined around the time they did the sharding, and I think they did the cutover a week before Black Friday, which is mind-blowing. But it worked. And then the subsequent years, we worked on things like going into multiple data centers. We also had this big mysterious Redis server that was 128 gigabytes of RAM, which was a lot at the time. Today it's not that much. And no one really knew what was in it. And then it went down one day, and people were like, well, that's super terrifying. Because people had just been treating it as this KV store. And so we started splitting it out. We did all this stuff around making sure that if you go visit a Shopify store and the thing that stores your sessions is down, the right behavior is not just for the entirety of everything to be down. But that's kind of the default failure mode, right? You're not going to rescue all of that unless you're in a programming language that really forces that decision. So we did things like build this matrix out of, okay, well, this service, when this component is down, should act this way. And I found myself writing the test suite for a bunch of that. And then I was like, okay, well, we can't just mock all of this. And so I came up with this idea at the time of, oh, what we're going to do is we're just going to shell out to GDB, attach it to the process, and then close the file descriptor to the database to simulate, deep through the entire layer, that the database fails. That was a little crazy, and we never shipped that on CI, but it did uncover a massive amount of issues in Rails to be upstream and things like that around handling failures at the connection layer. So then I moved on to create this proxy called Toxy Proxy. And have you heard of this before? No, no. Yeah, Toxy Proxy is just a layer seven proxy that sits in between you and, well, layer four, but in between you and the databases. So you basically have this proxy and then MySQL, whatever, doesn't speak the protocol. But then you can do an API call, say take the database down, make it slow. And over time it also added layer seven things like do a bunch of failures. This way you're not mocking the low-level drivers, but you're testing the drivers and their failure handling as well. So then this entire matrix could be implemented in CI. So basically the proxy was just a really thin layer that was pass-through, but you built the functionality to simulate problems of database or things like data corruption or whatever you wanted to do. So you could just do it in there, and then anything that built on top of it. But then, oh yeah, and then everyone had to call this proxy, or it needs to be in a layer. Exactly. So you could do my, toxiproxy.mySQL.down and then pass it a lambda of what you wanted to do. Like get this page, do a checkout, whatever, with the sessions table down. And this just uncovered tens of issues in the MySQL driver, in Rails. It's just like no one in the ecosystem had been testing for this. And it was very difficult to see this in prod, right, because when MySQL is down, you're focused on just getting it back up and not what the application actually could have done. Yeah, it's interesting. Of course, we're going to talk a bit more about databases, obviously, but just thinking about how a lot of the problems, or some of the most gnarly problems in large systems, are always to do with state. And I never connected until now that state is usually, there's a database. If there's no database, if you have stateless services, you still have problems, you have nodes going down, you have corruption, whatever, but it's usually more isolated. But basically, if we have state, we typically have databases. If we have databases, and if you can simulate these problems, suddenly you can predict a lot of things. So the problem with state, oftentimes, is it's really hard to simulate problems happening ahead of time unless they happen. So did you, it sounds like you had pretty good success with. Yeah, I think, to my knowledge, it's still running in the CI system of Shopify today. I don't know if anyone in the crowd is from Shopify, but I'm pretty sure that it still does. And so we wrote all these tests against it to implement all of these different failure conditions. And it worked out great. So you spent eight years in total at Shopify. So starting from, all right, just a gap year. It just went on a year, a year, and another year. At what point did you think about leaving, and why? And what was your decision framework? It sounds like you were on Epic running out. Even today, Shopify is doing wonderful. It's probably doing even way better than that growth kind of kept on. So I'm sure there would have been an argument to stay and stay on the rocket ship. Yeah, so I spent eight years there from 13 to 21. And I think there just came a point where I wanted to see something different. Again, I'd been inside of Shopify since I was 18 years old, right? I'd seen one other startup in high school. I was like, if I want to learn more about computers and learn faster, it might be time to inject some novelty into dysfunction. And so I left in 21. And I'd worked on so many different parts of the infrastructure, like caching. Me and Justine, who's now my co-founder, we wrote the entire storefront for Shopify, which powered almost 100% of traffic 18 months after we embarked on it. We've worked on running Shopify in multiple data centers. We've worked on so many database scaling projects, caching, all of these different things, right? A lot of the scalability came from the Kardashians launching lots of products on Shopify, which would force a lot of traffic. But that's eventually how I left. And so when I left, I didn't really know what I wanted to do. And so I left in 21. And I'd worked on so many different parts of the infrastructure: caching, me and Justine, who's now my co-founder, we wrote the entire storefront for Shopify, which powered almost 100% of traffic 18 months after we embarked on it. We've worked on running Shopify in multiple data centers. We've worked on so many database scaling projects, caching, all of these different things, right? A lot of the scalability came from the Kardashians launching lots of products on Shopify, which would force a lot of traffic. But that's eventually how I left. And so, when I left, I didn't really know what I wanted to do. And so one of the projects I had while I was at Shopify was this napkin math project. Have you seen this? Napkin math? No. No. So napkin math was essentially just this table that I maintain on GitHub of how much bandwidth can you drive to DRAM? What does a round trip to S3 cost, and how long does it take? How much bandwidth can you drive to an NVMe SSD? How much bandwidth can you drive to an EBS volume? Just a collection of probably 50 of these numbers, and then a Rust script that generates them all. What all these things cost? What does a gigabyte of memory cost? Two dollars. What does a gigabyte of S3 cost? Two cents. What does a gigabyte of this cost? Ten cents, right? What does it cost on spot? What does it cost on a three-year commit? I had a massive table and then created flashcards for almost every single cell, so I know all these numbers. And this was a project I started taking on at Shopify because I found myself in this role a lot where I would go in and review a project, right? So some product team would be like, okay, we gotta build this thing. So we gotta build this infrastructure to support the feature. And a lot of the time they would say, okay, well, we've gone and benchmarked it on database A. But the benchmarks are not very good, so we're gonna go with database B. And I hate benchmarks so much because that's not a satisfying answer to me. To me, it's like, this does not jive with my intuition. Database A that you're saying takes 10 seconds to do this should take 10 milliseconds if you do the napkin math, right? If it's a search query, right? It's like, okay, you're searching for three terms. Each term has this many documents that match it. That's this many megabytes. We intersect this many lists. You have DRAM bandwidth on multiple cores of 100 gigabytes per second. This should take 10 milliseconds. You tell me the benchmark takes 10 seconds. One of us is wrong. Either there's a gap in my understanding, which is very likely, or you benchmarked the wrong thing. And in some ways, some reasons, right, it's like, okay, you've done a benchmark. You didn't realize that your benchmark is doing a distributed query across 100 different nodes. And so, of course, the P99 is gonna be really, really high, right, unless you've cut that off, or that means it's not going to be. You might have made some different set of trade-offs. So I just found myself in these discussions repeatedly where people were making infrastructure decisions based on poor benchmarks. And so I needed some ammo to go in and just be like, okay, we can just do the calculation right here. Because I was always doing these little demos or writing little prototype scripts to demonstrate this. But it was just the argument of here's how a BG works. This is how many pages we have to visit. This is what a random SSD read takes. It takes one millisecond. You have to visit a thousand, blah, blah, blah, blah, blah, blah. And then present it back and see, this is the difference to your query. Well, is the query plan correct? Is there a bug in MySQL? Do we have bad disks? What's the discrepancy here? And I just got caught with that bug. And so, after I left Shabaab, I was just writing a lot of articles about this. I was just like, well, how long should this query take? And then one hypothesis I had at some point is like, okay, well, how many writes per second can MySQL do? Well, shouldn't the amount of writes per second that MySQL does equal the amount of fsyncs that you can do per second? That makes sense, right? Every time you do a write, you fsync to persist to disk. So, how many fsyncs can you do per second? Well, an fsync takes one millisecond. So, you do a thousand writes per second. Well, that doesn't really match up. I feel like a database can do more than a thousand writes per second. Why can it do that? So, that was one of those things where I tested, and it's like, okay, well, MySQL on a little dinky box could do 10,000 writes per second. Well, how is that possible? And now you would just ask... How is it possible? Because you batch. So an fsync happens on usually a 4K... Yeah. Right? But that's not intuitive. Actually, I got caught. It was probably some 24-hour period where I just got obsessed with this question. Whereas, you're writing the BPF traces and all of that to do all of this. This is pre-LLM, so it took forever. And then I found out that every fsync was much larger than I would have inferred. Yeah. Like, oh, it's batching. You go into the code and you read it, and then you found some obscure article by... It's always someone in a central German town that's written some article about how some intricacy of MySQL works and a patch that they did to... It's like the entire internet runs on small towns in Bavaria, I'm convinced. Yeah. And then you decided to start Turbo Puffer. Yeah. How did you decide? Did you know what you wanted to build, or was it more like I want to build something, something databases? Because you were clearly very into databases. You've done an awesome job benchmarking what are the theoretical limits. You are very familiar with this. This probably became, you know, a world expert in this niche. And then how... Did you want to go into databases again? I think it was... There's three things that came to a head. The last project that I worked on at Shopify was Search, and I didn't have a good time. What did you use back there? I don't... We don't need to name names of other database companies, but it was one of the traditional search companies that a lot of different companies run. And it was just very difficult to get it to do what I did. And I was just like, the projects that touched that database just... I couldn't get them to perform at the napkin math. And there's no query planner, and I couldn't figure out why it wasn't there. And sometimes it tracked, and then sometimes it really didn't track at all. And so I tried to learn as much as I could to figure out and start reading the source code of it. And I couldn't get it to track very often. It was very difficult to operate. And so that was in the back of my head. I never thought I would touch that again. Then the second ingredient was the napkin math project. Because it gave me a lot of facility with all of these napkin math numbers of what might be achievable with the machine if you utilized it perfectly. Properly, yeah. And then the third one was that, doing this, leaving Shopify in 21, having spent eight years there, and during that time, I did this... I called it angel engineering. So I joined my friends' companies, and then I just vested equity instead of just investing or something like that. And because I wanted to have my fingers in it. I wanted to see what else was out there. That's why I left. And this problem kept coming up again and again and again and again, right? ChatGPT came out in 2022, and I was working with a company then. And they wanted to connect a bunch of documents to AI. And that's when the context windows were really small. So you had to reach for search very quickly. So it's like a few kilobytes. It was eight kilobytes or four kilobytes depending on the model. It was very, very small. So you had to reach for search very quickly, right? Yeah. And so I worked with them, and I created a little recommendation engine. I called it angel engineering. So I joined my friends' companies, and then I just vested equity instead of just investing or something like that. Because I wanted to have my fingers in it. I wanted to see what else was out there. That's why I left. And this problem kept coming up again, again, and again, and again, right? ChatGPT came out in 2022, and I was working with a company then. And they wanted to connect a bunch of documents to AI. And that's when the context windows were really small. So you had to reach for search very quickly. So it's a few kilobytes. It was eight kilobytes or four kilobytes, depending on the model. It was very, very small. So you had to reach for search very quickly, right? Yeah. And so I worked with them, and I was... I created a little recommendation engine. And the recommendation engine was actually quite good. I found out that one of the co-founder's wife was pregnant through the recommendations that I was getting when I was running it on his feed. It was... Weird, but yeah. It was recommending. Yeah. It was just, he was reading about, I didn't get permission. I just, I don't think anyone expected it to be good enough. And just, okay, this thing is working. And then I ran the back-of-the-envelope math on what it would cost to do this for everyone, all the users. This is a company called Readwise. So it's articles that you save and then search later. And it was going to cost 30 grand a month. And this was a company, it's a bootstrap Canadian company. They spend about five, at the time they were spending about 5K a month on all the other infrastructure combined. So it just, it didn't, fundamentally in a company, if you're doing an investment, you have to run some gross margin on top of whatever you're paying, right? And it just didn't line up. And so we just didn't ship it. And I worked on, I tuned autovacuum on Postgres or something like that, which is a good pastime. And then I just couldn't stop thinking about why it was so expensive to store all of these vectors that we were using for the recommendations. And I just sat and did the napkin math one day of, can we just use it all to an S3 and do some clustering and then organize the files in a way? And it's, maybe you could build that. And then one day I just kind of said, fuck it, and did it. And sat down and started to write it out. And I spent the summer of '23 just hammering my head against the wall, trying to find an approach where I can get the latency that I wanted. Because the problem with S3 is it has really good durability, but latency, we're talking hundreds of milliseconds, right? Yes, the P99 on a 256 or 512 kilobyte object on S3 is around 200 milliseconds. And you're saying P99 because when you're talking large scale, you want to care about the P99, right? Yeah, I think when you're just. That's why we're not talking about P50. When you're designing a system, you want to optimize for the P99. And especially because when you're designing a system on S3, generally in every round trip, you're not doing one request. You're often doing lots of requests, right? You're going to have the P99 real quick. Exactly. So it's like if you're navigating a tree on S3, right? It's like, okay, you get the upper layer of the tree, 200 milliseconds. You get another layer of the tree, 200 milliseconds. You get a bunch of leaves of the tree in 200 milliseconds. So in aggregate, you want to look at the P99, probably even the P999, to design the system properly. Because you will need to minimize the number of round trips that you had to make. So I just sat and sketched that out and tried a bunch of different approaches. And then finally in July of '23, I got something end to end that seemed to work. And then rewrote it probably twice. And then released it in October of '23 based on just that summer of working through it. And then you built it on top of S3 because, I guess, durability and all of it, and just really good. How did you make it fast? We didn't in the beginning, or I didn't in the beginning. It was just me at the time. That came later, yeah. And it was really, it was a project. It was not a company. It was to satisfy a curiosity. I did not set out to do this like, I'm going to go raise $10 million and do it. I barely knew what a VC was. I just had to do this thing. And I was so focused on doing it. It was so clear to me that if I wasn't going to do it, someone else was going to do it. And I just became fully obsessed that summer with it. And so the first version was the simplest possible thing. I think I'm a very pragmatic person. I didn't get buried. I barely read any of the literature on LSM. I read a bunch of it, got the basic idea. Barely implemented that because that would have taken too much time. It was the simplest possible version of what it could be. Really what you have to imagine is that the simplest way you could do this is you run some clustering algorithm on the vectors. You get the clusters. And then you put the clusters in files. The files are called cluster one, cluster two, cluster three. And then you have another file called centroids of the clusters. And then you do the search by downloading centroids, looking at the centroids, and then downloading the N closest clusters. There's a few optimizations around merging some clusters that were adjacent in files and so on, just to control some costs and some performance. But that was basically it. And then getting that to scale. That was the first version. And then how do we make it fast? Well, I didn't even implement a caching layer. I just put the reverse proxy in front of S3 with NGINX, and then had it cached. But you do know what a reverse proxy is. I do know what it is. I just still don't know what the reverse is about. But anyway, the reverse proxy reverses the performance in this case, maybe that's what it's about, by caching all of the S3 objects. Again, it was the simplest. It's like, I'm just going to put that in front. I knew how to configure NGINX. I've written more NGINX Lua than a lot of NGINX Lua. Very good software. Just had that cache in front. And then the way that I would do things like deleting in the cache was just shell out to XRX and just remove things in the cache and reverse engineer the directory structure on NGINX. And that's what we shipped. And it was just running on a single server in a Tmux instance. And I was like, okay, let's see if anyone gives a shit. Yeah, so far, this is cool engineering and a cool side project and a bunch of novel ideas. And I think just some hardcore engineering. How did Cursor come into play? Because when I learned about TurboBuffer, I was talking with Cursor about how they built their backend, their database, how they scaled it. And they were telling me all these migrations and they were telling me, oh, yeah, so we are in Postgres, but it didn't. They did something else in Postgres, it didn't even work that well. They went to AWS Aurora, which is AWS managed service of Postgres, and it didn't work well, which is very surprising. And they're like, oh, yeah, and then we went to this thing called TurboBuffer, and it worked well. And I was like, what's TurboBuffer? And they said that you were one of their first customers. And this never computed to me. Cursor was already massive at that point. How did you meet the folks, and how did they become, were they the first customer, one of the first? They were the first customer. The first. The first. No. They reached out after I just launched on Twitter. I was like, hey, I built this thing. And frankly, it was like, hey, launched this thing. And to me, I was like, I am so sick of working on this. I've been working on this all summer. I don't know if anyone cares. I only want to work on this if anyone cares. Let's put it on Twitter. Again, single Tmux instance on a core node somewhere in GCP. And I was like, what's TurboBuffer? And they're like, oh, yeah, TurboBuffer. I think they said that we were one of their first customers. And this never computed to me. Cursor was already massive at that point. How did you meet the folks, and how did they become, were they the first customer, one of the first? They were the first customer. The first. The first. No. They reached out after I just launched on Twitter. I was like, hey, I built this thing. And frankly, it was like, hey, launch this thing. And to me, I was like, I am so sick of working on this. I was like, I've been working on this all summer. I don't know if anyone cares. I only want to work on this if anyone cares. Let's put it on Twitter. Again, single Tmux instance on a core node somewhere in GCP. I was like, if someone goes to prod, I'll set it up properly on multiple, and I'll just block on that. But let's see if anyone cares. It was the MVP of MVP. Anyone who's actually worked in the internals on databases would never have had, would have had too much pride to ship anything like that. And I've worked on, I was just releasing it like a SaaS project. Why can't you work on a database like it's SaaS? I don't know. It's like, if anyone uses it, we'll do it properly. I know how to run software with a lot of nines. But it was not a proper LSM. It was very, very, it was the simplest version of what it could be. And then I released it on Twitter. I was like, yeah, you could do a million vectors for a dollar. And before that, I think the cheapest was maybe $100 per million for something that actually worked. Yeah. And I knew it was reliable, right? I knew I had these invariants, like if you shut down all the VMs, no data is lost, all the writes are committed directly to all of us. It has all the same invariants it had today. And Cursor reached out. And knowing them now, I'm sure at the time Cursor was maybe eight people. And knowing the founders now, I am sure that they had sat at the dinner table one day and were like, the unit economics of what we have right now, where all the vectors are in DRAM, are not working. Why hasn't anyone built it where we can put it in S3, and the actual code bases that are actively being used, we can put in memory? And everything else just sits in object storage, and then we just hot load it in and out of the cache. Yeah. Makes so much sense, right? You open the code base, a few seconds, and it's in RAM. And then the queries are as fast as anything else. It made so much sense. So at the time, they were, if you look at some of Amman, one of the co-founder's early tweets, he talks about using S3 for KV caching and things like that. And then the data is still in fact, which barely anyone is still doing even though the economics... Like, oh, Godmuckel, yeah, price-wise. Yeah, and it's very uncommon, and I think it will happen, right? But they were ahead of their time. And they, I think they were, I don't know if they were thinking of building it themselves. I think that's quite likely. And they found Turbo Puffer, and it just perfectly pattern matched into that. Again, I don't know if this dinner conversation happened or if this was just inside Arvid's head. Well, half fast now. But it pattern matched something. And so we exchanged a bunch of emails, and then something compelled, I didn't know anything about B2B sales. Now I love B2B sales. I didn't know anything. I was just like, I just want to help them because they had some unit economics that didn't line up. So I just went to San Francisco, right? I live in Canada. I went to San Francisco, and I showed up at the office. And when I showed up at the office, they were having some Postgres problem that they were discussing. Yeah, the A-W-S-A-R-O-R problems, yes. Yeah, early on. And I was like, oh, do you guys have PG Analyze? And they said, oh, no, we don't. I was like, okay, let's get that going, right? Let's look at it. And it was the same thing as it always is with Postgres, which is auto vacuum hadn't run enough. And so they had all of these, like going to heap when they should be doing index scans and blah, blah, blah. So we were talking about all of that. And so I was just helping them, right? It was like my database genes just kicked in. And I think this built enough trust with them that, okay, well, maybe if he knows how to help us with the database, maybe he also would know how to build one. And at this time, I'd also approached who I thought was the best engineer who ever worked at Shopify, my co-founder Justine. And she'd come on, and the first thing that she did was remove the reverse proxy NGINX cache with a file-based cache. Just the direct cache, which again, great. The S3 thing worked. And so she was online. She was starting to work on it. And Cursor then that night was like, okay, well, we're going to migrate. And so they migrated everything over the course of a week or two after that. But Cursor was a small company back then, right? Yeah. And they were just in the beginning of their massive rapid growth. Exactly. And I told them that I was going to reduce their bill by 95%. And I did. Like we did. Justine and I did. They came on, and their last bill with their previous vendor and the first bill with us, it was 95% lower. Yeah. And you're nice for not seeing vendors, but I can see vendors. I just talk to them, and it's in the deep dive about Cursor. It was, it was, it was Aurora specifically. So, This was, this was not, this was not Postgres. No, this was a, Oh, it was a different one, but it's probably still in the write-up where we don't need to name names, but yeah, but they were, the reason they went there is reliability. And I think that reliability was their main, main, main, main point. I'm sure the unit of commerce would have been there, but yeah, this was. And then what Swala told me is he said, look, there's a few things that we did they should never ever do. And he said that one of them, you should never ever bet your business on a tiny startup where you are their only or biggest customer, except for Turbo Puffer. And he said, I love, love those guys. So I guess it just comes to show that even in your case, to me, what the story shows us is you can do things when you build high-quality things and you're pushing for things. Good things can happen. And on the other side of Cursor, when you're a startup, it's okay to take sometimes irrational risks when you have conviction. And it sounds to me that you gave them conviction by showing up in person, by helping them, by showing that you know yourself. You've suddenly brought in your 10-ish or eight years of Shopify experience and your curiosity, and they probably took a risk because of that, not because you were some random vendor. They probably would have never done that. So fast forward today, Turbo Puffer is now a lot bigger, you're working on some cool things, but you have this very interesting business where, for you, CPUs are important, right? You run on mostly CPUs. And you told me a story yesterday that you met Jensen, and Jensen, he really wanted to sell you on GPUs. Can you tell me how that meeting went? Yeah, Jensen Huang, right? Yeah. I'd never met Jensen before. We were at an event at NVIDIA, and we were just doing presentations. This is a big HQ, super impressive. Yeah, exactly. They invited a couple of companies to go and talk about our businesses and how we can partner with NVIDIA and so on. And I don't know. I was like, I think I was in a goofy mood that day. And so I went up on stage and I said, hey, I'm Simon from Turbo Puffer. And yeah, if you're wondering about the name, it's like if everything goes south, we can always pivot into vapes. I was kind of nervous, and this is what I said. And then he said back to me. And then who was in the room? Was it Jensen? Was it a direct report? It was Jensen, and then I don't know if it's just 50 direct reports or it was like, you know. It was Jensen and then a bunch of the NVIDIA leadership, right? We were at an event at NVIDIA, and we were doing presentations. This is a big HQ, super impressive. Yeah, exactly. They invited a couple of companies to go and talk about our businesses and how we can partner with NVIDIA and so on. And I don't know. I think I was in a goofy mood that day. And so I went up on stage and I said, hey, I'm Simon from Turbo Puffer. And yeah, if you're wondering about the name, it's if everything goes south, we can always pivot into vapes. I was nervous. And this is what I said. And then he said back to me. And then who was in the room? Was it Jensen? Was it a direct report? It was Jensen, and then I don't know if it's just 50 direct reports or it was, you know. It was Jensen and then a bunch of the NVIDIA leadership, right? Because you go there and then you talk about that and you find opportunities to partner and work together, right? And so I said, yeah, so plan B could be that we could pivot into vapes. And then he said, I was already nervous. He said, judging by your slide, maybe you should. No, he did not. I didn't know what to say back to that. So I said, well, Jensen, do you vape? He didn't answer the question. Someone on the team wrote to the whole company, Turbo Puffer company, Simon just asked Jensen if he vapes. And then this is a great start, right? And then the team had talked to me beforehand. It was like, Simon, we've got to make sure we don't say the C word. We can't say CPUs. I just couldn't stop talking about CPUs. I was like, AVX 512 is so sick. We love SIMD, and there's so many CPUs. They're so easy to get. It's just the riot in CPU land. I think I stopped short of saying I'm so glad I don't need GPUs. But I couldn't stop talking about CPUs. Yeah. And so Jensen took an interest in that. Yeah. So, who knows? I'm sure you made a memorable version. Maybe he made it his mission now to, at some point, get you guys onto GPUs. But speaking of CPUs, can you tell me a bit what you're seeing inside of the hyperscale, the cloud providers? You're now on AWS, you're in GCP, you're on Azure. What I would think naively is there's a GPU shortage. And when I talk with inference companies, and AI labs, they're just getting whatever they can do. I would think getting CPUs should be easy. Is it? No. It's not anymore. Why? What's happening? Can you tell us about the dynamics on the why and what you've learned? Yeah. So, I think that GPUs will probably continue to be scarce. I don't know, maybe there's going to be some surplus. I refuse to speculate too much about the macro. But I think as RL is becoming a very, very large amount of the workloads, that needs a lot of CPUs. So, the labs are sucking up a lot of CPUs because you need CPUs to be like, okay, we need to teach this model how to search. We need to teach it how to use grep. We need to teach it how to boot up bash. It needs to run real things and learn from that. It takes a lot of CPU. And so, I think RL is consuming a lot of CPU. And then also, all of the agents are running on CPUs, right? They need to do all kinds of very general-purpose things on a CPU. And so, as the demand curve is shifting to the right and it's becoming more and more applied, and that feeds back into RL, by the way, right? Because as things become more applied, it's like, oh, the models are not that good at CAD or shipbuilding. I don't know. And then you have to spin up even more RL environments to do that. I think that's what we're seeing. And so, we're on the other end of that, needing these CPUs. We need a lot of NVMe SSDs as well. And a lot of this right now is tied up in DRAM, right? Where you need a lot of that also for the GPU servers. But I would assume that it gets a lot worse before it gets a lot better on the CPU side. And I think even the big companies are fighting amongst each other, right, to get the allocations. And even we, we're selling to companies that we also fight for CPU with and against, right? It's really difficult. And so, you write things to try to make sure you get these CPUs as fast as possible. Yeah. And yesterday, I was at a dinner that you hosted with your team where you actually have a bunch of TurboPuffer customers. A bunch of them are AI labs or AI startups. But a lot of them, one of them, Reflection, had massive amount of footprint. And they were telling me that they're in a situation where they cannot buy more. When it comes to GPUs or CPUs, they max out. They have the longest contracts that are possible. And I didn't realize how competitive it is in the cloud when you go beyond a small fish to a medium size or even a large fish. That now it's interesting. So now you have this, and even you're having this kind of fight behind the scenes that is maybe not as visible. Exactly. And, I mean, you work with the clouds, right? You work with them to talk about which regions have CPU, which regions are getting, it comes down to power, right? Of, okay, well, where is the power, which is generally where they're going to ship the new CPUs. And so, we have to work with some of our biggest customers on that. So, these are real constraints, right, that are making their way to us. We're just very fortunate that it's very easy for us to run lots of TurboPuffer clusters, because all we need are a few CPUs and NVMe SSDs, and then S3. And then we're in a good place. But there's lots of changes that we can make even to the architecture to try to protect from a lot of this. Now, I'd rather spend that engineering effort on other things. Yeah. But we are very, very good at using a lot of very different SKUs, right? So, we don't need everything to be a particular CPU or instance type. We can run with many different types of machine types. And a few meaning that's the fancy name for the different machine types. Yes, exactly, right? Like, C4D or IAG or whatever they're called. What's your favorite one? We really like right now the C4s on GCP. GCP, yeah. The Z4Ds are also performing really well. And now that we've done a bunch of optimizations to them, those are really, really great machine types. We really like those. And then the ARM C4As as well on GCP. We like those. But I think that in general, when you're small, it's very easy to suck up a bunch of, but at Shopify, I was also part of deciding ahead of BFCM, right, a few months out, you have to tell the cloud providers how much you're intending to use. Do commits on all of that, right? The clouds are not infinite as they seem when you're small. Now, one way, of course, to get infrastructure and also credibility is venture capital. If you raise $100 million, a billion dollars, some of your customers just raised $2 billion. Actually, I talked with them yesterday. It gives you credibility. It gives you cash. You can pay for this thing. Your specific TurboPuffer's relationship to venture capital seems very interesting. I never heard you announce a raise until maybe just very recently. Can you tell me how you, and you told me that when you started this thing, you didn't think too much outside of the world. You're not a big fan of the world outside of just building some cool stuff. How did you think about venture capital? And how do you think about raising? Because again, I feel you have a very fresh and different perspective than what is typical inside of Silicon Valley. Yeah, so I think to understand how I think about capital, you have to go back to the beginning of TurboPuffer, right, where I promised Cursor that Justine and I could get their bill to $4K a month. And this was based on some very rough napkin math on, okay, if TurboPuffer was a better implementation than it currently is, then it should cost this much. And that's the pricing we ship with. And that's what we guaranteed Cursor. And that's the first thing that we had in the future. But the software was not that good. You're not a big fan of the world outside of just building some cool stuff. How did you think about venture capital? And how do you think about raising? Because again, I feel you have a very fresh and different perspective than what is typical inside Silicon Valley. Yeah, so I think to understand how I think about capital, you have to go back to the beginning of TurboPuffer, where I promised Cursor that Justine and I could get their bill to $4K a month. And this was based on some very rough napkin math on, okay, if TurboPuffer was a better implementation than it currently is, then it should cost this much. And that's the pricing we shipped with. And that's what we guaranteed Cursor. And that's the first thing that we had in the future. But the software was not that good. It was very reliable, but it was very simple, right? And that's a core engineering principle of mine, is simplicity above everything. You and I have talked before about how software ages well and some of the advantages of having long tenures inside companies. You had a long tenure at Uber, I had a long tenure at Shopify, so you see simplicity just almost always wins. And at the time, I was not convinced whether this was a venture-scale opportunity. Because I understood that if you take venture capital, no matter how many smiles there are in the room, everyone's expecting that you have to earn a big return on that on some timeline that makes sense to everyone involved. And everyone involved are pension funds in Canada. It is a whole stack of people that need to. So, at the time, I was like, I don't know if this could be a billion-dollar company. I didn't know that in the very, very beginning. It wasn't completely clear to me. It felt like a very niche product, right, to build this particular search engine. And that was completely fine with me. So it was fine. And so then I just looked at the Cursor bill and I looked at my GCP bill, which is what we started on. And it's like a dumb Danish person who's just like, okay, this number should just be lower than the other number. Yeah. That's just, I don't think I'd spent enough time in San Francisco. Because I think the money over here works a little bit differently. That's all I knew. You were doing business 101. As long as you're making a profit, you're good, right? Yeah. I'm not kidding in this exaggeration that it was just like, that just made sense to me. That Justine and I were just going to go optimize this until these numbers were roughly equal. And maybe if we could get some other workloads, we could start paying ourselves. But that was very much the philosophy at the time. Because I didn't know if I could go raise a bunch of money. I didn't know anyone who had the money. I didn't have any relationships. You were an absolute outsider to the world. I was an outsider. I was an outsider squared, right? I grew up in Aarhus, Denmark. And I then moved to Ottawa, Canada. So I'm an outsider to Canada. And in Canada, I'm an outsider to San Francisco. So I was just thinking about this from first principles. Like, venture capital, you need this return. You need it on this timeline. I don't know if I can deliver that yet. I would need more data to decide that. Because I kind of want to keep working on this. And now I have to get to this point for it to not be a failure. In January, there was a person that I was at IOI with in 2012 and 2013. And his name is Boyan. And he was on the Northern Macedonian team at IOI. And he was really good. He was so good that the North Macedonian team called him God. I don't know why, but that was what he went by. And he was very good. Grew up. And I really wanted to work with Boyan. But I couldn't afford to work with Boyan. And he was very much like, this is what I can live off. I want to build this data. This is what it can be. But at this point, Justine and I hadn't taken a salary for six months. And we'd already spent tens of thousands of dollars on GCP bills and all of that. And I was like, I don't think we can do it. And so I had met one individual in Silicon Valley. His name is Lockie. And I ended up just calling him and saying, hey, I want to learn a little bit faster here. Can we raise like 700K? That's what I wanted to raise. So it's just like, I want to have two engineers for the rest of the year. Justine and I still don't need to be paid. And then a little bit of buffer room. This is what I need. And if this doesn't have PMF and isn't a big opportunity by the end of the year, I don't think we're going to bother. And we'll just shut the whole thing down. And we won't have taken a dime. We'll return everything to you. I think there was the first time you heard anyone say it like that. And I told some other VCs that at the time. And that was terrifying to them. I think to someone on the West Coast, this sounds like you have low ambition or something like that. And to me, it just came from, when I don't know how to play a game, I just play with open cards. Like, this is how I see it. And so it was very clear to us that we wanted to do this. But it also became clear to us that we didn't want to keep working on this unless it could become big. And we were starting to develop conviction that this could actually become really, really big. And so we did that and hired Boyan, and then became profitable later that year. And then just continued to hire. And then, to raise more money, you need, there's six reasons to raise capital. The first reason to raise capital is to fund R&D. Mm-hmm. That was the reason that we raised capital in January. Because we funded R&D with a lot of our own opportunity cost in not taking a salary and then paying the bills ourselves. But we wanted to learn a little bit faster. And so we hired Boyan and Morgan as the first engineers. And then the second reason to raise capital is to fund growth. You've built something and you want to tell the world about it and you want to spend more capital to do that. The third reason to raise capital is for the founder's ego. It's very popular. I appreciate the honesty. It's very popular. Very, very popular, right? Big numbers, lots of press. 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. You are setting a certain price for future employees and their upside. For some people it can become a status game. And that's not what it's about. We're here to build a big business together, and this is not a reason to raise money. But I do think that it happens. The fourth reason to raise capital is to reward your employees, right? You're on a very long journey and you want to work with the best people in the world. And by definition, there's not that many best people in the world. So you want to reward them. That was the reason that we took more capital in December, was to allow the employees to liquidate some of their equity instead of waiting for some event like an IPO or something further out. The fifth reason to raise is for a strategic partnership. There are strategic partnerships that have been made in this city that have made companies. And the sixth reason to raise would be doing M&A or something like that. But you have to be very honest about what reason you are raising in those six. The first reason we raised was one and the second reason we raised was four. Which ones, the first reason was? R&D. R&D. And the second reason was? To provide liquidity to the employees. Yep. Yep. I think it's a nice and healthy way. So you want to reward them. That was the reason that we took more capital in December, was to allow the employees to liquidate some of their equity. Instead of waiting for some event, like an IPO or something further out. The fifth reason to raise is for a strategic partnership. There are strategic partnerships that have been made in this city that have made companies. And the sixth reason to raise would be doing M&A or something like that. But you have to be very honest about what reason you are raising in those six. First reason we raised was one, and second reason we raised was four. Which one was the first reason we raised for? R and D. R and D. And the second reason was? To provide liquidity to the employees. Yep. Yep. I think it's a nice and healthy way. And I think, yeah, the ego part we don't talk about, and the identity, and especially the closer you are to tech ecosystems where a lot of people are raising, it will be part of it. As closing, I want to ask you about the way you have a remote culture. These days I'm seeing it, especially for companies that do anything with AI, whether that be building AI infra or just AI products. A lot of them prefer in person, having an HQ, oftentimes in SF or wherever your headquarters may be, London or somewhere else. Because these companies often find that they have faster iteration. It's just fewer layers cut in between. And of course, speed is very, very important. You have started full remote, and you're still full remote. How is it working? And what kind of quirks or Turbo Puffer ways have you found to make this work better? Yeah, I think the company started in 23, sort of on the cusp of COVID, where a lot of companies were just remote. The Shopify infra team was remote since the very beginning. Because it was very difficult to get them all to move to Ottawa. And so it was natural to me. It was like, okay, I think there are maybe two cities where you can build a database company fast. And that's San Francisco and maybe New York. There are maybe other cities, right? But that's where it's been done. Yep. And so if you don't want to do that, I think you have to go all in on some distributed model. And so we've tried to figure out what that distributed model means for Turbo Puffer. It doesn't mean the absence of in person. We get everyone together twice a year in some location. Earlier this year we were in Banff, right? And then we were in Mexico City, and so on. So that's not that uncommon. But one of the things that we've been trying to do is we have this concept called campfires. And the concept of the campfire is that when a couple of people just randomly congregate in a place, you call it a campfire and you encourage as many people as you want to come and join. So for example, this week is a Turbo Puffer campfire in San Francisco, because I'm here for this conference and a bunch of other things. And so everyone is invited to come. We're going to go meet customers, right? We're going to put on dinners for our customers and things like that. And we just make a thing out of it and spend time together. And we encourage everyone to come. We've also gone to the extent now of wanting to encourage that, but not everyone needs to go to the campfire all the time. Some people just want to lock in and hack until 10. And that's great. We have people that just make it to the off-sites twice a year, and otherwise they're home, they're with their families, and they don't spend time on an airplane. Fantastic. That is completely compatible with this model. And there are other people at the company who are on a plane probably every two weeks. We had someone the other day where they saw a campfire happening in New York, and everyone was dialing in from a meeting room in New York. And she had so much FOMO that she took an Uber straight to the airport in Ottawa and flew to New York to hang out with the team, right? And I think that's fantastic. We've also introduced these things where if you do a conference talk or a blog post or something like that at Turbo Puffer, or something a bit extracurricular, we give you a TurboCredit. And a TurboCredit allows you to upgrade your next flight to business class, which again encourages spending time together with the team. And now, I mean, TurboCredit is probably going to take on a life of its own. Someone was talking about doing a central bank and doing interest rates on the TurboCredits, and doing a betting market on the TurboCredit. And so this might take on a life of its own. And if you're at a conference like this, there are some of our engineers here who just want to interact with customers, and standing on an expo floor all day is quite taxing. And so if you do that for two days because you want to do it, you get a TurboCredit, right? And so it's just these fun little things that we try to do to encourage people to meet if they want to meet. Thank you. Well, in this session, what I found very interesting is TurboPuffer is, so many AI companies are using you as an infrastructure layer. But in this conversation, we managed to talk very little about AI and a lot more about engineering principles, pushing, being curious, and the human connection, how important it is for people to work together, to trust each other. So just thank you very much for that. So let's give a big round of applause for Simon. Thank you so much. This is great. Thank you. Um, but one of the things that we're, we, we've been trying to do is we have this concept called campfires. And the concept of the campfire is that when a couple of people just sort of randomly congregate in a place, you call it a campfire and you encourage as many people as you want to come and join. So for example, this week is a Turbo Puffer campfire in San Francisco, cause I'm here for this conference and a bunch of other things. And so everyone is invited to come. Like we're going to go meet customers, right? We're going to put on dinners for our customers and things like that. And we just make a thing out of it and, and spend time together. And, uh, we encourage everyone to come. We've also gone to the extent now of, um, we want to encourage that, but not everyone, not everyone needs to go to the campfire all the time. Some people just want to, you know, lock in and hacks into 10. And that's great. We have people that just make it to the off sites twice a year and otherwise they're home, they're with their families and they don't, they don't spend time on an airplane. Um, fantastic. Like that is completely compatible with this model. And there are other people at the company who are on a plane probably every two weeks. Um, we had someone the other day where they saw a campfire happening in New York and everyone was dialing in from a meeting room in New York. And she had so much FOMO that she took an Uber straight to the airport in Ottawa and flew to, flew to New York to hang out with the team, right? And I think that's fantastic. Um, and we've also introduced these things where, um, if you, if you, uh, if you do a current conference talk or a blog post or something like that at TurboPuff or something a bit extracurricular, we give you a TurboCredit. And a TurboCredit allows you to upgrade your next flight to business class, which again encourages spending time together with the team. Um, and now, I mean, TurboCredit is probably going to take on a life on their own. Someone was talking about doing a central bank and doing interest rates on the TurboCredits, um, and doing a betting market on the TurboCredit. And so like this might take on its life on its own. Um, and, uh, you, you know, if you, um, if you're at a conference like this, there's some of the, our engineers here who are just want to interact with customers and be on like, and standing on a like expo floor all day is quite taxing. And so if you do that for two days, cause you want to do it, oh, you get a TurboCredit, right? And so it's just like these fun little things that we try to do to, to, to encourage people to meet if they want to meet. Thank you. Well, in this session, uh, what I found very interesting is TurboPuffer is, uh, so many AI companies are using you as an infrastructure layer. But in this conversation, we managed to talk very little about AI and a lot more about engineering principles, pushing, being curious and the human connection, how important it is for people to work together to trust each other. So just thank you very much for that. So let's give a big round of applause for Simon. Thank you so much. This is great. Thank you.