WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=jQDXzEVHMSE

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/jQDXzEVHMSE.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:24.720 --> 00:00:26.800
All right.

s3
00:00:26.880 --> 00:00:38.719
It'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

s4
00:00:38.719 --> 00:00:51.920
CEO 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?

s5
00:00:52.160 --> 00:00:54.399
um through PowerPoint.

s6
00:00:54.399 --> 00:01:03.840
PowerPoint 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

s7
00:01:03.840 --> 00:01:18.880
go 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.

s8
00:01:18.880 --> 00:01:19.840
Do you remember Front Page?

s9
00:01:19.840 --> 00:01:20.880
Yeah, I remember Front Page.

s10
00:01:20.880 --> 00:01:25.840
It it it was supposed to eliminate the need for all any front-end developers.

s11
00:01:25.840 --> 00:01:26.400
Exactly.

s12
00:01:26.400 --> 00:01:29.520
And it it only worked in Internet Explorer.

s13
00:01:29.520 --> 00:01:36.320
I 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.

s14
00:01:36.320 --> 00:01:51.920
And 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

s15
00:01:51.920 --> 00:01:55.439
uh different things and then it just sort of escalated from there.

s16
00:01:55.439 --> 00:02:01.119
Then you upgrade to Dreamweaver and now you're coding and then you're like well how do you make the pages dynamically?

s17
00:02:01.119 --> 00:02:09.039
you learn PHP and then for me I exhausted the internet on Danish language programming advice.

s18
00:02:09.039 --> 00:02:09.599
Mhm.

s19
00:02:09.599 --> 00:02:19.516
Um 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.

s20
00:02:19.516 --> 00:02:21.120
[laughter]

s21
00:02:21.120 --> 00:02:24.000
So you kind of start hacking get into deeper.

s22
00:02:24.000 --> 00:02:30.080
Now the logical step would have been to just you know go to university and learn properly about this stuff.

s23
00:02:30.080 --> 00:02:33.760
But that's not what you did did you?

s24
00:02:33.760 --> 00:02:44.319
I 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

s25
00:02:44.319 --> 00:02:45.200
of the web.

s26
00:02:45.200 --> 00:02:52.560
I 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.

s27
00:02:52.560 --> 00:02:54.239
Um, so that would have been very interesting.

s28
00:02:54.239 --> 00:02:55.760
Maybe I would have been better at programming.

s29
00:02:55.760 --> 00:02:57.040
That would have been nice.

s30
00:02:57.040 --> 00:02:58.720
And then I Yeah.

s31
00:02:58.720 --> 00:03:02.080
Then I just started picking up jobs and things like that throughout high school.

s32
00:03:02.080 --> 00:03:07.840
And when I was in high school as well, I got exposed to this thing called the International Olympiad in Informatics.

s33
00:03:07.840 --> 00:03:08.720
You heard of this thing?

s34
00:03:08.720 --> 00:03:09.440
Yeah.

s35
00:03:09.440 --> 00:03:21.680
Um, 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.

s36
00:03:21.680 --> 00:03:31.920
And 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

s37
00:03:31.920 --> 00:03:34.480
were like the algorithmicalish programs.

s38
00:03:34.480 --> 00:03:35.040
Exactly.

s39
00:03:35.040 --> 00:03:42.480
It'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

s40
00:03:42.480 --> 00:03:55.120
you 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

s41
00:03:55.120 --> 00:04:03.439
do 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

s42
00:04:03.439 --> 00:04:04.959
um and so I started doing that.

s43
00:04:04.959 --> 00:04:10.319
In high school, I was working um I was working as well um for a startup.

s44
00:04:10.319 --> 00:04:17.040
Um and then I just Shopify found me while I was still in high school.

s45
00:04:17.040 --> 00:04:20.959
And and the whole like Shopify found me, was it through your open source contributions?

s46
00:04:20.959 --> 00:04:23.360
Was it was it something else?

s47
00:04:23.360 --> 00:04:37.440
It 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.

s48
00:04:37.440 --> 00:04:44.080
It 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.

s49
00:04:44.080 --> 00:04:47.040
And so I went back to one of these old Nokia brick phones.

s50
00:04:47.040 --> 00:04:48.960
And this is back in 2013.

s51
00:04:48.960 --> 00:04:53.040
And people hadn't really realized all the pernicious effects of smartphones at the time.

s52
00:04:53.040 --> 00:04:59.919
And so I wrote this article about how oh my god I'm like calling people and I have my sense of direction back.

s53
00:04:59.919 --> 00:05:01.520
Um and I wrote an article about it.

s54
00:05:01.520 --> 00:05:07.680
And this article it went on hacker news briefly and it um New York Times decided to feature it.

s55
00:05:07.680 --> 00:05:08.479
No way.

s56
00:05:08.479 --> 00:05:08.880
Yeah.

s57
00:05:08.880 --> 00:05:23.440
And 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

s58
00:05:23.440 --> 00:05:25.199
um but I had a great call with them.

s59
00:05:25.199 --> 00:05:28.160
They invited me on site to Ottawa, Canada.

s60
00:05:28.160 --> 00:05:30.560
Um I had no idea what Ottawa Canada is.

s61
00:05:30.560 --> 00:05:33.440
I think the email says something like what's an Ottawa?

s62
00:05:33.440 --> 00:05:34.880
I had no idea.

s63
00:05:34.880 --> 00:05:42.479
Um, and so I went there and it was just like walked into the building and it was just a just felt right.

s64
00:05:42.479 --> 00:05:51.360
Um, 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."

s65
00:05:51.360 --> 00:05:51.600
Yeah.

s66
00:05:51.600 --> 00:05:52.880
In 2013.

s67
00:05:52.880 --> 00:05:53.120
Yeah.

s68
00:05:53.120 --> 00:05:59.440
I think that's that's a like legit excuse for like not even worrying about college and and university.

s69
00:05:59.440 --> 00:06:01.039
But I did it crossed your mind.

s70
00:06:01.039 --> 00:06:01.520
It did.

s71
00:06:01.520 --> 00:06:04.319
I thought I was going I thought I was doing a gap year.

s72
00:06:04.319 --> 00:06:19.919
I 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

s73
00:06:19.919 --> 00:06:28.000
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."

s74
00:06:28.000 --> 00:06:41.199
So 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

s75
00:06:41.199 --> 00:06:49.120
mentions 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.

s76
00:06:49.120 --> 00:06:51.759
I don't think that's true but that's what I thought.

s77
00:06:51.759 --> 00:06:54.479
So I went and did that for everything that I encountered.

s78
00:06:54.479 --> 00:06:59.919
Um, so that was a really good crash course and then very quickly it became clear that well I just want to continue doing this.

s79
00:06:59.919 --> 00:07:06.560
I 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.

s80
00:07:06.560 --> 00:07:20.160
So 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?

s81
00:07:20.160 --> 00:07:22.160
Like they're they're leading.

s82
00:07:22.160 --> 00:07:28.639
So 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.

s83
00:07:28.639 --> 00:07:36.080
You 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.

s84
00:07:36.080 --> 00:07:52.720
I 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

s85
00:07:52.720 --> 00:08:03.199
layer 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.

s86
00:08:03.199 --> 00:08:07.360
I was so I just wanted to learn what it was when they were talking about a reverse proxy.

s87
00:08:07.360 --> 00:08:09.199
I'm like, why is it reverse?

s88
00:08:09.199 --> 00:08:12.479
I I still can't answer that.

s89
00:08:13.875 --> 00:08:15.360
[snorts]

s90
00:08:15.360 --> 00:08:17.150
I I I mean, okay,

s91
00:08:17.150 --> 00:08:18.080
[laughter]

s92
00:08:18.080 --> 00:08:22.240
you know, well, what's in reverse?

s93
00:08:22.240 --> 00:08:26.080
Because it's a proxy, right?

s94
00:08:26.479 --> 00:08:27.840
I don't I don't know.

s95
00:08:27.840 --> 00:08:28.479
I don't know.

s96
00:08:28.479 --> 00:08:29.840
It's like an inverted index.

