Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)

AI Engineer · 56 min · 714 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

  1. 00:01[music]
  2. 00:24All right.
  3. 00:26It's great to be here and today with me here I'm I'm Gerge, author of the pragmatic engineer and I'm excited to have a chat with Simon Ericson uh founder
  4. 00:38CEO of Turbopuffer 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?
  5. 00:52um through PowerPoint.
  6. 00:54PowerPoint you I don't know if any of you know this but in power well you probably know this but in PowerPoint right you can make the the diagrams and stuff when you click them
  7. 01:03go to another slide that becomes touring complete real quick right you can sort of you know create very complicated convoluted games and then at some point you know you make it through the Microsoft Office suite and you discover Front Page.
  8. 01:18Do you remember Front Page?
  9. 01:19Yeah, I remember Front Page.
  10. 01:20It it it was supposed to eliminate the need for all any front-end developers.
  11. 01:25Exactly.
  12. 01:26And it it only worked in Internet Explorer.
  13. 01:29I remember a heartbreak I had one day when someone opened a website I created in Firefox and it just it was it was all over the place.
  14. 01:36And then one day I accidentally clicked the HTML thing in front page and it just showed all of this stuff that I couldn't make sense of and it 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
  15. 01:51uh different things and then it just sort of escalated from there.
  16. 01:55Then you upgrade to Dreamweaver and now you're coding and then you're like well how do you make the pages dynamically?
  17. 02:01you learn PHP and then for me I exhausted the internet on Danish language programming advice.
  18. 02:09Mhm.
  19. 02:09Um and I was I was around 11 or 12 and so I just you know went and got addicted to World of Warcraft for four years but that gets you really really good at English.
  20. 02:19[laughter]
  21. 02:21So you kind of start hacking get into deeper.
  22. 02:24Now the logical step would have been to just you know go to university and learn properly about this stuff.
  23. 02:30But that's not what you did did you?
  24. 02:33I mean I just um I I started just I I mean you know then I learned video games then I learned English and then you know this like massive arsenal
  25. 02:44of the web.
  26. 02:45I now it'd be very interesting because the LLMs would just speak Danish to me and you could just you wouldn't have hit the wall like I did.
  27. 02:52Um, so that would have been very interesting.
  28. 02:54Maybe I would have been better at programming.
  29. 02:55That would have been nice.
  30. 02:57And then I Yeah.
  31. 02:58Then I just started picking up jobs and things like that throughout high school.
  32. 03:02And when I was in high school as well, I got exposed to this thing called the International Olympiad in Informatics.
  33. 03:07You heard of this thing?
  34. 03:08Yeah.
  35. 03:09Um, and I had a I had an internet friend and she lived in Australia and she was on the Australian team and she told there's probably something for the Danish team as well, but I had never I'd never heard about it before.
  36. 03:21And so I found it on some like 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
  37. 03:31were like the algorithmicalish programs.
  38. 03:34Exactly.
  39. 03:35It's sort of 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 is
  40. 03:42you could imagine something like okay here's like n trucks here's m packages the m packages have these dimensions give me which trucks which packages should be in right and then
  41. 03:55do something optimal like that's an npmplete problem you can't solve that but you could compete with everyone else in the competition of doing the best thing so it's these kinds of problems right
  42. 04:03um and so I started doing that.
  43. 04:04In high school, I was working um I was working as well um for a startup.
  44. 04:10Um and then I just Shopify found me while I was still in high school.
  45. 04:17And and the whole like Shopify found me, was it through your open source contributions?
  46. 04:20Was it was it something else?
  47. 04:23It was because I had written an article where I had I had I dropped my iPhone and it was you know the iPhones are a lot like there used to be a time right where you drop your iPhone and you just knew it was over for the screen.
  48. 04:37It doesn't really happen as much anymore like the screens have gotten a lot better but back then it was like yeah one drop and it was dead and it just couldn't use it anymore.
  49. 04:44And so I went back to one of these old Nokia brick phones.
  50. 04:47And this is back in 2013.
  51. 04:48And people hadn't really realized all the pernicious effects of smartphones at the time.
  52. 04:53And so I wrote this article about how oh my god I'm like calling people and I have my sense of direction back.
  53. 04:59Um and I wrote an article about it.
  54. 05:01And this article it went on hacker news briefly and it um New York Times decided to feature it.
  55. 05:07No way.
  56. 05:08Yeah.
  57. 05:08And so a lot of traffic was driven to it and then some astute Shopify recruiter put it all together and um and I had a call with them and then I don't think they realized that I was still in high school but
  58. 05:23um but I had a great call with them.
  59. 05:25They invited me on site to Ottawa, Canada.
  60. 05:28Um I had no idea what Ottawa Canada is.
  61. 05:30I think the email says something like what's an Ottawa?
  62. 05:33I had no idea.
  63. 05:34Um, and so I went there and it was just like walked into the building and it was just a just felt right.
  64. 05:42Um, and so I I I interviewed with them and then said, "Well, I got to finish high school first and then uh and then I moved to Canada uh to to to work at Shopify."
  65. 05:51Yeah.
  66. 05:51In 2013.
  67. 05:52Yeah.
  68. 05:53I think that's that's a like legit excuse for like not even worrying about college and and university.
  69. 05:59But I did it crossed your mind.
  70. 06:01It did.
  71. 06:01I thought I was going I thought I was doing a gap year.
  72. 06:04I thought I was like, "Okay, I'm gonna go work at Shopify for a year and then I'll probably go back and do but I would just 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 II competitions which is a pretty good crash course
  73. 06:19in 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."
  74. 06:28So I did I did that repeatedly and in my first year at Shopify I just every time I heard something that I didn't know what 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 like well if someone
  75. 06:41mentions mentions like TCP surely they know exactly what's in the three-way handshake and how TLS is like layered on top and they've looked at Wireshark and all of that.
  76. 06:49I don't think that's true but that's what I thought.
  77. 06:51So I went and did that for everything that I encountered.
  78. 06:54Um, so that was a really good crash course and then very quickly it became clear that well I just want to continue doing this.
  79. 06:59I don't want to go go somewhere else and then come back to this because I felt like I'd already found what I wanted to do.
  80. 07:06So it sounds sounds like it was a pretty good combination of like you just having this like very natural insecurity like you know you're young, you know, you don't have the education that everyone else has and inside a company that's just doing pretty like cutting edge stuff even at the time and even even to today, right?
  81. 07:20Like they're they're leading.
  82. 07:22So you just kept self-seing yourself like just catching up and go and then do I understand that you just went deep in every concept that you understood.
  83. 07:28You didn't like just like try to understand a surface level but like go as deep as you can search on the internet buy books whatever that is.
  84. 07:36I think it was just that I just wanted to know keep learning how computers work and I think that this is something that I now look for when we interview engineers is that you just you can't help yourself but trying to peel back the layers and for me that ended up with the infrastructure
  85. 07:52layer that was you know the people closest to the metal at at Shopify and I would just always sit next to them at lunch because I was working on the on the product side but I just I couldn't help myself.
  86. 08:03I was so I just wanted to learn what it was when they were talking about a reverse proxy.
  87. 08:07I'm like, why is it reverse?
  88. 08:09I I still can't answer that.
  89. 08:13[snorts]
  90. 08:15I I I mean, okay,
  91. 08:17[laughter]
  92. 08:18you know, well, what's in reverse?
  93. 08:22Because it's a proxy, right?
  94. 08:26I don't I don't know.
  95. 08:27I don't know.
  96. 08:28It's like an inverted index.
  97. 08:29Like what's inverted?
  98. 08:30It's like it's a terrible name.
  99. 08:32Anyway, yeah, I I mean it's still better when when you get the NAT nat tables, the lookups, some of those things like some of that.
  100. 08:39But yeah, I hear you there.
  101. 08:41There's some like weird names with this, but at at Shopify, what were some of the kind of like hard engineuring challenges that you engineering challenges, outages, like like learnings that kind of defined you that were really also fun at the time or interesting to learn, but
  102. 09:00it would have been hard to get it elsewhere.
  103. 09:03Yeah.
  104. 09:03So I think it was, you know, in the 2010s there's like a bunch of SAS companies that that scale really quickly and I felt so fortunate to have a front row seat to that
  105. 09:12and so I ended up on the infrastructure team and this was back in you know 134 and uh Docker was coming out and so we were containerizing everything and
  106. 09:22we were just every single year we had to you know the growth rates of of of SAS sometimes seems quaint in comparison to the growth rates of companies today but it was a company that was growing at you know 120 40%
  107. 09:33year-over-year.
  108. 09:34Um, and so every year we were just preparing for a Black Friday that was going to be a lot worse than the last.
  109. 09:40And this is back in the day of we're buying physical hardware, right?
  110. 09:43We have to like place an order at a particular point in time and do some interpolation based on that.
  111. 09:47Um, and the software also had to scale.
  112. 09:49And when you're scaling most software, a lot of the application layer problems end up back at the database layer.
  113. 09:56And so I just naturally found myself at this layer between Rails and the databases.
  114. 10:01Shopify didn't at the time at least contribute many patches to the databases themselves but mostly just spent time orchestrating.
  115. 10:08So we were doing sharding because as um my my dear boss Camilo used to say you can't cache rights.
  116. 10:16So there's a fundamental point where you you just you have to move beyond a single shard.
  117. 10:22Um so I wasn't I joined around the time and they did the sharding and they did it I think they did the cut over a week before Black Friday which is mindblowing.
  118. 10:31uh and very but it worked and then the the subsequent years we worked on things like going into multiple data centers.
  119. 10:38We also had this big mysterious reddish server that was like you know 128 GB of RAM which was a lot at the time.
  120. 10:44Today 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.
  121. 10:52Um because people had just been treating it as this KV store.
  122. 10:55Um and so we started splitting it out.
  123. 10:57We did all this stuff around making sure that if you if you if you go visit a Shopify store and the thing that stores your sessions is down, the right behavior is not just for the entire the of everything to be down.
  124. 11:12But that's kind of the default failure mode, right?
  125. 11:13You're not going to rescue all of that.
  126. 11:15Um unless you're in a programming language that really forces that decision.
  127. 11:18So we did things like um build this matrix out of okay well this service when this component is down should act this way.
  128. 11:27Um and I found myself writing the test suite for a bunch of that.
  129. 11:31And then I was like okay well we can't just mock all of this.
  130. 11:33And so um I came up with this idea at the time of like oh what we're going to do is we're just going to um shell out to GDB
  131. 11:40and then into the process and then close the file descriptor to the database to simulate the through the entire layer that the database fails.
  132. 11:47That was a little crazy and we never shipped that on CI but it did uncover a massive amount of issues in Rails that' be upstream and things like that of around just like handling failures at the connection layer.
  133. 11:58So then I moved on to create this proxy called Toxyroxy and
  134. 12:02have you heard of this before?
  135. 12:03No. No.
  136. 12:04Yeah.
  137. 12:04Toxyroxy is it's just like a layer 7 proxy that sits in between um you and well layer four but in between you and the databases.
  138. 12:14So you basically have just like this proxy and then my SQL whatever doesn't speak the protocol but then you can do an API call say take take uh take the database down make it slow
  139. 12:24um and over time it also added layer 7 things of 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
  140. 12:36so the basically the proxy was just like a really thin layer which like was passed through but you built the functionality to like simulate problems with database or things like data corruption or whatever you wanted to do.
  141. 12:49So you could just do it in there and then you can anything that built on top of it but but then Oh yeah and then everyone had to like call this proxy or it needed to be on in a layer.
  142. 12:58Exactly.
  143. 12:58So you could do like do like my you know proxy.mmysql downdown 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
  144. 13:11tens of issues right in the myql driver in the rails like 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 in myql down
  145. 13:21you're focused on just getting back up and not like what could the application actually have done.
  146. 13:26Yeah, it's interesting.
  147. 13:27Of 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
  148. 13:37and I never connected until now that I mean state is usually there's a database.
  149. 13:41If there's no database, if you have stateless services, you know, I mean, you still have problems, you have nodes going down, you have, I don't know, corruption, whatever, but it's usually like more isolated.
  150. 13:51But basically, like if we have state, we typically have databases.
  151. 13:54is if we have databases and if you can simulate these problems suddenly you can I mean you you can like predict a lot of things but the problem with state often time is it's really hard to
  152. 14:04simulate problems happening ahead of time unless when they happen so did you it sounds like you have pretty good success with
  153. 14:10yeah I think to my knowledge it's still um running in like 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
  154. 14:21um and so we wrote all these tests against it to implement and all of these different uh different failure conditions and it just yeah it was it was it worked out great.
  155. 14:29So you spent eight years in total at at Shopify.
  156. 14:32So like starting from like all right just a gap year it just went on a year a year and another year.
  157. 14:36Um at what point did you think about leaving and why and what was your kind of decision framework?
  158. 14:44It sounds like you or you were like on Epic right now even today Shopify it's doing wonderful.
  159. 14:49It's probably doing even way better than like like you know that growth kind of kept on.
  160. 14:52So I'm sure there would have been an argument to stay and you know stay on their August ship.
  161. 14:56Yeah.
  162. 14:56So I I spent I spent eight years there from 13 to to 21.
  163. 15:02Um and I I think there just came a point where I wanted to see something different again.
  164. 15:08I've been inside of Shopify since I was 18 years old, right?
  165. 15:11I'd been seen one other startup in high school.
  166. 15:14I was like if I want to learn more about computers and learn faster, it might be time to inject some novelty into this function.
  167. 15:20Um, and so I I left in in in 21 and I'd worked on so many different parts of the infrastructure like caching.
  168. 15:28Um, me and Justine, who's now my co-founder, we wrote the entire storefront um, storefront for Shopify, um, which powered almost 100% of traffic 18 months after we embarked on it.
  169. 15:38Um, we've worked on running Shopify in multiple data centers.
  170. 15:41We've worked on so many database scaling projects like caching, all of these different things, right?
  171. 15:47Um, a lot of the a lot of the scalability came from the Kardashians launching lots of products on on Shopify, which would force a lot of traffic.
  172. 15:54Um, but that's that's eventually how I left.
  173. 15:57And so when I left, I didn't really know what I wanted to do.
  174. 16:00And so I one of the projects I had while I was at Shopify was this napkin math project.
  175. 16:06Have you seen this
  176. 16:07napkin math?
  177. 16:07No.
  178. 16:08No. Um, so napkin math was essentially just this table that I maintain on GitHub of how much bandwidth can you drive to DRAMM, what does a roundtrip to S3
  179. 16:21cost, 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?
  180. 16:29Just a collection of probably there's probably like 50 of these numbers and then a RS script that generates them all.
  181. 16:36um what all these things cost?
  182. 16:38What do you like?
  183. 16:38What does a gigabyte of memory cost?
  184. 16:40$2.
  185. 16:40What does a gigabyte of S3 cost?
  186. 16:422 cents.
  187. 16:42What does a gigabyte of um this cost?
  188. 16:4510 cents, right?
  189. 16:46What does it cost on spot?
  190. 16:47What does it cost on a three-year commit?
  191. 16:48Like I had just have a massive table and then create flash cards for almost every single cell.
  192. 16:53So I know all these numbers.
  193. 16:54And this was a project I started taking on at Shopify because I found myself in um this role a lot where I would go in and review a project, right?
  194. 17:03So some product team would be like okay we got to do we got to build this thing so we got to build this infrastructure to support the feature and a lot of the times they would say okay well we've gone and benchmarked it on database A
  195. 17:14but the benchmarks are not very good so we're going to go with database B and I hate benchmarks so much because that's not a satisfying answer to me to me it's like
  196. 17:31this does not jive maybe 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
  197. 17:43you're searching for three terms there each term has this many documents that match it that's this many megabytes we inter intersect these many this many lists you have DRAM bandwidth on multiple cores of 100 gigabytes per second this should take 10 millisecond you tell me the benchmark takes 10
  198. 18:02one of us is wrong.
  199. 18:03Either there's a gap in my understanding, which is very likely, or you would benchmark the wrong thing.
  200. 18:09And in some ways, some reasons, right, it's like, okay, you've done a benchmark.
  201. 18:12You don't didn't realize that your benchmark is doing a distributed query across a 100 different nodes.
  202. 18:17And so, of course, the P99 is going to be really, really high, right?
  203. 18:21Unless you've cut that off or or made some different set of trade-offs.
  204. 18:24So I just found myself in these discussions repeatedly where people were making infrastructure decisions based on poor benchmarks.
  205. 18:31And so I needed some I I needed some ammo to go in and just be like okay we can just do the calculation right here and then.
  206. 18:37Um because I was always doing these like little demos or like writing little prototype scripts to to demonstrate this.
  207. 18:43But it was just I just the argument of here's how a beach tree works.
  208. 18:48This is how many pages we have to visit.
  209. 18:50This is what a random SSD read takes.
  210. 18:51It takes one millisecond.
  211. 18:53you have to visit a thousand blah blah blah blah blah and then present it back and see if this is the difference to your query.
  212. 18:58Well, like is the query plan correct?
  213. 19:00Like is there a bug in my SQL?
  214. 19:01Do we have bad discs?
  215. 19:02Like what's the discrepancy here?
  216. 19:04And I just got caught with that bug.
  217. 19:06And so after I left Sha, I was just writing a lot of articles about this.
  218. 19:09I was just like, well, how long does should this query take?
  219. 19:11And then I one hypothesis I had at some point is like, okay, well, how many writes per second can MySQL do?
  220. 19:18Well, shouldn't the amount of writes per second that MySQL do equal the amount of f-syncs that you can do per second?
  221. 19:24That sort of makes sense, right?
  222. 19:25Every time you do a write, you f-sync to persist to disk.
  223. 19:28So, how many f-syncs can you do per second?
  224. 19:30Well, an f-sync takes one millisecond.
  225. 19:32So, you do a thousand writes per second.
  226. 19:33That well, that doesn't really match up.
  227. 19:34Like, feel like a database can do more than,000 rightes per second.
  228. 19:37Why can it do that?
  229. 19:39So, that was one of those things where I tested and it's like, okay, well, my SQL on a little dinky box could do 10,000 writes per second.
  230. 19:44Well, how is that possible?
  231. 19:45Mhm.
  232. 19:46And now you would just ask how is it possible?
  233. 19:49Because you batch.
  234. 19:50So an f-sync happens on usually a 4K.
  235. 19:53Yeah.
  236. 19:54Right.
  237. 19:54But it's like that's not intuitive.
  238. 19:56Like it's actually I I I got caught.
  239. 19:58It was like just like you know probably some like 24-hour period where I just got obsessed with this question where like you're writing like the BPF traces and all of that to do all of this.
  240. 20:05This is like pre-LM so it took forever and you and then I found out that oh every f-sync was like much larger than I would have inferred 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 somewhere in like a central German town that's like
  241. 20:22written some article about like how some intricacy of my SQL works and a patch that they did to it's like the entire internet runs on small towns in Bavaria.
  242. 20:32I'm convinced.
  243. 20:33Yeah.
  244. 20:36And then you decided to start Turbopuffer.
  245. 20:40Yeah.
  246. 20:40Did h how did you decide?
  247. 20:42Did 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.
  248. 20:48You you've done an awesome job benchmarking like what is the theoretical like limits?
  249. 20:53You were very familiar with this probably became you know like world expert in in this niche.
  250. 20:59And then how
  251. 21:02did did you want to go into databases again?
  252. 21:05I think it was there's three things that sort of came to a head.
  253. 21:11Um the last project that I worked on at Shopify was search and I didn't have a good time.
  254. 21:16What what what did you use back there?
  255. 21:18Um I don't we don't need to name names of other database companies but it was uh it was one of the one of the like traditional search companies that a lot of different um 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
  256. 21:34that database just I couldn't get them to perform at the napkin math and like there's there's no query planner and like 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 like start
  257. 21:49reading the source code of it and I was just I couldn't get it to track very often.
  258. 21:52It was very difficult to operate and so I just that was sort of like in the back of my head.
  259. 21:56I never thought I would touch that again.
  260. 21:58Then the second ingredient was the napkin math project because it sort of just 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
  261. 22:10properly.
  262. 22:11Yeah.
  263. 22:11And then the third one was that doing this you know leaving Shopify in 21 having spent eight years there and during that time I did this I called it angel engineering so I like joined my friends companies and then I just vested equity instead of um
  264. 22:25instead of just investing or something like that and because I wanted to have my fingers in it I wanted to like see what else was out there that's why I left and
  265. 22:32this problem kept coming up again again and again and again right like ChachiBT came out in 2022 and I was working with 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.
  266. 22:46So you had to reach for search very quickly.
  267. 22:48So it's like a few kilobytes.
  268. 22:49It was eight kilobytes or four kilobytes depending on the model.
  269. 22:52It was very very small.
  270. 22:52So you had to reach for search very quickly.
  271. 22:54Right.
  272. 22:55And
  273. 22:56so I I I worked with them and I was I was I created a little recommendation engine and the recommendation engine was actually quite good.
  274. 23:04Um, like I s I found out that one of the co-founders wife was pregnant through the recommendations that I was getting when I was running it on his feed.
  275. 23:11Um, like it was it was it it
  276. 23:14weird but
  277. 23:14it was recommending.
  278. 23:15Yeah.
  279. 23:15I mean it was just like you know he was reading about like and I did get permission.
  280. 23:21I just like I don't think anyone expected to be good enough and just like okay it's this this thing is working and then I ran the back of the envelope math on what it would cost to do this for everyone like all the users.
  281. 23:32This is a company called Readwise.
  282. 23:33So it's like articles that you save and then and insert later.
  283. 23:36And it was going to cost 30 grand a month.
  284. 23:39And this was a company.
  285. 23:40It's a bootstrap Canadian company.
  286. 23:42They spend about five they at the time they were spending about 5k a month on all the other infrastructure combined.
  287. 23:47So it just it didn't the you know fundamentally in a company if you're doing an investment you have have to run some gross margin on top of whatever you're paying right and it just didn't line up.
  288. 23:57Um and so we just didn't ship it.
  289. 23:59I worked on I you know tuned to autovacuum on postcress or something like that which is a good pastime and then you I just couldn't stop thinking about why it was so expensive to store
  290. 24:10all of these vectors that we were using for the recommendations and I just sat and did the napkin math one day of like can we just use it all in S3 and do some clustering and then organize the files and just the way and it's like maybe you could build that and then
  291. 24:25one day I just kind of said [ __ ] it and did it and like sat down and started started to like to write it out.
  292. 24:31Um, and I spent the summer of of 23 just hammering my head against the wall trying to find an approach where I could get the latency that I wanted.
  293. 24:40Um,
  294. 24:41because the problem with S3 is it has really good durability, but latency we're talking hundreds of milliseconds, right?
  295. 24:46Yes.
  296. 24:46The P99 on a uh 256 or 512 kilobyte object on S3 um is around 200 milliseconds.
  297. 24:56Um,
  298. 24:56and and you're saying P99 because like when you're talking large scale, you want to care about the P99, right?
  299. 25:01Yeah.
  300. 25:01I think when you're
  301. 25:01That's why we're not talking about P50.
  302. 25:03When you're designing a system, you want to optimize for the P99.
  303. 25:06And especially because when you're designing a system on on S3, generally in every roundtrip, you're not doing one request.
  304. 25:12You're often doing lots of requests, right?
  305. 25:14You're going to hit the P99 real quick.
  306. 25:15Exactly.
  307. 25:16So, it's like if you're navigating a tree on S3, right?
  308. 25:18It's like, okay, you get the upper layer of the tree 200 milliseconds.
  309. 25:20You get like another layer of the tree 200 milliseconds.
  310. 25:23You get a bunch of leaves of the tree in 200 millonds.
  311. 25:25So in aggregate you have like 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.
  312. 25:35So, I just sat and sketched that out um and tried a bunch of different approaches and then and then finally in in in July of 23, I I I got something
  313. 25:46end to end that seemed to work and then rewrote it probably twice and then released it in in October of of 23 based on um based on just that that summer of of of working through it.
  314. 25:56And then you kind of you built it on on top of S3 because I guess durability and and all of and just really good.
  315. 26:02How did you make it fast?
  316. 26:05We didn't in the beginning or I didn't in the beginning.
  317. 26:07Um it was just me at the time and it was really like it was it was it was a project.
  318. 26:12It was not a company.
  319. 26:14It was not
  320. 26:15it was it was it was to satisfy a curiosity.
  321. 26:18It was not I did not set out to do this like I'm going to go like raise $10 million and do like I was like I barely knew what a VC was.
  322. 26:26Like I was like I just had to do this thing and I was so focused on doing it.
  323. 26:32so 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.
  324. 26:38And so the first version was the simplest possible thing.
  325. 26:42I think I'm a very pragmatic person like I I didn't get buried.
  326. 26:48I barely read any like of the literature on LSM.
  327. 26:52I sort of like you know read a bunch of it just like got the basic idea barely implemented that because that would have taken too much time.
  328. 26:57It was the simplest possible version of what it could be.
  329. 26:59Like really what you have to imagine is that the simplest way you could do this is you run some clustering algorithm on the vectors.
  330. 27:06You get the clusters and then you put the clusters in files.
  331. 27:09The cl the files are called cluster one, cluster two, cluster three and then you have another file called centroidids of the clusters and then you do the search by downloading centroidids
  332. 27:19looking at the centrids and then downloading the n closest clusters.
  333. 27:23There was a few optimizations around merging some clusters that were JSON in files and so on just to like control some cost and some performance but that was basically it and then getting that to scale.
  334. 27:33That was the first version.
  335. 27:34And then how do we make it fast?
  336. 27:36Well, I didn't even implement a caching layer.
  337. 27:39I just put the reverse proxy in front of S3 with Engine X and then had it
  338. 27:43know what a reverse proxy is.
  339. 27:44I like I do know what it is.
  340. 27:47I just still don't know what what the reverse is about.
  341. 27:50But anyway, um the reverse the reverse proxy reverse things.
  342. 27:56Um the the performance in this case um maybe that's what it's about by caching right all of the all of the S3 objects.
  343. 28:03It again it was the simplest like it's like I'm just going to put that in front.
  344. 28:07I knew how to configure engine X like I've written more enginex Lua than u than a lot of engineext Lua very good software.
  345. 28:15um just had that cache in front and then the way that I would do things like deleting in the cache was just like shell out to XRX and just remove like things in the in the cache and reverse engineer the directory structure on engine X and that's what we shipped and it was just running on a single
  346. 28:27server in a T-Ox instance.
  347. 28:28I was like okay let's see if anyone gives a [ __ ] Yeah.
  348. 28:31So so far I mean this is kind of like cool engineering and like a cool side project and like a bunch of novel ideas and I you know like I think just some hardcore engineering.
  349. 28:40How did cursor come into play?
  350. 28:41Because like when I learned about Turbopuffer, I was talking with Cursor about like how they built their their back end, their database, how they scaled, and they're telling me all these migrations and they were telling me like, oh yeah, so we we were on Postgress, but it didn't no they did something else in Postgress.
  351. 28:59It didn't even work that well.
  352. 29:00They went to AWS Aurora, which is managed service of Postgress, and it didn't work well, which is very surprising.
  353. 29:05And they're like, "Oh, yeah."
  354. 29:06And then we went to this thing called Turbopuffer, and they worked well.
  355. 29:09And I was like, what's turbuffer?
  356. 29:11And they're like, oh yeah, turbopuffer.
  357. 29:13I think I think they said like we were one of their first customers.
  358. 29:15And this never computed to me.
  359. 29:17Curser was already massive at that point.
  360. 29:19How did you meet the folks?
  361. 29:21And how did they become would were they the first customer?
  362. 29:24One of the first.
  363. 29:26They were the first customer.
  364. 29:27The first
  365. 29:27the first.
  366. 29:28No.
  367. 29:29Um they they they reached out um after I just launched on on Twitter.
  368. 29:35I was like, "Hey, I built this thing."
  369. 29:37And frankly it was like in I exact you it was like hey launch this thing and to me I was like I am so sick of working on this like I was like I've been working on this all summer I don't know if anyone cares
  370. 29:49I only want to work on this if anyone cares.
  371. 29:51Let's put it on Twitter again single Tox instance on a 8 core node somewhere in GCP.
  372. 29:56I was like if someone goes to prod I'll I'll set it up properly on multiple and like I'll just block on that but let let's see if anyone cares.
  373. 30:02It was like the MVP of MVP.
  374. 30:04Anyone 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.
  375. 30:14Um, and I've just, you know, I've worked on I was just releasing it like a SAS project.
  376. 30:18Why can't you work on a database like it's SAS?
  377. 30:20I don't, you know, it's like if anyone uses it, we'll do it properly.
  378. 30:22I know how to run software with a lot of nines.
  379. 30:25Um, but it was not a proper LSN like it was very very it was the simplest version of what it could be.
  380. 30:30And then I released on Twitter.
  381. 30:32I was like, "Yeah, you could do a million vectors for a dollar."
  382. 30:34And before that, I think the the cheapest was maybe $100 per million for something that actually worked.
  383. 30:39Yeah.
  384. 30:39Um, and I knew it was reliable, right?
  385. 30:41I knew like I had these invariants like if you shut down all the VMs, like no data is lost, like all the rights are committed directly to object like it has all the same invariants it had today.
  386. 30:50Um and cursor reached out and knowing them now I'm sure at the time the cursor was maybe eight people and knowing the founders now I am sure that they had sat at the dinner table one day and we're like the unit economics of what we have right now where all the vectors are in DRAM
  387. 31:05are 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
  388. 31:14and everything else just sit in opic stores and then we just hotload it in and out of the cache
  389. 31:18makes so much sense right you open the codebase few seconds and it's in RAM and then the queries are as fast as anything else.
  390. 31:23It made so much sense.
  391. 31:24So I mean at the time they were if you look at some of Aman one of the co-founders early tweets he talks about uh using S3 for KV caching and things like that which barely anyone is still doing even though
  392. 31:35um the economics
  393. 31:36yeah price wise yeah it's and it's it's very it's very uncommon and I think it will happen right but they were ahead of their time
  394. 31:42and they I think they were I don't know if they were thinking of building it themselves I think that's quite likely um and they found Turboper and it just perfectly pattern matched into that again I don't know if this dinner conversation happened or if this was just inside
  395. 31:56Harvey's head.
  396. 31:57Um, but it pattern matched something and so we exchanged a bunch of emails and then something compelled.
  397. 32:03I didn't know anything about B2B sales.
  398. 32:05Now I love B2B sales.
  399. 32:07Um, I didn't know anything.
  400. 32:08I was just like I just want to help them cuz they they were they had some unit economics that didn't line up.
  401. 32:13So I just went to San Francisco, right?
  402. 32:15I live in Canada.
  403. 32:16I went to San Francisco and I showed up at the office and when I showed up at the office they um they were having some Postgress problem that they were discussing.
  404. 32:23Yeah, the AWS aurora problems.
  405. 32:25Yes.
  406. 32:25Yeah.
  407. 32:26Early on.
  408. 32:26And I was like, "Oh, do you guys have PG analyze?"
  409. 32:29And they said, "Oh, no, we don't."
  410. 32:31I let's let's get that going, right?
  411. 32:33Let's look at it.
  412. 32:34And it was the same thing as it always is with Postgress, which is autovacuum hadn't run enough and so they had all of these like going to heat when they should be doing index scans and blah blah blah.
  413. 32:43So, we were talking about all of that.
  414. 32:44And so, it's just helping them, right?
  415. 32:46It was like my, you know, my database genes just like kicked in.
  416. 32:49And 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.
  417. 33:00And um at this time I'd also approached who I thought was the best engineer who ever worked at Shopify, my co-founder Justine.
  418. 33:08um and she'd come on and the first thing that she did was um remove the reverse proxy enginex cache with a file-based cache just a direct cache which again great like the S3 thing worked
  419. 33:21um and so she was online she was starting to work on it and um and cursor cursor cursor then that night was like okay well we're going to migrate and so they migrated everything over the course of like a week or two after that
  420. 33:33um but cursor was a small company back then right yeah and they were they just in the beginning of their massive rapid growth.
  421. 33:40Exactly.
  422. 33:40And I I told them that I was going to reduce their bill by 95%.
  423. 33:45And I did like we did.
  424. 33:47Justine and I did.
  425. 33:48We like they came on and their last bill with their previous vendor and the first bill with us, it was 95% lower.
  426. 33:56Yeah.
  427. 33:56And you're you're nice for not saying vendors, but I I can say talks to them and and it's in the deep dive about cursor.
  428. 34:01It was it was a it was Aurora specifically.
  429. 34:04Uh so
  430. 34:04this was this was not this was not Postgress.
  431. 34:06No, this was a
  432. 34:08it was a different one, but it's probably still in the write up.
  433. 34:10We don't we don't need to name names, but uh yeah, but they were the reason they went there is reliability was their main main pain point.
  434. 34:17I'm sure the unit economics would have been there, but yeah, this was and then what Swallow told me is he said like look like there's a few things that we did never ever do and he said one of them you should never ever bet your business on a tiny startup where you are their only or biggest customer
  435. 34:30except for Turbopuffer and he said I love love those guys.
  436. 34:33So I guess it just comes to show that even in your case like to me what this story is shows is is you can do things when you build
  437. 34:41highquality 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
  438. 34:55by helping them by showing that you know you know your stuff like you suddenly brought in your your 10ish or eight years of Shopify experience and your curiosity and They probably took a risk because of that, not because you were some, you know, random vendor.
  439. 35:07They probably never done that.
  440. 35:09So, fast forward today, uh, Turbopuffer is now a lot bigger.
  441. 35:13You're you're working on some some some cool things, but you have this very interesting business where for you CPUs are important, right?
  442. 35:22You run on mostly CPUs.
  443. 35:24And you told me a story over dinner yesterday that uh you met Jensen uh and Jensen he really wanted to sell you on GPUs.
  444. 35:34Can you tell me how that meeting went?
  445. 35:36Um yeah, Jensen Hong, right?
  446. 35:38Yeah.
  447. 35:38I just I never met uh I'd never met uh Jensen before.
  448. 35:42We were we were at an event at uh at at Nvidia and we were just doing um presentations in a big HQ.
  449. 35:49Super impressive.
  450. 35:50Yeah, exactly.
  451. 35:50they've invited a couple of companies to go and and um and and and talk about um uh talk about our businesses and how we can partner with Nvidia and so on.
  452. 35:59And I I don't I I don't know.
  453. 36:03I was like I think I was in a goofy mood that day.
  454. 36:05And so I went up on on stage and I said, "Um, hey, I'm Simon from from Turbopuffer."
  455. 36:12And uh and yeah, if you're wondering about the name, it's like if everything goes south, we can always pivot into vapes.
  456. 36:20[laughter]
  457. 36:21I was kind of nervous and this is what I this is what I said and then and then he said back to
  458. 36:27wait who was in the room?
  459. 36:28Was it Jensen?
  460. 36:28Was it a direct report?
  461. 36:29It was it was Jensen and then I don't he has like I don't know if it's just 50 direct reports or it was like you know it was there was it was Jensen and then a bunch of the um like Nvidia Nvidia leadership, right?
  462. 36:41Um cuz you go there and then you talk about that you find opportunities to partner and work together, right?
  463. 36:45And so I said, "Yeah, you know, so plan B could be that we could pivot into vapes."
  464. 36:52And then he said, I was already nervous.
  465. 36:55He said, "Judging by your slide, maybe you should."
  466. 37:01[laughter]
  467. 37:02No, he did not.
  468. 37:07And and
  469. 37:08[gasps]
  470. 37:10I didn't know what to say back to that.
  471. 37:12So I said, "Well, Jensen, do you vape?"
  472. 37:20[snorts]
  473. 37:20[laughter]
  474. 37:22He didn't he didn't answer the question.
  475. 37:26[laughter]
  476. 37:26And then someone um someone on the um someone on the on the team um wrote to the whole company, Turop Puffer Company, Simon just asked Jensen if he vapes.
  477. 37:39Um, and then you know this is this is a great start, right?
  478. 37:43And um, and then the team had team team had sort of talked to me beforehand.
  479. 37:47I was like, Simon, we got to make sure we don't say the C-word.
  480. 37:50We can't say CPUs.
  481. 37:55And so I just couldn't stop talking about CPUs.
  482. 37:57I was like, AVX 512 is so sick.
  483. 38:00Like we love SIMD and um, like we we we like there's so many CPUs.
  484. 38:05They're so easy to get.
  485. 38:07like um it's just a riot in CPU land.
  486. 38:10Like you know I I don't I think I stopped short of saying I'm so glad I don't need GPUs.
  487. 38:15[laughter]
  488. 38:15But but it was just it I just couldn't stop talking about CPUs.
  489. 38:21Yeah.
  490. 38:21And so you know Jensen took an interest in that.
  491. 38:24Yeah.
  492. 38:26So who who knows like I'm sure you made you made a memorable impression.
  493. 38:29Maybe he made it his mission now to like at some point get you guys onto GPUs.
  494. 38:33But speaking of CPUs, can you tell me a bit what you're seeing inside of the hypers scale, the cloud providers?
  495. 38:39You're now in AWS, you're you're in GCP, you're on Azure.
  496. 38:42What I would think naively is there's a GPU shortage and when I talk with inference companies, they are and and and AI labs, they're just getting whatever they can do.
  497. 38:50I would think getting CPUs is should be easy.
  498. 38:53Is it?
  499. 38:54No,
  500. 38:55it's not anymore.
  501. 38:57Why?
  502. 38:57What's happening?
  503. 38:58Can you tell us about dynamics on on on the why and what you've learned?
  504. 39:01Yeah.
  505. 39:01So, I think that GPUs will probably continue to be scarce.
  506. 39:07Like, I don't know, maybe there's going to be some surplus.
  507. 39:09I I refuse to speculate too much about the macro, but I think as as RL is becoming a very very large amount of the workloads that needs a lot of CPUs.
  508. 39:20So, the labs are sucking up a lot of CPUs because you need CPUs to be like, okay, we need to like teach this model how to how to search.
  509. 39:26We need to teach it how to use GP.
  510. 39:28We need to teach it how to boot up bash.
  511. 39:30We need it needs to run real things and learn from that takes a lot of CPU.
  512. 39:36Um and so I think as we RL is consuming a lot of CPU and then also just all of the agents are running on CPUs, right?
  513. 39:42They need to do all kinds of very general purpose things on a CPU and so as as as the demand curve is sort of shifting to the right and it's becoming more and more applied and that feeds back into RL by the way, right?
  514. 39:53because as things become more applied like oh the models are not that good at CAD or ship building I don't know and then you know you have to spin up even more RL environments to do that so I think that's what we're seeing and so we're on the other end of that needing these CPUs
  515. 40:06we need a lot of NVME SSDs as well um and a lot of this right now is tied up in DRAM right of of where like
  516. 40:14you need a lot of that also for the GPU servers um but I would assume that it gets a lot worse before it gets a lot better on the on the CPU side
  517. 40:21um and I think even the big companies are fighting amongst each other, right, to get the allocations and even we, you know, we're selling to companies that we also fight for CPU with and against, right?
  518. 40:32It's uh it's it's it's really difficult and so you write things to try to make sure you get these CPUs as f fast as possible.
  519. 40:38Yeah.
  520. 40:38And yesterday I was at a dinner that you hosted with your team where you actually have a bunch of Turbo customers.
  521. 40:42A bunch of them are AI AI labs or or AI startups but a lot of them one of them uh reflection had have hu massive amount of footprint and they were telling me that they're in a situation where they cannot buy more like they
  522. 40:57when it comes to GPUs or CPUs they max out they have the longest contracts that possible and I didn't realize how competitive it is in the cloud when you you go beyond a small fish to like a medium size or even a a large fish that now like
  523. 41:12It's it's interesting.
  524. 41:13So So now you have this and even you're having this this uh kind of fight behind the scenes that is maybe not as visible.
  525. 41:19Exactly.
  526. 41:19And I mean you you work with the clouds right you work with them to talk about which regions have um have CPU which regions are getting it comes down to power right of like okay well where is the power which is generally where they're going to ship the new CPUs.
  527. 41:33Um and so we have to work with some of our biggest customers on that.
  528. 41:36So these are real constraints right that are that are making our way to us.
  529. 41:40We're just very fortunate that it's very easy for us to run lots of turbuffer clusters because all we need are like a few CPUs and NVME SSDs and then S3 and then we're in a good place.
  530. 41:51But there's lots of changes that we can make even to the architecture um to try to protect from from a lot of this.
  531. 41:56Now I'd rather spend that engineering effort on other things but we are very very good at using a lot of very different SKs, right?
  532. 42:03So we don't need everything to be a particular CPU or instance type.
  533. 42:07We can run with many even many different types of machine types.
  534. 42:10Um
  535. 42:11Q meaning that's the it's a fancy name for like the different machine types.
  536. 42:15Yes.
  537. 42:15Exactly.
  538. 42:15Right.
  539. 42:16Like you know C4D or I AG or whatever they're called.
  540. 42:19What's your favorite one?
  541. 42:21Um we really like right now the um C4s on uh GCP.
  542. 42:28GCP.
  543. 42:28Um the Z4Ds are also performing really well um now that we've done done a bunch of of um of optimizations to them.
  544. 42:36Um those are really really great machine types.
  545. 42:39Uh we really like those.
  546. 42:40Um and then the ARM C4As as well um on on GCP.
  547. 42:45Um we like those.
  548. 42:47But I think that in general like when you're yeah when you're small it's very easy to suck up a bunch of but at Shopify I was also part of you know deciding
  549. 42:56ahead of BFCM right a few months out you have to tell the cloud providers how much you're intending to use.
  550. 43:01do commits on all of that, right?
  551. 43:03The the clouds are not infinite as they seem when you're small.
  552. 43:06And one way, of course, to like get like infrastructure and and also just like credibility is venture capital.
  553. 43:12If you raise $100 million, a billion dollars, some of your customers just raised $2 billion.
  554. 43:16Actually, I talked with them yesterday.
  555. 43:18You know, it gives you credibility, gives you cash, you can pay for this thing.
  556. 43:21Your specific Turbopufferers relationship to venture capital seems very interesting.
  557. 43:26I never heard you announce a raise until m maybe just very recently.
  558. 43:30Can you tell me how you and and you told me that when you started this thing, you didn't think too much outside of just building some cool stuff.
  559. 43:36How 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 which is typical inside of Silicon Valley.
  560. 43:48Yeah.
  561. 43:49So I think to to understand my how I think about capital you have to go back to the the beginning of Turbopuffer, right?
  562. 43:57where I promised cursor that Justine and I could get their bill to 4K a month.
  563. 44:03And this was based on some very rough napkin math on, okay, if if Turbopuffer was a better implementation than it currently is, then it should cost this much.
  564. 44:13And that's the pricing we ship with and that's what we guaranteed um guaranteed cursor.
  565. 44:18Um but the software was not that good.
  566. 44:21Like it was very reliable, but it was very simple, right?
  567. 44:24And that's like a core engineering principle of me is simplicity above everything.
  568. 44:29Um you and I have talked before about how software that ages well and some of the advantages of seeing be having long tenures inside of companies.
  569. 44:36You had a long tenure at Uber.
  570. 44:38I had a long tenure at Shopify.
  571. 44:39So you see simplicity just almost always wins.
  572. 44:42Um 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 sort of expecting that you have to earn a big return on that on some timeline that makes sense to everyone involved and everyone
  573. 45:02involved are you know pension funds in Canada like that it's like it there's like a whole stack right of of of people that that need to so at the time I was like I don't you I don't know if this could be a billion dollar company.
  574. 45:13I didn't know that in the very very beginning.
  575. 45:15Um it wasn't completely clear to me.
  576. 45:17It felt like a very niche kind of product, right, to build this particular search engine.
  577. 45:22Um and that was completely fine with me.
  578. 45:24So I you know it's it's it was fine.
  579. 45:27And so then I just I just looked at the cursor bill and I looked at my GCP bill which is what we started on.
  580. 45:35and you know as like a you know dumb Danish person who's just like okay like this number should just be lower than the other number.
  581. 45:42Yeah,
  582. 45:43that's sort of like you know and it's just I don't think I'd spend enough time in San Francisco cuz I think the money over here it works a little bit differently.
  583. 45:51Um that's just that's all I knew.
  584. 45:54You you were doing business 101 as as long as you're making a profit you're good, right?
  585. 45:59Yeah.
  586. 46:00It was like I'm 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.
  587. 46:11And maybe if if if we could get some other workloads, we could start paying ourselves.
  588. 46:15But that was like very much the philosophy at the time.
  589. 46:18Um because I didn't know if I could go raise a bunch of of of money.
  590. 46:21I didn't know anyone who had the money.
  591. 46:23I I didn't have any relationships.
  592. 46:25Um you were an absolute outsider to the
  593. 46:27I was I was an outsider.
  594. 46:28I was like an outsider squared, right?
  595. 46:30I grew up in Aus, Denmark and I um I then moved to Ottawa, Canada.
  596. 46:35So it's like I'm an outsider to Canada and in Canada I'm an outsider to San Francisco.
  597. 46:41So I was just thinking about this from first principles like oh you're a venture capital you need this return you need it on this timeline.
  598. 46:49I don't know if I can deliver that yet.
  599. 46:50I would need more data to decide that because I want to like 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.
  600. 47:00Um in in in January then I uh there was a person that I was at II with in in uh in 2012 and 2013 and his name is Buen and he was on the North and Macedonian team
  601. 47:13um at II um and he was he's he was really good.
  602. 47:17He was so good that the North Macedonian team called him God.
  603. 47:20Um I don't know why but that was what he went by and he was yeah he was very good grew up and and I really wanted to work with Buen
  604. 47:30but I couldn't afford to work with Boyan
  605. 47:31[laughter]
  606. 47:32um and he was very much like this is what I can live off like you know I just like I want to build this date like that would be like this is what it can be but at this point Justine and I hadn't taken a salary for like 6 months
  607. 47:44and we'd already we'd already spent like tens of thousands of dollars on like on GCP bills and all of that and I was like I don't think we can I don't think we can we we can do it.
  608. 47:54And so I had met one one individual in in Silicon Valley uh his name is Locky and it just I ended up just calling him and saying hey I kind of want to learn a little bit faster here.
  609. 48:06Can I can we raise like 700K?
  610. 48:10That's like what I wanted to raise.
  611. 48:11So it's just like I want to have like two engineers for the rest of the year.
  612. 48:17Justine and I still don't need to be paid and then a little bit of buffer room.
  613. 48:20It's like this is what I need and if this doesn't have PMF and is 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 it taking a dime.
  614. 48:28We'll return everything to you.
  615. 48:30Um I think there was the first time you heard anyone say it like that.
  616. 48:35Um and um I told some other VCs that at the time and that was terrifying to them.
  617. 48:39I think to someone on the West Coast this sounds like you have low ambition or something like that.
  618. 48:45M
  619. 48:45um and to me it was just like I I don't know it just came from a when I don't know how to play a game I just play with open cards like this is how I see it
  620. 48:52and so I we were it was very clear to us that we wanted to do this and but also it became clear to us that we didn't want to just like keep working on this unless it could become big and we were starting to develop conviction conviction that this actually become really really big
  621. 49:05and so we we we did that and hired Buen and then became profitable later that year um and then just continued to hire and then it's like to raise more money, you need sort of
  622. 49:18there's six reasons to raise capital.
  623. 49:20The first reason to raise capital is to fund R&D.
  624. 49:23Mhm.
  625. 49:24That was the reason that we raised capital in January because we funded R&D with a lot of our own, you know, opportunity cost and not taking a salary and then paying the bills ourselves.
  626. 49:33Um, but we wanted to learn a little bit faster and so we hired Buen and Morgan as the first engineers.
  627. 49:39And then the second reason to raise capital is to fund growth.
  628. 49:43you've you you've built something and you want to tell the world about it and you want to spend more capital to do that.
  629. 49:50Um the third reason to to to raise capital is for the founders's ego.
  630. 49:56[snorts]
  631. 49:56Um it's a very popular appreciate the honesty.
  632. 49:59It's very popular, very very popular, right?
  633. 50:01big numbers, lots of press, like um and I think this is a very very dangerous reason to raise money.
  634. 50:08And I wish that it was more talked about because you're diluting all of your employees when you do it.
  635. 50:14You are um setting a certain price for future employees and their upside.
  636. 50:19It's it's it for some people it can become a status game and that's not what it's about.
  637. 50:24We're here to build a big business together and this is not a reason to raise money.
  638. 50:30Um, but I I do think that it happens.
  639. 50:33Um, the fourth reason to to to raise capital is to reward your employees, right?
  640. 50:37It's a 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.
  641. 50:44So, you want to reward them.
  642. 50:46Um, that was the reason that we took more capital in December um was to allow the employees to liquidate as some of their equity um instead of waiting for some like event like an IPO or something like further out.
  643. 50:58Um the fifth reason to raise is for a strategic partnership.
  644. 51:01There are strategic partnerships that have been made in this in this city that have made companies.
  645. 51:06Um and um the six reason to raise would be do doing M&A or or something like that.
  646. 51:13But it's like you have to be very honest about what reason you are raising in those six.
  647. 51:18First reason we raised was one and second reason we raised was four.
  648. 51:22Um so which which ones?
  649. 51:23The first reason to raise was R&D.
  650. 51:25R&D and the second reason was
  651. 51:27um to provide liquidity to the employees
  652. 51:29employees.
  653. 51:30Yep.
  654. 51:31I I think it's a 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
  655. 51:40to tech ecosystems where a lot of people are raising it it will be part of it.
  656. 51:45As closing I I wanted to ask you about the way you have a remote culture these days.
  657. 51:51I'm seeing it especially for companies that do anything with AI, may that be building AI infra or or or just AI products.
  658. 51:59A lot of them prefer in person having a HQ often times in SF or wherever your headquarters may that be London or somewhere else because you often these companies often find that they have faster iteration.
  659. 52:11Uh it's just fewer layers cut in between and of course speed is is very very important.
  660. 52:15You have started full remote and you're still full remote.
  661. 52:18how is it working?
  662. 52:21Uh, and what kind of quirks or like or turbo ways have you found to to make this work better?
  663. 52:28Yeah, I think so.
  664. 52:30The the company started in in 23.
  665. 52:33So, sort of like on the on the on the cusp of COVID where a lot of companies were just remote.
  666. 52:37Um, the Shopify infra was remote since the very um very beginning because it was very difficult to get them all to move to Ottawa.
  667. 52:44Um, and so it was natural to me.
  668. 52:49It's like, okay, I think there's kind of maybe two cities where you can build a database company fast, and that's San Francisco and and and maybe New York.
  669. 52:57There are maybe other cities, right?
  670. 52:58But that's like kind of where it's been done.
  671. 53:00Yeah.
  672. 53:00And so if you don't want to do that, I think you have to go all in on on on some distributed model.
  673. 53:05And so we've tried to figure out what does that distributed model mean for Turppuffer?
  674. 53:09It doesn't mean the absence of in person.
  675. 53:10we get everyone together twice a year in in some in in some location.
  676. 53:15Uh earlier this year we were in in B, right?
  677. 53:17And then we were in Mexico City and so on.
  678. 53:18So it's like that's that's not that uncommon.
  679. 53:21Um but one of the things that we we we've been trying to do is we have this concept called campfires.
  680. 53:26And 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.
  681. 53:36So, 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.
  682. 53:42And so, everyone is invited to come.
  683. 53:44Like, we're going to go meet customers, right?
  684. 53:45We're going to put on dinners for our customers and things like that.
  685. 53:48And we just make a thing out of it and and spend time together.
  686. 53:51And uh we encourage everyone to come.
  687. 53:54We'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.
  688. 54:02Some people just want to, you know, lock in and hacks into tent and that's great.
  689. 54:06We 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.
  690. 54:13Um, fantastic.
  691. 54:14Like that is completely compatible with this model.
  692. 54:17And there are other people at the company who are on a plane probably every two weeks.
  693. 54:20Um, 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
  694. 54:33[laughter]
  695. 54:33flew to New York to hang out with the team, right?
  696. 54:35And I think that's fantastic.
  697. 54:37Um 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 Turbop or something a bit extracurricular,
  698. 54:48we give you a turbo credit and a turbo credit allows you to upgrade your next flight to business class which again encourages spending time together with the team.
  699. 54:58Um and now I mean turbo credits are probably going to take on a life of their own.
  700. 55:03Someone was talking about doing a central bank and doing interest rates on the turbo credits.
  701. 55:06um and doing a betting market on the turbo credits.
  702. 55:09And so like this might take on its life on its own.
  703. 55:12Um 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.
  704. 55:26And so if you do that for two days because you want to do it, oh, you get a turbo credit, right?
  705. 55:30And 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.
  706. 55:36Well, in this session, uh, what I found very interesting is Turbopuffer is a 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,
  707. 55:50pushing, being curious, and the human connection, how important it is for people to work together, to trust each other.
  708. 55:56So, just thank you very much for that.
  709. 55:58So, let's give a big round of applause for Simon.
  710. 56:00Thank you so much.
  711. 56:02This is great.
  712. 56:02Thank you.
  713. 56:05Are you
  714. 56:25[music]