s97
00:08:29.840 --> 00:08:30.720
Like what's inverted?

s98
00:08:30.720 --> 00:08:32.000
It's like it's a terrible name.

s99
00:08:32.000 --> 00:08:39.919
Anyway, 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.

s100
00:08:39.919 --> 00:08:41.039
But yeah, I hear you there.

s101
00:08:41.039 --> 00:09:00.880
There'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

s102
00:09:00.880 --> 00:09:03.040
it would have been hard to get it elsewhere.

s103
00:09:03.040 --> 00:09:03.360
Yeah.

s104
00:09:03.360 --> 00:09:12.399
So 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

s105
00:09:12.399 --> 00:09:22.000
and 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

s106
00:09:22.000 --> 00:09:33.680
we 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%

s107
00:09:33.680 --> 00:09:34.880
year-over-year.

s108
00:09:34.880 --> 00:09:40.080
Um, and so every year we were just preparing for a Black Friday that was going to be a lot worse than the last.

s109
00:09:40.080 --> 00:09:43.040
And this is back in the day of we're buying physical hardware, right?

s110
00:09:43.040 --> 00:09:47.440
We have to like place an order at a particular point in time and do some interpolation based on that.

s111
00:09:47.440 --> 00:09:49.360
Um, and the software also had to scale.

s112
00:09:49.360 --> 00:09:56.160
And when you're scaling most software, a lot of the application layer problems end up back at the database layer.

s113
00:09:56.160 --> 00:10:01.680
And so I just naturally found myself at this layer between Rails and the databases.

s114
00:10:01.680 --> 00:10:08.080
Shopify didn't at the time at least contribute many patches to the databases themselves but mostly just spent time orchestrating.

s115
00:10:08.080 --> 00:10:16.480
So we were doing sharding because as um my my dear boss Camilo used to say you can't cache rights.

s116
00:10:16.480 --> 00:10:22.399
So there's a fundamental point where you you just you have to move beyond a single shard.

s117
00:10:22.399 --> 00:10:31.279
Um 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.

s118
00:10:31.279 --> 00:10:38.720
uh and very but it worked and then the the subsequent years we worked on things like going into multiple data centers.

s119
00:10:38.720 --> 00:10:44.720
We also had this big mysterious reddish server that was like you know 128 GB of RAM which was a lot at the time.

s120
00:10:44.720 --> 00:10:52.399
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.

s121
00:10:52.399 --> 00:10:55.440
Um because people had just been treating it as this KV store.

s122
00:10:55.440 --> 00:10:57.440
Um and so we started splitting it out.

s123
00:10:57.440 --> 00:11:12.160
We 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.

s124
00:11:12.160 --> 00:11:13.760
But that's kind of the default failure mode, right?

s125
00:11:13.760 --> 00:11:15.279
You're not going to rescue all of that.

s126
00:11:15.279 --> 00:11:18.959
Um unless you're in a programming language that really forces that decision.

s127
00:11:18.959 --> 00:11:27.360
So we did things like um build this matrix out of okay well this service when this component is down should act this way.

s128
00:11:27.360 --> 00:11:31.440
Um and I found myself writing the test suite for a bunch of that.

s129
00:11:31.440 --> 00:11:33.920
And then I was like okay well we can't just mock all of this.

s130
00:11:33.920 --> 00:11:40.160
And 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

s131
00:11:40.160 --> 00:11:47.920
and then into the process and then close the file descriptor to the database to simulate the through the entire layer that the database fails.

s132
00:11:47.920 --> 00:11:58.160
That 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.

s133
00:11:58.160 --> 00:12:02.800
So then I moved on to create this proxy called Toxyroxy and

s134
00:12:02.800 --> 00:12:03.760
have you heard of this before?

s135
00:12:03.760 --> 00:12:04.399
No. No.

s136
00:12:04.399 --> 00:12:04.640
Yeah.

s137
00:12:04.640 --> 00:12:14.160
Toxyroxy 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.

s138
00:12:14.160 --> 00:12:24.079
So 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

s139
00:12:24.079 --> 00:12:36.800
um 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

s140
00:12:36.800 --> 00:12:49.360
so 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.

s141
00:12:49.360 --> 00:12:58.079
So 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.

s142
00:12:58.079 --> 00:12:58.480
Exactly.

s143
00:12:58.480 --> 00:13:11.920
So 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

s144
00:13:11.920 --> 00:13:21.360
tens 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

s145
00:13:21.360 --> 00:13:26.399
you're focused on just getting back up and not like what could the application actually have done.

s146
00:13:26.399 --> 00:13:27.440
Yeah, it's interesting.

s147
00:13:27.440 --> 00:13:37.680
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

s148
00:13:37.680 --> 00:13:41.600
and I never connected until now that I mean state is usually there's a database.

s149
00:13:41.600 --> 00:13:51.920
If 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.

s150
00:13:51.920 --> 00:13:54.480
But basically, like if we have state, we typically have databases.

s151
00:13:54.480 --> 00:14:04.320
is 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

s152
00:14:04.320 --> 00:14:10.880
simulate problems happening ahead of time unless when they happen so did you it sounds like you have pretty good success with

s153
00:14:10.880 --> 00:14:21.279
yeah 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

s154
00:14:21.279 --> 00:14:29.920
um 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.

s155
00:14:29.920 --> 00:14:32.160
So you spent eight years in total at at Shopify.

s156
00:14:32.160 --> 00:14:36.639
So like starting from like all right just a gap year it just went on a year a year and another year.

s157
00:14:36.639 --> 00:14:44.639
Um at what point did you think about leaving and why and what was your kind of decision framework?

s158
00:14:44.639 --> 00:14:49.199
It sounds like you or you were like on Epic right now even today Shopify it's doing wonderful.

s159
00:14:49.199 --> 00:14:52.959
It's probably doing even way better than like like you know that growth kind of kept on.

s160
00:14:52.959 --> 00:14:56.639
So I'm sure there would have been an argument to stay and you know stay on their August ship.

s161
00:14:56.639 --> 00:14:56.880
Yeah.

s162
00:14:56.880 --> 00:15:02.079
So I I spent I spent eight years there from 13 to to 21.

s163
00:15:02.079 --> 00:15:08.720
Um and I I think there just came a point where I wanted to see something different again.

s164
00:15:08.720 --> 00:15:11.360
I've been inside of Shopify since I was 18 years old, right?

s165
00:15:11.360 --> 00:15:14.000
I'd been seen one other startup in high school.

s166
00:15:14.000 --> 00:15:20.800
I was like if I want to learn more about computers and learn faster, it might be time to inject some novelty into this function.

s167
00:15:20.800 --> 00:15:28.480
Um, and so I I left in in in 21 and I'd worked on so many different parts of the infrastructure like caching.

s168
00:15:28.480 --> 00:15:38.160
Um, 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.

s169
00:15:38.160 --> 00:15:41.920
Um, we've worked on running Shopify in multiple data centers.

s170
00:15:41.920 --> 00:15:47.279
We've worked on so many database scaling projects like caching, all of these different things, right?

s171
00:15:47.279 --> 00:15:54.800
Um, 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.

s172
00:15:54.800 --> 00:15:57.440
Um, but that's that's eventually how I left.

s173
00:15:57.440 --> 00:16:00.800
And so when I left, I didn't really know what I wanted to do.

s174
00:16:00.800 --> 00:16:06.639
And so I one of the projects I had while I was at Shopify was this napkin math project.

s175
00:16:06.639 --> 00:16:07.279
Have you seen this

s176
00:16:07.279 --> 00:16:07.920
napkin math?

s177
00:16:07.920 --> 00:16:08.160
No.

s178
00:16:08.160 --> 00:16:21.120
No. 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

s179
00:16:21.120 --> 00:16:29.759
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?

s180
00:16:29.759 --> 00:16:36.560
Just a collection of probably there's probably like 50 of these numbers and then a RS script that generates them all.

s181
00:16:36.560 --> 00:16:38.240
um what all these things cost?

s182
00:16:38.240 --> 00:16:38.959
What do you like?

s183
00:16:38.959 --> 00:16:40.320
What does a gigabyte of memory cost?

s184
00:16:40.320 --> 00:16:40.720
$2.

s185
00:16:40.720 --> 00:16:42.160
What does a gigabyte of S3 cost?

s186
00:16:42.160 --> 00:16:42.560
2 cents.

s187
00:16:42.560 --> 00:16:45.279
What does a gigabyte of um this cost?

s188
00:16:45.279 --> 00:16:46.079
10 cents, right?

s189
00:16:46.079 --> 00:16:47.279
What does it cost on spot?

s190
00:16:47.279 --> 00:16:48.880
What does it cost on a three-year commit?

s191
00:16:48.880 --> 00:16:53.120
Like I had just have a massive table and then create flash cards for almost every single cell.

s192
00:16:53.120 --> 00:16:54.959
So I know all these numbers.

s193
00:16:54.959 --> 00:17:03.120
And 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?

s194
00:17:03.120 --> 00:17:14.799
So 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

s195
00:17:14.799 --> 00:17:31.280
but 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

s196
00:17:31.280 --> 00:17:43.919
this 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

s197
00:17:43.919 --> 00:18:02.559
you'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

s198
00:18:02.559 --> 00:18:03.919
one of us is wrong.

s199
00:18:03.919 --> 00:18:09.840
Either there's a gap in my understanding, which is very likely, or you would benchmark the wrong thing.

s200
00:18:09.840 --> 00:18:12.799
And in some ways, some reasons, right, it's like, okay, you've done a benchmark.

s201
00:18:12.799 --> 00:18:17.919
You don't didn't realize that your benchmark is doing a distributed query across a 100 different nodes.

s202
00:18:17.919 --> 00:18:21.440
And so, of course, the P99 is going to be really, really high, right?

s203
00:18:21.440 --> 00:18:24.400
Unless you've cut that off or or made some different set of trade-offs.

s204
00:18:24.400 --> 00:18:31.360
So I just found myself in these discussions repeatedly where people were making infrastructure decisions based on poor benchmarks.

s205
00:18:31.360 --> 00:18:37.919
And 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.

s206
00:18:37.919 --> 00:18:43.679
Um because I was always doing these like little demos or like writing little prototype scripts to to demonstrate this.

s207
00:18:43.679 --> 00:18:48.480
But it was just I just the argument of here's how a beach tree works.

s208
00:18:48.480 --> 00:18:50.160
This is how many pages we have to visit.

s209
00:18:50.160 --> 00:18:51.919
This is what a random SSD read takes.

s210
00:18:51.919 --> 00:18:53.039
It takes one millisecond.

s211
00:18:53.039 --> 00:18:58.720
you 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.

s212
00:18:58.720 --> 00:19:00.480
Well, like is the query plan correct?

s213
00:19:00.480 --> 00:19:01.760
Like is there a bug in my SQL?

s214
00:19:01.760 --> 00:19:02.799
Do we have bad discs?

s215
00:19:02.799 --> 00:19:04.880
Like what's the discrepancy here?

s216
00:19:04.880 --> 00:19:06.559
And I just got caught with that bug.

s217
00:19:06.559 --> 00:19:09.120
And so after I left Sha, I was just writing a lot of articles about this.

s218
00:19:09.120 --> 00:19:11.760
I was just like, well, how long does should this query take?

s219
00:19:11.760 --> 00:19:18.640
And then I one hypothesis I had at some point is like, okay, well, how many writes per second can MySQL do?

s220
00:19:18.640 --> 00:19:24.320
Well, shouldn't the amount of writes per second that MySQL do equal the amount of f-syncs that you can do per second?

s221
00:19:24.320 --> 00:19:25.520
That sort of makes sense, right?

s222
00:19:25.520 --> 00:19:28.720
Every time you do a write, you f-sync to persist to disk.

s223
00:19:28.720 --> 00:19:30.640
So, how many f-syncs can you do per second?

s224
00:19:30.640 --> 00:19:32.320
Well, an f-sync takes one millisecond.

s225
00:19:32.320 --> 00:19:33.679
So, you do a thousand writes per second.

s226
00:19:33.679 --> 00:19:34.960
That well, that doesn't really match up.

s227
00:19:34.960 --> 00:19:37.520
Like, feel like a database can do more than,000 rightes per second.

s228
00:19:37.520 --> 00:19:39.360
Why can it do that?

s229
00:19:39.360 --> 00:19:44.480
So, 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.

s230
00:19:44.480 --> 00:19:45.600
Well, how is that possible?

s231
00:19:45.600 --> 00:19:46.640
Mhm.

s232
00:19:46.640 --> 00:19:49.280
And now you would just ask how is it possible?

s233
00:19:49.280 --> 00:19:50.480
Because you batch.

s234
00:19:50.480 --> 00:19:53.840
So an f-sync happens on usually a 4K.

s235
00:19:53.840 --> 00:19:54.400
Yeah.

s236
00:19:54.400 --> 00:19:54.640
Right.

s237
00:19:54.640 --> 00:19:56.080
But it's like that's not intuitive.

s238
00:19:56.080 --> 00:19:58.080
Like it's actually I I I got caught.

s239
00:19:58.080 --> 00:20:05.919
It 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.

s240
00:20:05.919 --> 00:20:22.960
This 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

s241
00:20:22.960 --> 00:20:32.159
written 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.

s242
00:20:32.159 --> 00:20:33.360
I'm convinced.

s243
00:20:33.360 --> 00:20:35.360
Yeah.

s244
00:20:36.080 --> 00:20:40.320
And then you decided to start Turbopuffer.

s245
00:20:40.320 --> 00:20:40.720
Yeah.

s246
00:20:40.720 --> 00:20:42.720
Did h how did you decide?

s247
00:20:42.720 --> 00:20:48.320
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.

s248
00:20:48.320 --> 00:20:53.840
You you've done an awesome job benchmarking like what is the theoretical like limits?

s249
00:20:53.840 --> 00:20:59.919
You were very familiar with this probably became you know like world expert in in this niche.

s250
00:20:59.919 --> 00:21:02.320
And then how

s251
00:21:02.480 --> 00:21:05.760
did did you want to go into databases again?

s252
00:21:05.760 --> 00:21:11.039
I think it was there's three things that sort of came to a head.

s253
00:21:11.039 --> 00:21:16.880
Um the last project that I worked on at Shopify was search and I didn't have a good time.

s254
00:21:16.880 --> 00:21:18.880
What what what did you use back there?

s255
00:21:18.880 --> 00:21:34.640
Um 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

s256
00:21:34.640 --> 00:21:49.520
that 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

s257
00:21:49.520 --> 00:21:52.799
reading the source code of it and I was just I couldn't get it to track very often.

s258
00:21:52.799 --> 00:21:56.640
It was very difficult to operate and so I just that was sort of like in the back of my head.

s259
00:21:56.640 --> 00:21:58.240
I never thought I would touch that again.

s260
00:21:58.240 --> 00:22:10.640
Then 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

s261
00:22:10.640 --> 00:22:11.200
properly.

s262
00:22:11.200 --> 00:22:11.600
Yeah.

s263
00:22:11.600 --> 00:22:25.360
And 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

s264
00:22:25.360 --> 00:22:32.559
instead 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

s265
00:22:32.559 --> 00:22:46.240
this 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.

s266
00:22:46.240 --> 00:22:48.080
So you had to reach for search very quickly.

s267
00:22:48.080 --> 00:22:49.440
So it's like a few kilobytes.

s268
00:22:49.440 --> 00:22:52.080
It was eight kilobytes or four kilobytes depending on the model.

s269
00:22:52.080 --> 00:22:52.960
It was very very small.

s270
00:22:52.960 --> 00:22:54.799
So you had to reach for search very quickly.

s271
00:22:54.799 --> 00:22:55.360
Right.

s272
00:22:55.360 --> 00:22:56.480
And

s273
00:22:56.480 --> 00:23:04.080
so 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.

s274
00:23:04.080 --> 00:23:11.440
Um, 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.

s275
00:23:11.440 --> 00:23:14.159
Um, like it was it was it it

s276
00:23:14.159 --> 00:23:14.880
weird but

s277
00:23:14.880 --> 00:23:15.679
it was recommending.

s278
00:23:15.679 --> 00:23:15.919
Yeah.

s279
00:23:15.919 --> 00:23:21.200
I mean it was just like you know he was reading about like and I did get permission.

s280
00:23:21.200 --> 00:23:32.320
I 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.

s281
00:23:32.320 --> 00:23:33.440
This is a company called Readwise.

s282
00:23:33.440 --> 00:23:36.960
So it's like articles that you save and then and insert later.

s283
00:23:36.960 --> 00:23:39.520
And it was going to cost 30 grand a month.

s284
00:23:39.520 --> 00:23:40.400
And this was a company.

s285
00:23:40.400 --> 00:23:42.159
It's a bootstrap Canadian company.

s286
00:23:42.159 --> 00:23:47.760
They spend about five they at the time they were spending about 5k a month on all the other infrastructure combined.

s287
00:23:47.760 --> 00:23:57.760
So 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.

s288
00:23:57.760 --> 00:23:59.840
Um and so we just didn't ship it.

s289
00:23:59.840 --> 00:24:10.480
I 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

s290
00:24:10.480 --> 00:24:25.440
all 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

s291
00:24:25.440 --> 00:24:31.440
one day I just kind of said [ __ ] it and did it and like sat down and started started to like to write it out.

s292
00:24:31.440 --> 00:24:40.960
Um, 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.

s293
00:24:40.960 --> 00:24:41.520
Um,

s294
00:24:41.520 --> 00:24:46.080
because the problem with S3 is it has really good durability, but latency we're talking hundreds of milliseconds, right?

s295
00:24:46.080 --> 00:24:46.320
Yes.

s296
00:24:46.320 --> 00:24:56.159
The P99 on a uh 256 or 512 kilobyte object on S3 um is around 200 milliseconds.

s297
00:24:56.159 --> 00:24:56.480
Um,

s298
00:24:56.480 --> 00:25:01.200
and and you're saying P99 because like when you're talking large scale, you want to care about the P99, right?

s299
00:25:01.200 --> 00:25:01.279
Yeah.

s300
00:25:01.279 --> 00:25:01.919
I think when you're

s301
00:25:01.919 --> 00:25:03.679
That's why we're not talking about P50.

s302
00:25:03.679 --> 00:25:06.400
When you're designing a system, you want to optimize for the P99.

s303
00:25:06.400 --> 00:25:12.320
And especially because when you're designing a system on on S3, generally in every roundtrip, you're not doing one request.

s304
00:25:12.320 --> 00:25:14.080
You're often doing lots of requests, right?

s305
00:25:14.080 --> 00:25:15.760
You're going to hit the P99 real quick.

s306
00:25:15.760 --> 00:25:16.080
Exactly.

s307
00:25:16.080 --> 00:25:18.320
So, it's like if you're navigating a tree on S3, right?

s308
00:25:18.320 --> 00:25:20.960
It's like, okay, you get the upper layer of the tree 200 milliseconds.

s309
00:25:20.960 --> 00:25:23.200
You get like another layer of the tree 200 milliseconds.

s310
00:25:23.200 --> 00:25:25.200
You get a bunch of leaves of the tree in 200 millonds.

s311
00:25:25.200 --> 00:25:35.440
So 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.

s312
00:25:35.440 --> 00:25:46.159
So, 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

s313
00:25:46.159 --> 00:25:56.720
end 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.

s314
00:25:56.720 --> 00:26:02.159
And then you kind of you built it on on top of S3 because I guess durability and and all of and just really good.

s315
00:26:02.159 --> 00:26:04.799
How did you make it fast?

s316
00:26:05.200 --> 00:26:07.679
We didn't in the beginning or I didn't in the beginning.

s317
00:26:07.679 --> 00:26:12.640
Um it was just me at the time and it was really like it was it was it was a project.

s318
00:26:12.640 --> 00:26:14.159
It was not a company.

s319
00:26:14.159 --> 00:26:15.760
It was not

s320
00:26:15.760 --> 00:26:18.880
it was it was it was to satisfy a curiosity.

s321
00:26:18.880 --> 00:26:26.159
It 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.

s322
00:26:26.159 --> 00:26:32.240
Like I was like I just had to do this thing and I was so focused on doing it.

s323
00:26:32.240 --> 00:26:38.880
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.

s324
00:26:38.880 --> 00:26:42.159
And so the first version was the simplest possible thing.

s325
00:26:42.159 --> 00:26:48.640
I think I'm a very pragmatic person like I I didn't get buried.

s326
00:26:48.640 --> 00:26:52.000
I barely read any like of the literature on LSM.

s327
00:26:52.000 --> 00:26:57.600
I 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.

s328
00:26:57.600 --> 00:26:59.840
It was the simplest possible version of what it could be.

s329
00:26:59.840 --> 00:27:06.960
Like really what you have to imagine is that the simplest way you could do this is you run some clustering algorithm on the vectors.

s330
00:27:06.960 --> 00:27:09.760
You get the clusters and then you put the clusters in files.

s331
00:27:09.760 --> 00:27:19.200
The 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

s332
00:27:19.200 --> 00:27:23.120
looking at the centrids and then downloading the n closest clusters.

s333
00:27:23.120 --> 00:27:33.360
There 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.

s334
00:27:33.360 --> 00:27:34.559
That was the first version.

s335
00:27:34.559 --> 00:27:36.000
And then how do we make it fast?

s336
00:27:36.000 --> 00:27:39.120
Well, I didn't even implement a caching layer.

s337
00:27:39.120 --> 00:27:43.760
I just put the reverse proxy in front of S3 with Engine X and then had it

s338
00:27:43.760 --> 00:27:44.880
know what a reverse proxy is.

s339
00:27:44.880 --> 00:27:47.600
I like I do know what it is.

s340
00:27:47.600 --> 00:27:50.000
I just still don't know what what the reverse is about.

s341
00:27:50.000 --> 00:27:56.240
But anyway, um the reverse the reverse proxy reverse things.

s342
00:27:56.240 --> 00:28:03.760
Um 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.

s343
00:28:03.760 --> 00:28:07.039
It again it was the simplest like it's like I'm just going to put that in front.

s344
00:28:07.039 --> 00:28:15.679
I knew how to configure engine X like I've written more enginex Lua than u than a lot of engineext Lua very good software.

s345
00:28:15.679 --> 00:28:27.600
um 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

s346
00:28:27.600 --> 00:28:28.960
server in a T-Ox instance.

s347
00:28:28.960 --> 00:28:31.760
I was like okay let's see if anyone gives a [ __ ] Yeah.

s348
00:28:31.760 --> 00:28:40.080
So 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.

s349
00:28:40.080 --> 00:28:41.679
How did cursor come into play?

s350
00:28:41.679 --> 00:28:59.760
Because 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.

s351
00:28:59.760 --> 00:29:00.720
It didn't even work that well.

s352
00:29:00.720 --> 00:29:05.840
They went to AWS Aurora, which is managed service of Postgress, and it didn't work well, which is very surprising.

s353
00:29:05.840 --> 00:29:06.559
And they're like, "Oh, yeah."

s354
00:29:06.559 --> 00:29:09.679
And then we went to this thing called Turbopuffer, and they worked well.

s355
00:29:09.679 --> 00:29:11.600
And I was like, what's turbuffer?

s356
00:29:11.600 --> 00:29:13.279
And they're like, oh yeah, turbopuffer.

s357
00:29:13.279 --> 00:29:15.679
I think I think they said like we were one of their first customers.

s358
00:29:15.679 --> 00:29:17.360
And this never computed to me.

s359
00:29:17.360 --> 00:29:19.840
Curser was already massive at that point.

s360
00:29:19.840 --> 00:29:21.760
How did you meet the folks?

s361
00:29:21.760 --> 00:29:24.960
And how did they become would were they the first customer?

s362
00:29:24.960 --> 00:29:26.080
One of the first.

s363
00:29:26.080 --> 00:29:27.200
They were the first customer.

s364
00:29:27.200 --> 00:29:27.760
The first

s365
00:29:27.760 --> 00:29:28.559
the first.

s366
00:29:28.559 --> 00:29:29.440
No.

s367
00:29:29.440 --> 00:29:35.840
Um they they they reached out um after I just launched on on Twitter.

s368
00:29:35.840 --> 00:29:37.039
I was like, "Hey, I built this thing."

s369
00:29:37.039 --> 00:29:49.440
And 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

s370
00:29:49.440 --> 00:29:51.520
I only want to work on this if anyone cares.

s371
00:29:51.520 --> 00:29:56.000
Let's put it on Twitter again single Tox instance on a 8 core node somewhere in GCP.

s372
00:29:56.000 --> 00:30:02.480
I 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.

s373
00:30:02.480 --> 00:30:04.480
It was like the MVP of MVP.

s374
00:30:04.480 --> 00:30:14.320
Anyone who's actually worked in the internal on databases would never have had like would have had too much pride to ship anything like that.

s375
00:30:14.320 --> 00:30:18.320
Um, and I've just, you know, I've worked on I was just releasing it like a SAS project.

s376
00:30:18.320 --> 00:30:20.240
Why can't you work on a database like it's SAS?

s377
00:30:20.240 --> 00:30:22.799
I don't, you know, it's like if anyone uses it, we'll do it properly.

s378
00:30:22.799 --> 00:30:25.440
I know how to run software with a lot of nines.

s379
00:30:25.440 --> 00:30:30.720
Um, but it was not a proper LSN like it was very very it was the simplest version of what it could be.

s380
00:30:30.720 --> 00:30:32.720
And then I released on Twitter.

s381
00:30:32.720 --> 00:30:34.799
I was like, "Yeah, you could do a million vectors for a dollar."

s382
00:30:34.799 --> 00:30:39.200
And before that, I think the the cheapest was maybe $100 per million for something that actually worked.

s383
00:30:39.200 --> 00:30:39.840
Yeah.

s384
00:30:39.840 --> 00:30:41.760
Um, and I knew it was reliable, right?

s385
00:30:41.760 --> 00:30:50.640
I 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.

s386
00:30:50.640 --> 00:31:05.840
Um 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

s387
00:31:05.840 --> 00:31:14.159
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

s388
00:31:14.159 --> 00:31:18.080
and everything else just sit in opic stores and then we just hotload it in and out of the cache

s389
00:31:18.080 --> 00:31:23.600
makes 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.

s390
00:31:23.600 --> 00:31:24.960
It made so much sense.

s391
00:31:24.960 --> 00:31:35.120
So 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

s392
00:31:35.120 --> 00:31:36.640
um the economics

s393
00:31:36.640 --> 00:31:42.640
yeah 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

s394
00:31:42.640 --> 00:31:56.240
and 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

s395
00:31:56.240 --> 00:31:57.279
Harvey's head.

s396
00:31:57.279 --> 00:32:03.679
Um, but it pattern matched something and so we exchanged a bunch of emails and then something compelled.

s397
00:32:03.679 --> 00:32:05.600
I didn't know anything about B2B sales.

s398
00:32:05.600 --> 00:32:07.360
Now I love B2B sales.

s399
00:32:07.360 --> 00:32:08.640
Um, I didn't know anything.

s400
00:32:08.640 --> 00:32:13.760
I was just like I just want to help them cuz they they were they had some unit economics that didn't line up.

s401
00:32:13.760 --> 00:32:15.279
So I just went to San Francisco, right?

s402
00:32:15.279 --> 00:32:16.000
I live in Canada.

s403
00:32:16.000 --> 00:32:23.600
I 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.

s404
00:32:23.600 --> 00:32:25.279
Yeah, the AWS aurora problems.

s405
00:32:25.279 --> 00:32:25.679
Yes.

s406
00:32:25.679 --> 00:32:26.000
Yeah.

s407
00:32:26.000 --> 00:32:26.880
Early on.

s408
00:32:26.880 --> 00:32:29.760
And I was like, "Oh, do you guys have PG analyze?"

s409
00:32:29.760 --> 00:32:31.200
And they said, "Oh, no, we don't."

s410
00:32:31.200 --> 00:32:33.519
I let's let's get that going, right?

s411
00:32:33.519 --> 00:32:34.559
Let's look at it.

s412
00:32:34.559 --> 00:32:43.279
And 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.

s413
00:32:43.279 --> 00:32:44.960
So, we were talking about all of that.

s414
00:32:44.960 --> 00:32:46.320
And so, it's just helping them, right?

s415
00:32:46.320 --> 00:32:49.919
It was like my, you know, my database genes just like kicked in.

s416
00:32:49.919 --> 00:33:00.159
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.

s417
00:33:00.159 --> 00:33:08.399
And um at this time I'd also approached who I thought was the best engineer who ever worked at Shopify, my co-founder Justine.

s418
00:33:08.399 --> 00:33:21.039
um 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

s419
00:33:21.039 --> 00:33:33.039
um 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

s420
00:33:33.039 --> 00:33:40.080
um but cursor was a small company back then right yeah and they were they just in the beginning of their massive rapid growth.

s421
00:33:40.080 --> 00:33:40.720
Exactly.

s422
00:33:40.720 --> 00:33:45.279
And I I told them that I was going to reduce their bill by 95%.

s423
00:33:45.279 --> 00:33:47.120
And I did like we did.

s424
00:33:47.120 --> 00:33:48.159
Justine and I did.

s425
00:33:48.159 --> 00:33:56.080
We like they came on and their last bill with their previous vendor and the first bill with us, it was 95% lower.

s426
00:33:56.080 --> 00:33:56.240
Yeah.

s427
00:33:56.240 --> 00:34:01.440
And 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.

s428
00:34:01.440 --> 00:34:04.080
It was it was a it was Aurora specifically.

s429
00:34:04.080 --> 00:34:04.960
Uh so

s430
00:34:04.960 --> 00:34:06.880
this was this was not this was not Postgress.

s431
00:34:06.880 --> 00:34:08.399
No, this was a

s432
00:34:08.399 --> 00:34:10.159
it was a different one, but it's probably still in the write up.

s433
00:34:10.159 --> 00:34:17.359
We 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.

s434
00:34:17.359 --> 00:34:30.879
I'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

s435
00:34:30.879 --> 00:34:33.520
except for Turbopuffer and he said I love love those guys.

s436
00:34:33.520 --> 00:34:41.520
So 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

s437
00:34:41.520 --> 00:34:55.440
highquality 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

s438
00:34:55.440 --> 00:35:07.280
by 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.

s439
00:35:07.280 --> 00:35:09.359
They probably never done that.

s440
00:35:09.359 --> 00:35:13.520
So, fast forward today, uh, Turbopuffer is now a lot bigger.

s441
00:35:13.520 --> 00:35:22.480
You're you're working on some some some cool things, but you have this very interesting business where for you CPUs are important, right?

s442
00:35:22.480 --> 00:35:24.800
You run on mostly CPUs.

s443
00:35:24.800 --> 00:35:34.160
And you told me a story over dinner yesterday that uh you met Jensen uh and Jensen he really wanted to sell you on GPUs.

s444
00:35:34.160 --> 00:35:36.240
Can you tell me how that meeting went?

s445
00:35:36.240 --> 00:35:38.320
Um yeah, Jensen Hong, right?

s446
00:35:38.320 --> 00:35:38.960
Yeah.

s447
00:35:38.960 --> 00:35:42.800
I just I never met uh I'd never met uh Jensen before.

s448
00:35:42.800 --> 00:35:49.440
We were we were at an event at uh at at Nvidia and we were just doing um presentations in a big HQ.

s449
00:35:49.440 --> 00:35:50.079
Super impressive.

s450
00:35:50.079 --> 00:35:50.480
Yeah, exactly.

s451
00:35:50.480 --> 00:35:59.440
they'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.

s452
00:35:59.440 --> 00:36:03.599
And I I don't I I don't know.

s453
00:36:03.599 --> 00:36:05.760
I was like I think I was in a goofy mood that day.

s454
00:36:05.760 --> 00:36:12.400
And so I went up on on stage and I said, "Um, hey, I'm Simon from from Turbopuffer."

s455
00:36:12.400 --> 00:36:19.680
And uh and yeah, if you're wondering about the name, it's like if everything goes south, we can always pivot into vapes.

s456
00:36:20.520 --> 00:36:21.359
[laughter]

s457
00:36:21.359 --> 00:36:27.359
I was kind of nervous and this is what I this is what I said and then and then he said back to

s458
00:36:27.359 --> 00:36:28.079
wait who was in the room?

s459
00:36:28.079 --> 00:36:28.720
Was it Jensen?

s460
00:36:28.720 --> 00:36:29.680
Was it a direct report?

s461
00:36:29.680 --> 00:36:41.520
It 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?

s462
00:36:41.520 --> 00:36:45.920
Um cuz you go there and then you talk about that you find opportunities to partner and work together, right?

s463
00:36:45.920 --> 00:36:52.400
And so I said, "Yeah, you know, so plan B could be that we could pivot into vapes."

s464
00:36:52.400 --> 00:36:55.440
And then he said, I was already nervous.

s465
00:36:55.440 --> 00:37:01.280
He said, "Judging by your slide, maybe you should."

s466
00:37:01.785 --> 00:37:02.640
[laughter]

s467
00:37:02.640 --> 00:37:05.440
No, he did not.

s468
00:37:07.280 --> 00:37:08.990
And and

s469
00:37:08.990 --> 00:37:10.079
[gasps]

s470
00:37:10.079 --> 00:37:12.720
I didn't know what to say back to that.

s471
00:37:12.720 --> 00:37:17.520
So I said, "Well, Jensen, do you vape?"

s472
00:37:20.125 --> 00:37:20.780
[snorts]

s473
00:37:20.780 --> 00:37:22.640
[laughter]

s474
00:37:22.640 --> 00:37:26.000
He didn't he didn't answer the question.

s475
00:37:26.020 --> 00:37:26.320
[laughter]

s476
00:37:26.320 --> 00:37:39.359
And 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.

s477
00:37:39.520 --> 00:37:43.599
Um, and then you know this is this is a great start, right?

s478
00:37:43.599 --> 00:37:47.440
And um, and then the team had team team had sort of talked to me beforehand.

s479
00:37:47.440 --> 00:37:50.880
I was like, Simon, we got to make sure we don't say the C-word.

s480
00:37:50.880 --> 00:37:53.520
We can't say CPUs.

s481
00:37:55.280 --> 00:37:57.119
And so I just couldn't stop talking about CPUs.

s482
00:37:57.119 --> 00:38:00.079
I was like, AVX 512 is so sick.

s483
00:38:00.079 --> 00:38:05.920
Like we love SIMD and um, like we we we like there's so many CPUs.

s484
00:38:05.920 --> 00:38:07.119
They're so easy to get.

s485
00:38:07.119 --> 00:38:10.640
like um it's just a riot in CPU land.

s486
00:38:10.640 --> 00:38:15.801
Like you know I I don't I think I stopped short of saying I'm so glad I don't need GPUs.

s487
00:38:15.801 --> 00:38:15.839
[laughter]

s488
00:38:15.839 --> 00:38:21.599
But but it was just it I just couldn't stop talking about CPUs.

s489
00:38:21.599 --> 00:38:21.920
Yeah.

s490
00:38:21.920 --> 00:38:24.960
And so you know Jensen took an interest in that.

s491
00:38:24.960 --> 00:38:26.079
Yeah.

s492
00:38:26.079 --> 00:38:29.520
So who who knows like I'm sure you made you made a memorable impression.

s493
00:38:29.520 --> 00:38:33.359
Maybe he made it his mission now to like at some point get you guys onto GPUs.

s494
00:38:33.359 --> 00:38:39.280
But speaking of CPUs, can you tell me a bit what you're seeing inside of the hypers scale, the cloud providers?

s495
00:38:39.280 --> 00:38:42.400
You're now in AWS, you're you're in GCP, you're on Azure.

s496
00:38:42.400 --> 00:38:50.720
What 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.

s497
00:38:50.720 --> 00:38:53.599
I would think getting CPUs is should be easy.

s498
00:38:53.599 --> 00:38:54.320
Is it?

s499
00:38:54.320 --> 00:38:55.760
No,

s500
00:38:55.760 --> 00:38:57.040
it's not anymore.

s501
00:38:57.040 --> 00:38:57.440
Why?

s502
00:38:57.440 --> 00:38:58.000
What's happening?

s503
00:38:58.000 --> 00:39:01.200
Can you tell us about dynamics on on on the why and what you've learned?

s504
00:39:01.200 --> 00:39:01.680
Yeah.

s505
00:39:01.680 --> 00:39:07.280
So, I think that GPUs will probably continue to be scarce.

s506
00:39:07.280 --> 00:39:09.280
Like, I don't know, maybe there's going to be some surplus.

s507
00:39:09.280 --> 00:39:20.240
I 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.

s508
00:39:20.240 --> 00:39:26.960
So, 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.

s509
00:39:26.960 --> 00:39:28.720
We need to teach it how to use GP.

s510
00:39:28.720 --> 00:39:30.960
We need to teach it how to boot up bash.

s511
00:39:30.960 --> 00:39:36.000
We need it needs to run real things and learn from that takes a lot of CPU.

s512
00:39:36.000 --> 00:39:42.160
Um 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?

s513
00:39:42.160 --> 00:39:53.040
They 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?

s514
00:39:53.040 --> 00:40:06.640
because 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

s515
00:40:06.640 --> 00:40:14.000
we 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

s516
00:40:14.000 --> 00:40:21.839
you 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

s517
00:40:21.839 --> 00:40:32.640
um 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?

s518
00:40:32.640 --> 00:40:38.400
It'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.

s519
00:40:38.400 --> 00:40:38.640
Yeah.

s520
00:40:38.640 --> 00:40:42.880
And yesterday I was at a dinner that you hosted with your team where you actually have a bunch of Turbo customers.

s521
00:40:42.880 --> 00:40:57.119
A 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

s522
00:40:57.119 --> 00:41:12.400
when 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

s523
00:41:12.400 --> 00:41:13.200
It's it's interesting.

s524
00:41:13.200 --> 00:41:19.359
So 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.

s525
00:41:19.359 --> 00:41:19.680
Exactly.

s526
00:41:19.680 --> 00:41:33.760
And 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.

s527
00:41:33.760 --> 00:41:36.640
Um and so we have to work with some of our biggest customers on that.

s528
00:41:36.640 --> 00:41:40.480
So these are real constraints right that are that are making our way to us.

s529
00:41:40.480 --> 00:41:51.040
We'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.

s530
00:41:51.040 --> 00:41:56.000
But there's lots of changes that we can make even to the architecture um to try to protect from from a lot of this.

s531
00:41:56.000 --> 00:42:03.599
Now 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?

s532
00:42:03.599 --> 00:42:07.440
So we don't need everything to be a particular CPU or instance type.

s533
00:42:07.440 --> 00:42:10.720
We can run with many even many different types of machine types.

s534
00:42:10.720 --> 00:42:11.760
Um

s535
00:42:11.760 --> 00:42:15.119
Q meaning that's the it's a fancy name for like the different machine types.

s536
00:42:15.119 --> 00:42:15.440
Yes.

s537
00:42:15.440 --> 00:42:15.839
Exactly.

s538
00:42:15.839 --> 00:42:16.160
Right.

s539
00:42:16.160 --> 00:42:19.839
Like you know C4D or I AG or whatever they're called.

s540
00:42:19.839 --> 00:42:21.359
What's your favorite one?

s541
00:42:21.359 --> 00:42:28.000
Um we really like right now the um C4s on uh GCP.

s542
00:42:28.000 --> 00:42:28.720
GCP.

s543
00:42:28.720 --> 00:42:36.640
Um the Z4Ds are also performing really well um now that we've done done a bunch of of um of optimizations to them.

s544
00:42:36.640 --> 00:42:39.119
Um those are really really great machine types.

s545
00:42:39.119 --> 00:42:40.720
Uh we really like those.

s546
00:42:40.720 --> 00:42:45.760
Um and then the ARM C4As as well um on on GCP.

s547
00:42:45.760 --> 00:42:47.520
Um we like those.

s548
00:42:47.520 --> 00:42:56.640
But 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

s549
00:42:56.640 --> 00:43:01.839
ahead of BFCM right a few months out you have to tell the cloud providers how much you're intending to use.

s550
00:43:01.839 --> 00:43:03.119
do commits on all of that, right?

s551
00:43:03.119 --> 00:43:06.079
The the clouds are not infinite as they seem when you're small.

s552
00:43:06.079 --> 00:43:12.319
And one way, of course, to like get like infrastructure and and also just like credibility is venture capital.

s553
00:43:12.319 --> 00:43:16.640
If you raise $100 million, a billion dollars, some of your customers just raised $2 billion.

s554
00:43:16.640 --> 00:43:18.160
Actually, I talked with them yesterday.

s555
00:43:18.160 --> 00:43:21.680
You know, it gives you credibility, gives you cash, you can pay for this thing.

s556
00:43:21.680 --> 00:43:26.800
Your specific Turbopufferers relationship to venture capital seems very interesting.

s557
00:43:26.800 --> 00:43:30.720
I never heard you announce a raise until m maybe just very recently.

s558
00:43:30.720 --> 00:43:36.960
Can 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.

s559
00:43:36.960 --> 00:43:48.800
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 which is typical inside of Silicon Valley.

s560
00:43:48.800 --> 00:43:49.200
Yeah.

s561
00:43:49.200 --> 00:43:57.040
So I think to to understand my how I think about capital you have to go back to the the beginning of Turbopuffer, right?

s562
00:43:57.040 --> 00:44:03.599
where I promised cursor that Justine and I could get their bill to 4K a month.

s563
00:44:03.599 --> 00:44:13.599
And 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.

s564
00:44:13.599 --> 00:44:18.480
And that's the pricing we ship with and that's what we guaranteed um guaranteed cursor.

s565
00:44:18.480 --> 00:44:21.040
Um but the software was not that good.

s566
00:44:21.040 --> 00:44:24.000
Like it was very reliable, but it was very simple, right?

s567
00:44:24.000 --> 00:44:29.040
And that's like a core engineering principle of me is simplicity above everything.

s568
00:44:29.040 --> 00:44:36.960
Um 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.

s569
00:44:36.960 --> 00:44:38.160
You had a long tenure at Uber.

s570
00:44:38.160 --> 00:44:39.520
I had a long tenure at Shopify.

s571
00:44:39.520 --> 00:44:42.640
So you see simplicity just almost always wins.

s572
00:44:42.640 --> 00:45:02.000
Um 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

s573
00:45:02.000 --> 00:45:13.920
involved 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.

s574
00:45:13.920 --> 00:45:15.920
I didn't know that in the very very beginning.

s575
00:45:15.920 --> 00:45:17.839
Um it wasn't completely clear to me.

s576
00:45:17.839 --> 00:45:22.240
It felt like a very niche kind of product, right, to build this particular search engine.

s577
00:45:22.240 --> 00:45:24.480
Um and that was completely fine with me.

s578
00:45:24.480 --> 00:45:27.359
So I you know it's it's it was fine.

s579
00:45:27.359 --> 00:45:35.119
And so then I just I just looked at the cursor bill and I looked at my GCP bill which is what we started on.

s580
00:45:35.119 --> 00:45:42.960
and 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.

s581
00:45:42.960 --> 00:45:43.599
Yeah,

s582
00:45:43.599 --> 00:45:51.520
that'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.

s583
00:45:51.520 --> 00:45:54.000
Um that's just that's all I knew.

s584
00:45:54.000 --> 00:45:59.040
You you were doing business 101 as as long as you're making a profit you're good, right?

s585
00:45:59.040 --> 00:46:00.640
Yeah.

s586
00:46:00.640 --> 00:46:11.359
It 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.

s587
00:46:11.359 --> 00:46:15.119
And maybe if if if we could get some other workloads, we could start paying ourselves.

s588
00:46:15.119 --> 00:46:18.319
But that was like very much the philosophy at the time.

s589
00:46:18.319 --> 00:46:21.680
Um because I didn't know if I could go raise a bunch of of of money.

s590
00:46:21.680 --> 00:46:23.440
I didn't know anyone who had the money.

s591
00:46:23.440 --> 00:46:25.359
I I didn't have any relationships.

s592
00:46:25.359 --> 00:46:27.760
Um you were an absolute outsider to the

s593
00:46:27.760 --> 00:46:28.640
I was I was an outsider.

s594
00:46:28.640 --> 00:46:30.240
I was like an outsider squared, right?

s595
00:46:30.240 --> 00:46:35.359
I grew up in Aus, Denmark and I um I then moved to Ottawa, Canada.

s596
00:46:35.359 --> 00:46:41.200
So it's like I'm an outsider to Canada and in Canada I'm an outsider to San Francisco.

s597
00:46:41.200 --> 00:46:49.280
So 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.

s598
00:46:49.280 --> 00:46:50.720
I don't know if I can deliver that yet.

s599
00:46:50.720 --> 00:47:00.319
I 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.

s600
00:47:00.319 --> 00:47:13.920
Um 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

s601
00:47:13.920 --> 00:47:17.599
um at II um and he was he's he was really good.

s602
00:47:17.599 --> 00:47:20.640
He was so good that the North Macedonian team called him God.

s603
00:47:20.640 --> 00:47:30.240
Um 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

s604
00:47:30.240 --> 00:47:31.902
but I couldn't afford to work with Boyan

s605
00:47:31.902 --> 00:47:32.800
[laughter]

s606
00:47:32.800 --> 00:47:44.319
um 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

s607
00:47:44.319 --> 00:47:54.800
and 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.

s608
00:47:54.800 --> 00:48:06.640
And 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.

s609
00:48:06.640 --> 00:48:10.640
Can I can we raise like 700K?

s610
00:48:10.640 --> 00:48:11.920
That's like what I wanted to raise.

s611
00:48:11.920 --> 00:48:17.280
So it's just like I want to have like two engineers for the rest of the year.

s612
00:48:17.280 --> 00:48:20.560
Justine and I still don't need to be paid and then a little bit of buffer room.

s613
00:48:20.560 --> 00:48:28.960
It'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.

s614
00:48:28.960 --> 00:48:30.559
We'll return everything to you.

s615
00:48:30.559 --> 00:48:35.200
Um I think there was the first time you heard anyone say it like that.

s616
00:48:35.200 --> 00:48:39.760
Um and um I told some other VCs that at the time and that was terrifying to them.

s617
00:48:39.760 --> 00:48:45.280
I think to someone on the West Coast this sounds like you have low ambition or something like that.

s618
00:48:45.280 --> 00:48:45.839
M

s619
00:48:45.839 --> 00:48:52.720
um 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

s620
00:48:52.720 --> 00:49:05.280
and 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

s621
00:49:05.280 --> 00:49:18.800
and 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

s622
00:49:18.800 --> 00:49:20.880
there's six reasons to raise capital.

s623
00:49:20.880 --> 00:49:23.599
The first reason to raise capital is to fund R&D.

s624
00:49:23.599 --> 00:49:24.240
Mhm.

s625
00:49:24.240 --> 00:49:33.839
That 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.

s626
00:49:33.839 --> 00:49:39.760
Um, but we wanted to learn a little bit faster and so we hired Buen and Morgan as the first engineers.

s627
00:49:39.760 --> 00:49:43.280
And then the second reason to raise capital is to fund growth.

s628
00:49:43.280 --> 00:49:50.000
you'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.

s629
00:49:50.000 --> 00:49:56.004
Um the third reason to to to raise capital is for the founders's ego.

s630
00:49:56.004 --> 00:49:56.559
[snorts]

s631
00:49:56.559 --> 00:49:59.040
Um it's a very popular appreciate the honesty.

s632
00:49:59.040 --> 00:50:01.440
It's very popular, very very popular, right?

s633
00:50:01.440 --> 00:50:08.480
big numbers, lots of press, like um and I think this is a very very dangerous reason to raise money.

s634
00:50:08.480 --> 00:50:14.400
And I wish that it was more talked about because you're diluting all of your employees when you do it.

s635
00:50:14.400 --> 00:50:19.040
You are um setting a certain price for future employees and their upside.

s636
00:50:19.040 --> 00:50:24.160
It's it's it for some people it can become a status game and that's not what it's about.

s637
00:50:24.160 --> 00:50:30.160
We're here to build a big business together and this is not a reason to raise money.

s638
00:50:30.160 --> 00:50:33.119
Um, but I I do think that it happens.

s639
00:50:33.119 --> 00:50:37.920
Um, the fourth reason to to to raise capital is to reward your employees, right?

s640
00:50:37.920 --> 00:50:44.960
It'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.

s641
00:50:44.960 --> 00:50:46.400
So, you want to reward them.

s642
00:50:46.400 --> 00:50:58.160
Um, 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.

s643
00:50:58.160 --> 00:51:01.440
Um the fifth reason to raise is for a strategic partnership.

s644
00:51:01.440 --> 00:51:06.240
There are strategic partnerships that have been made in this in this city that have made companies.

s645
00:51:06.240 --> 00:51:13.200
Um and um the six reason to raise would be do doing M&A or or something like that.

s646
00:51:13.200 --> 00:51:18.480
But it's like you have to be very honest about what reason you are raising in those six.

s647
00:51:18.480 --> 00:51:22.240
First reason we raised was one and second reason we raised was four.

s648
00:51:22.240 --> 00:51:23.440
Um so which which ones?

s649
00:51:23.440 --> 00:51:25.520
The first reason to raise was R&D.

s650
00:51:25.520 --> 00:51:27.680
R&D and the second reason was

s651
00:51:27.680 --> 00:51:29.599
um to provide liquidity to the employees

s652
00:51:29.599 --> 00:51:30.079
employees.

s653
00:51:30.079 --> 00:51:31.920
Yep.

s654
00:51:31.920 --> 00:51:40.880
I 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

s655
00:51:40.880 --> 00:51:45.520
to tech ecosystems where a lot of people are raising it it will be part of it.

s656
00:51:45.520 --> 00:51:51.040
As closing I I wanted to ask you about the way you have a remote culture these days.

s657
00:51:51.040 --> 00:51:59.599
I'm seeing it especially for companies that do anything with AI, may that be building AI infra or or or just AI products.

s658
00:51:59.599 --> 00:52:11.119
A 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.

s659
00:52:11.119 --> 00:52:15.440
Uh it's just fewer layers cut in between and of course speed is is very very important.

s660
00:52:15.440 --> 00:52:18.640
You have started full remote and you're still full remote.

s661
00:52:18.640 --> 00:52:21.119
how is it working?

s662
00:52:21.119 --> 00:52:28.640
Uh, and what kind of quirks or like or turbo ways have you found to to make this work better?

s663
00:52:28.640 --> 00:52:30.160
Yeah, I think so.

s664
00:52:30.160 --> 00:52:33.359
The the company started in in 23.

s665
00:52:33.359 --> 00:52:37.599
So, sort of like on the on the on the cusp of COVID where a lot of companies were just remote.

s666
00:52:37.599 --> 00:52:44.319
Um, the Shopify infra was remote since the very um very beginning because it was very difficult to get them all to move to Ottawa.

s667
00:52:44.319 --> 00:52:49.200
Um, and so it was natural to me.

s668
00:52:49.200 --> 00:52:57.680
It'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.

s669
00:52:57.680 --> 00:52:58.880
There are maybe other cities, right?

s670
00:52:58.880 --> 00:53:00.319
But that's like kind of where it's been done.

s671
00:53:00.319 --> 00:53:00.640
Yeah.

s672
00:53:00.640 --> 00:53:05.440
And so if you don't want to do that, I think you have to go all in on on on some distributed model.

s673
00:53:05.440 --> 00:53:09.280
And so we've tried to figure out what does that distributed model mean for Turppuffer?

s674
00:53:09.280 --> 00:53:10.960
It doesn't mean the absence of in person.

s675
00:53:10.960 --> 00:53:15.040
we get everyone together twice a year in in some in in some location.

s676
00:53:15.040 --> 00:53:17.119
Uh earlier this year we were in in B, right?

s677
00:53:17.119 --> 00:53:18.800
And then we were in Mexico City and so on.

s678
00:53:18.800 --> 00:53:21.119
So it's like that's that's not that uncommon.

s679
00:53:21.119 --> 00:53:26.720
Um but one of the things that we we we've been trying to do is we have this concept called campfires.

s680
00:53:26.720 --> 00:53:36.240
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.

s681
00:53:36.240 --> 00:53:42.160
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.

s682
00:53:42.160 --> 00:53:44.079
And so, everyone is invited to come.

s683
00:53:44.079 --> 00:53:45.680
Like, we're going to go meet customers, right?

s684
00:53:45.680 --> 00:53:48.400
We're going to put on dinners for our customers and things like that.

s685
00:53:48.400 --> 00:53:51.440
And we just make a thing out of it and and spend time together.

s686
00:53:51.440 --> 00:53:54.480
And uh we encourage everyone to come.

s687
00:53:54.480 --> 00:54:02.079
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.

s688
00:54:02.079 --> 00:54:06.400
Some people just want to, you know, lock in and hacks into tent and that's great.

s689
00:54:06.400 --> 00:54:13.119
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.

s690
00:54:13.119 --> 00:54:14.800
Um, fantastic.

s691
00:54:14.800 --> 00:54:17.200
Like that is completely compatible with this model.

s692
00:54:17.200 --> 00:54:20.559
And there are other people at the company who are on a plane probably every two weeks.

s693
00:54:20.559 --> 00:54:33.072
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

s694
00:54:33.072 --> 00:54:33.359
[laughter]

s695
00:54:33.359 --> 00:54:35.760
flew to New York to hang out with the team, right?

s696
00:54:35.760 --> 00:54:37.520
And I think that's fantastic.

s697
00:54:37.520 --> 00:54:48.160
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 Turbop or something a bit extracurricular,

s698
00:54:48.160 --> 00:54:58.400
we 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.

s699
00:54:58.400 --> 00:55:03.040
Um and now I mean turbo credits are probably going to take on a life of their own.

s700
00:55:03.040 --> 00:55:06.960
Someone was talking about doing a central bank and doing interest rates on the turbo credits.

s701
00:55:06.960 --> 00:55:09.280
um and doing a betting market on the turbo credits.

s702
00:55:09.280 --> 00:55:12.319
And so like this might take on its life on its own.

s703
00:55:12.319 --> 00:55:26.480
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.

s704
00:55:26.480 --> 00:55:30.000
And so if you do that for two days because you want to do it, oh, you get a turbo credit, right?

s705
00:55:30.000 --> 00:55:36.800
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.

s706
00:55:36.800 --> 00:55:50.480
Well, 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,

s707
00:55:50.480 --> 00:55:56.960
pushing, being curious, and the human connection, how important it is for people to work together, to trust each other.

s708
00:55:56.960 --> 00:55:58.480
So, just thank you very much for that.

s709
00:55:58.480 --> 00:56:00.480
So, let's give a big round of applause for Simon.

s710
00:56:00.480 --> 00:56:02.240
Thank you so much.

s711
00:56:02.240 --> 00:56:02.880
This is great.

s712
00:56:02.880 --> 00:56:05.040
Thank you.

s713
00:56:05.280 --> 00:56:07.359
Are you

s714
00:56:25.734 --> 00:56:27.734
[music]