Simon Eskildsen [0:00]: I don't think I've said this publicly before but I just called Lachy and was like look Lachy like if this doesn't have PMF by the end of the year like we'll just like return all the money to you Justine and I don't want to work on this unless it's really working so we want to give it the best shot this year and like we're really going to go for it we're going to hire a bunch of people and we're just going to be honest with everyone like when I don't know how to play a game I just play with open cards Lachy was the only person that didn't that didn't freak out he was like I've never heard anyone say that before
Alessio Fanelli [0:29]: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I'm joined by swyx, editor of Latent Space.
swyx [0:35]: Hello, hello. We're still recording in the Kernel studio for the first time. Very excited. And today we're joined by Simon Eskildsen of turbopuffer. Welcome.
Simon Eskildsen [0:45]: Thank you so much for having me.
swyx [0:46]: turbopuffer has like really gone on a huge tear and I do have to mention that like you're one of, you're not my newest member of the Danish Aarhus Mafia where like there's a lot of legendary programmers that have come out of it like Björn Sjostrom, Rasmus Lerdorf, Anders Hejlsberg and the V8 team and Google Maps team. You're mostly a Canadian now but isn't that interesting there's so much like strong Danish presence?
Simon Eskildsen [1:11]: Yeah, I was writing a post not that long ago about sort of the influences. So I grew up in Denmark, right? I left when I was 18 to go to Canada to work at Shopify. And so I would still say that I feel more Danish than Canadian. This is also the weird accent. I can't say TH because this is like, I don't, you know, my wife is also Canadian. And I think. I think like one of the things in Denmark is just like there's just such a ruthless pragmatism and there's also a big focus on just aesthetics like they're like very people really care about like where what things look like and like Canada has a lot of attributes US has a lot of attributes but I think there's been lots of great things to carry I don't know what's in the water in all those though and I don't know that I could be considered part of the Aarhus mafia quite yet compared to the phenomenal individuals we just mentioned but Rasmus Lerdorf is also Danish Canadian yeah. I don't know where he lives now but and he's the PHP.
swyx [2:09]: Yeah, and obviously Tobi is German move to Canada as well. Like this is like import that is an interesting talent move.
Alessio Fanelli [2:17]: I think I would love to get from you the definition of turbopuffer because I think you could be a vector db, which is maybe a bad word now in some circles. You could be a search engine. It's like, let's just start there and then we'll maybe. We'll maybe run through the history of how you got to this point.
Simon Eskildsen [2:32]: For sure. Yeah. So turbopuffer is at this point in time a search engine, right? We do full-text search and we do vector search and that's really what we're specialized in. If you're trying to do much more than that, like then this might not be the right place yet, but turbopuffer is all about search. The other way that I think about it is that we can take all of the world's knowledge, all of the exabytes and exabytes of data that there is, and we can... use those tokens to train a model, but we can't compress all of that into a few terabytes of weights, right? We can compress into a few terabytes of weights how to reason with the world, how to make sense of the knowledge, but we have to somehow connect it to something external that actually holds that like in full fidelity and truth. And that's the thing that we intend to become, right? That's like a very holier than thou kind of phrasing, right? But being the search engine for unstructured data is the focus of turbopuffer at this point in time.
Alessio Fanelli [3:25]: And let's break down. So people might say, well, didn't Elasticsearch already do this? And then some other people might say. it's this search on my data it's this like closer to RAG than to like a Exa like a public search thing like how do you segment like the different types of search?
Simon Eskildsen [3:41]: The way that I generally think about this is like there's a lot of database companies and I think if you want to build a really big database company, sort of you need a couple of ingredients to be in the air, which only happens roughly every 15 years. You need a new workload. You basically need the ambition that every single company. on earth is going to have data in your database. multiple times you look at a company like Oracle right you like I don't think you can find a company on earth with a digital presence that it not doesn't somehow have some data in an Oracle database right and I think at this point that's also true for Snowflake and Databricks right 15 years later it's or even more than that there's not a company on earth that doesn't indirectly or directly is consuming Snowflake or or Databricks or any of the big analytics databases um and I think we're in that kind of moment now right I don't think you're going to find a company over the next few years that doesn't directly or indirectly have all their data available for search and connect it to AI. So you need that new workload, like you need something to be happening where there's a new workload that causes that to happen. And that new workload is connecting very large amounts of data to AI. The second thing you need, the second condition to build a big database company is that you need some new underlying change in the storage architecture that is not possible from the databases that have come before you. If you look at Snowflake and Databricks, right, commoditized like a massive fleet of HDDs, like that was not possible and it just wasn't in the air in the 90s, right? So you just didn't build these systems as S3 and... and and so on was not around and I think the architecture is now possible that wasn't possible 15 years ago is to go all in on NVMe SSDs it requires a particular type of architecture for the database that is difficult to retrofit onto the databases that are already there, including the ones you just mentioned. The second thing is to go all in on object storage, more so than we could have done 15 years ago. Like we don't have a consensus layer. We don't really have anything. In fact, you could turn off all the servers that turbopuffer has and we would not lose any data because we have a completely all in on object storage. And this means that our architecture is just so simple. So that's the second condition, right? First being a new workload that means that every company on earth either indirectly or directly. is using your database, second being there's some new storage architecture. That means that the companies that have come before you can't do what you're doing. I think the third thing you need to do to build a big database company is that over time you have to implement more or less every query plan on the data. What that means is that you can't just get stuck in like this is the one thing that a database does. It has to be ever evolving because when someone has data in the database, they over time expect to be able to ask it more or less every question. mission to have to do that to get the storage architecture to the limit of what what it's capable of those are the three conditions
swyx [6:24]: I just wanted to get a little bit of like the motivation, right? Like, so you left Shopify, you're like principal engineer, infra guy. You also heard of kernel labs inside of Shopify, right? And then you consulted for Readwise and that kind of gave you that idea. I just wanted you to tell that story. Maybe you've told it before, but just introduce the... people to like the new workload there's an aha moment for turbopuffer
Simon Eskildsen [6:47]: For sure. So yeah, I spent almost a decade at Shopify. I was on the infrastructure team from the fairly early days around 2013. At the time, it felt like it was growing so quickly and everything, all the metrics were doubling year on year. Compared to what companies are contending with today, it's very cute in growth. I feel like some companies are seeing that month over month. month. Of course, Shopify has been compounding for a very long time now. But I spent a decade doing that. And the majority of that was just make sure the site is up today and make sure it's up a year from now. And a lot of that was really just the, you know, the Kardashians would drive very, very large amounts of data to Shopify as they were rotating through all the merch and building out their businesses. And we just needed to make sure we could handle that, right? And sometimes these were events with a million requests per second. And so, you know, we had our own data centers back in the day and we're moving to the cloud and there's so much sharding work and all of that that we were doing. That's been a decade just. scaling databases because that's fundamentally was the most difficult thing to scale about these sites the database that was the most difficult for me to scale during that time and that was the most aggravating to be on call for was Elasticsearch it was very very difficult to deal with and I saw a lot of projects that were just being held back in their ambition by using it and
swyx [8:05]: Self-hosted?
Simon Eskildsen [8:05]: Yes self-hosted.
Simon Eskildsen [8:07]: This was like 2015 right so it's like a very particular vintage right it's probably better a lot of these things now now um it was difficult to contend with and i'm just like I just think about it's an inverted index it should be good at these kinds of queries and do all of this and it was we often couldn't get it to do exactly what we needed to do or basically get Lucene to do like expose Lucene raw to to what we needed to do um so that was like just something that we did on the side it just panic scaled when we needed to but not a particular focus of mine so I left and when I left i um wasn't sure exactly what I wanted to do I mean it spent like a decade inside of the same company i'd like yeah like grown up there I started working there when I was 18 uh
swyx [8:44]: You only do rails?
Simon Eskildsen [8:45]: yeah I mean yeah rails. I love rails so good.
Alessio Fanelli [8:51]: I wish we could still work in Rails.
Simon Eskildsen [8:53]: I know I know
swyx [8:55]: I trued learning ruby it's just too much like too many options to do the same thing it's that's my I know there's there's a way to do it
Simon Eskildsen [9:02]: I love it I don't know that I would use it now like given cloud code and and Cursor and everything but but still if I'm just sitting down and writing a seasonal code that's how I think but anyway I left and I wasn't I talked to a couple companies I was like I don't I need to see a little bit more of the world here to know what I'm going to like focus on next. And so what I decided is like I was going to I called it like angel engineering where I just hopped around in my friend's companies in three months increments and just help them out with something right and and just vested a bit of equity and solve some interesting infrastructure problem. So I work with a bunch of companies at the time. Readwise was one of them. Replicate was one of them. Causal. I don't know if you've tried this. It's like a it's a spreadsheet engine. Yeah where you can. where you can do distribution they sold recently yeah we've been we used out an FPGA at turbopuffer so a bunch of companies like this and it was super fun and so when the chat GPT moment happened I was with With Readwise for a stint, we were preparing for the reader launch, right, which is where you queue articles and read them later. And I was just getting their Postgres up to snuff, like, which basically boils down to tuning auto vacuum. So I was doing that and then this happened and we were like, oh, maybe we should build a little recommendation engine and some features to try to hook in the LLMs. They were not that good yet, but it was clear there was something there. And so I built a small recommendation engine just, okay, let's take the articles that you've recently read, right? Like... embed all the articles and then do recommendations. It was good enough that when I ran it on one of the co-founders of Readwise, like I found out that I got articles about having a child. I'm like, oh my God, I didn't know that they were having a child. I wasn't sure what to do with that information, but the recommendation engine was good enough that it was suggesting articles about that. And so there was recommendations and it actually worked really well, but this was a company that was spending maybe five grand a month. month in total on all their infrastructure. And when I did the napkin math on running the embeddings of all the articles, putting them into a vector index, putting it in prod, it's going to be like 30 grand a month. that just wasn't tenable right like Readwise is the proudly bootstrapped company and paying 30 grand for infrastructure for one feature versus five it just wasn't tenable so sort of in the bucket of this is useful it's pretty good but let us let's return to it when the cost comes dow to it.
swyx [11:24]: Did you say it grows by feature so for five to thirty is by the number of like what's the what's the scaling factor it scales by the number of articles that you embed.
Simon Eskildsen [11:34]: It does but what I meant by that is like five grand for like all of the other other like the hiroko dynos postgres like all the other stuff.
swyx [11:41]: The storage is 30?
Simon Eskildsen [11:42]: Yeah like 30 grand for one feature right which is like what other articles are related to this one um so it was just too much right to power everything their budget would have been maybe a few thousand dollars which still would have been a lot and so we put it in the bucket of okay we're going to do that later but we'll wait for the cost to come down and that haunted me I couldn't stop thinking about it. I was like, okay, there's clearly some latent demand here. If the cost had been a tenth, we would have shipped it. and this was really the only data point that I had right I didn't I didn't I didn't go out and talk to anyone else it was just so I started reading right I couldn't I couldn't help myself like I didn't know what like a vector index is I generally barely knew about how to generate the vectors there was a lot of hype about this is the early 2023 there was a lot of hype about vector databases they're raising a lot of money as I really didn't know anything about it it's like you know trying these little models fine-tuning them like I was just trying to get sort of a lay of the land land so I just sat down I have this uh github repository called napkin math and on napkin math there's just um rows of like oh this is how much bandwidth like this is how many you know you can do 25 gigabytes per second on average to dram you can do you know five gigabytes per second of writes to an SSD but all of these numbers right and S3 how many you can do how much bandwidth can you drive per connection I was just sitting down it's like why hasn't anyone built a database where you just put everything on object storage you storage and then you puff it into NVMe when you use the data and you puff it into DRAM if you're if you're querying it a lot it's just like this seems fairly obvious and you the only real downside to that is that if you go all in on optic storage every write will take a couple hundred milliseconds of latency but from there it's really all upside right you do the first query it takes half a second And it sort of occurred to me, it's like, well, the architecture is really good for that, is really good for object storage, that's really good for NVMe SSDs. Well, you just couldn't have done that 10 years ago, back to what we were talking about before. You really have to build a database where you have as few round trips as possible, right? This is how CPUs work today. It's how NVMe SSDs work. It's how S3 works that you want to have a very large amount of outstanding requests, right? Like basically go to S3, do like. That thousand request drives for data in one round trip. Wait for that, get that, like make a new decision, do it again and try to do that maybe a maximum of three times. But no databases were designed that way. With NVMe SSDs, you can drive like within, you know, within a very low multiple of DRAM bandwidth if you use it that way. And same with S3, right? You can fully max out the network card, which generally is not maxed out. You get very like very, very good bandwidth. with and but no one had built a database like that so it's like okay well can't you just you know take all the vectors right and plot them in the proverbial coordinate system get the clusters put a file on S3 called clusters.json and then put another file for every cluster you know cluster1.json cluster2.json you know that like it's two round trips right so you get the clusters you find the closest clusters and then you download the cluster files like the the closest end and you can do this in two round trips yes
swyx [14:47]: And near neighbors locally?
Simon Eskildsen [14:49]: Yes and then and you would build this this file right just like ultra simplistic but it's not a far shot from what the first version of turbopuffer was why hasn't anyone done that you
Alession Fanelli [14:57]: In that moment, from a workload perspective, you're thinking this is going to be like a read heavy. thing because they're being recommended like it's the fact that like rights are so expensive now oh yeah you're actually not writing that much
Simon Eskildsen [15:10]: At that point, I hadn't really thought too much about, well, no, actually, it was always clear to me that there was going to be a lot of rights because at Shopify, the search clusters were doing, you know. i don't know tens or hundreds of qps right because you have to have a human sit and type in but we did you know I don't know how many updates there were per second i'm sure it was in the millions right into the cluster so I always knew there was like a 10 to 100 ratio on the read write in the Readwise use case it's um even even in the Readwise use case there probably be a lot fewer reads than writes right there's just a lot of churn on the amount of stuff that was going through versus the amount of queries um I wasn't thinking too much about that i was mostly just thinking about what's the the fundamentally cheapest way to build a database in the cloud today using the primitives that you have available. And this is it, right? You just now you have one machine. And, you know, let's say you have a terabyte of data in S3, you pay $200 a month for that, and then maybe 5% to 10% of that data needs to be in NVMe SSDs and less than that in DRAM. Well, you're just, you're paying very, very little to inflate the data.
swyx [16:11]: By the way, when you say no one else has done that, would you consider Neon to be on a similar path in terms of being sort of S3 first and separating the compute and storage?
Simon Eskildsen [16:21]: Yeah, I think what I meant with that is just build a completely new data. the new database I don't know if we were the first like it was very much it was I mean I i hadn't I just looked at the napkin math and was like this seems really obvious i'm sure like 100 people came up with it at the same time like the light bulb and every invention ever right it was just in the air I think neon neon was was first to it and they're trying they're retrofitted it onto postgres right and then they built this whole architecture where you have you have it in memory and then you sort of like you know mmap back to S3 and I think that was very novel at the time to do a full of for all TP, but I hadn't seen a database that was truly all-in, right? Not retrofitting it. The database built purely for this. No consensus layer, even using compare and swap on object stores to do consensus. I hadn't seen anyone go that all-in. And I mean, I'm sure there's someone that did that before us. I don't know. I was just looking at the napkin math.
swyx [17:11]: and when you say consensus layer are you strongly relying on S3 strong consistency you are okay so that is your consensus layer?
Simon Eskildsen [17:18]: It is the consistency layer. And I think also i think also like this is something that most people don't realize but S3 only became consistent in December of 2020 yeah
swyx [17:25]: I remember this coming out during covid and like people were like oh it was like it was just like a free upgrade, they just announced it we saw consistency guys and like okay cool
Simon Eskildsen [17:35]: i'm sure that they just they probably had it in prod for a while they're just like it's done right and people like okay cool but that's a big moment right like NVMe SSDs were also not in the cloud until around 2017 2017 right so you just sort of had like 2017 and the NVMe SSDs and people were like okay cool there's like one skew that does this whatever right takes a few years and then the second thing is like S3 becomes consistent in 2020 so now it means you don't have to have this like big foundation db or like zookeeper or whatever sitting there contending with the keys which is how you know that's what Snowflake and others had to do. Right and so just push to the you know whatever how many hundreds of people they have working on S3 solved and then compare and swap was not in S3 at this point in time yes
swyx [18:17]: By the way, I don't know what that is. So maybe you want to explain.
Simon Eskildsen [18:20]: yes so um what compare and swap is is basically you can imagine that if you have a database it might be really nice It would be nice to have a file called metadata.json, and metadata.json could say things like, hey, these keys are here, and this file means that, and there's lots of metadata that you have to operate in the database, right? But that's the simplest way to do it. So now you might have a lot of servers that want to change the metadata. They might have written a file and want the metadata to contain that file. But you have 100 nodes that are trying to contend with this metadata.json. Well, what compare and swap allows you to do is basically just you download the file. You make the modifications and then you write it only if it hasn't changed while you did the modification. And if not, you retry, right? You just have this retry loops. Now you can imagine if you have 100 nodes doing that, it's going to be really slow, but it will converge over time. That primitive was not available in S3. It wasn't available in S3 until late 2024, but it was available in GCP. The real story of this is certainly not that I sat down and like bake brained it as like, okay, we're going to start on GCS at S3 is going to get it later. Like it was really not that we started, we got really lucky. Like we started on GCP and we started on GCP because Shopify ran on GCP. And so that was the platform I was most available with. Right. And I knew the Canadian team there because I'd worked with them at Shopify. And so it was natural for us to start there. And so when we started building the database, we're like, oh yeah. Oh, yeah, we have to build it. We really thought we had to build a consensus layer, like have a zookeeper or something to do this. But then we discovered the compare and swap was like, oh, we can kick the can. We'll just do metadata or JSON and just it's fine. It's probably fine. And we just kept kicking the can until we had very, very strong conviction in the. idea. And then we kind of just hinged the company on the fact that S3 probably was going to get this. It started getting really painful in like mid 2024 because we were closing deals with Notion actually that was running in AWS and we're like, trust us, you really want us to run this in GCP? And they're like, no, I don't know about that. Like we're running everything in AWS and the latency across the clouds were so big and we had so much conviction that we bought like, you know, dark fiber between the AWS regions in Oregon, like in the inter exchange. change and GCP is like we've never seen a startup like do like what's going on here and we're just like no we don't want to do this we were tuning like tcp windows like everything to get the latency down because we had so high conviction in not doing like a metadata layer on S3 so those were the three conditions right comparing swap to do metadata which wasn't in S3 until late 2024 S3 being consistent which didn't happen until December 2020 uh 2020 and then NVMe SSDs which didn't land in the cloud until 2017
swyx [21:02]: I mean, in some ways, like a very big like cloud success story that like you were able to like put this all together, but also doing things like doing bind our favor that actually is something I've never heard.
Simon Eskildsen [21:13]: well I mean it's very common when you're a big company right you're like connecting your own like data center or whatever but it's like it was uniquely just a pain with Notion because the um the or like most of the like if you're buying an ashburn virginia right like us east the google like the GCP and and and AWS data centers like within a millisecond on each other on the public exchanges but in Oregon uniquely the GCP data center sits like a couple hundred kilometers like east of Portland and the AWS region sits in Portland but the network exchange they go through is through Seattle so it's like a full like 14 milliseconds or something like that and so anyway yeah it's so we were like okay we can't we have to go through an exchange in Portland yeah anyway
swyx [21:55]: And you'd rather do this than like run your own zookeeper?
Simon Eskildsen [21:58]: Yes, way rather. It doesn't have state. I don't want state in two systems. And I think all that is just informed by Justine, my co-founder and I had just been on call for so long and the worst outages are the ones where you have state in multiple places that's not syncing up. So it really came from from a like just a very pure source of pain of just imagining what we would be okay being woken up at 3 a.m. about. about and having something in zookeeper was not one of them
swyx [22:26]: I mean, we're talking to like a Notion or something, do they care? Or do they just care about latency? Or cost?
Simon Eskildsen [22:33]: They just cared about latency right and we just absorb the cost we're just like we have high connection in this at some point we can move them to AWS right and so we just we'll buy the fiber it doesn't matter right um and it's like 5 000 and we usually when you buy fiber you buy like multiple lines and we're like we can only afford one but we will just test it that when it goes over the public internet it's like super smooth and so we did a lot anyway it's yeah it was i
swyx [22:56]: that's cool you can imagine talking to the GCP rep and it's like no we're gonna buy because we know we're gonna churn we're gonna churn from you guys and go to AWS in like six months but I mean like they you know this workload still runs on GCP for what it's worth right because it's so it was just it was so reliable so it was never about moving off GCP it was just about how honestly it was just about giving Notion the latency that they deserved right um and we didn't want them to have to care about any of this we also they were like oh egress is going to be bad it was like okay screw it like we're just gonna like vpc peer with you in AWS we'll eat the cost yeah whatever needs to be done yeah
Alessio Fanelli [23:31]: and what were the actual workloads because I think when you think about AI it's like 14 milliseconds it's like really doesn't really matter in the scheme of like a model generation al, right?
Simon Eskildsen [23:40]: We were told the latency that we had to beat! So we're just looking at the traces, right? And then sort of like hand draw, like, you know. kind of like looking at the trace and then thinking what are the other extensions of the trace right and there's a lot more to it because it's also when you have if you have 14 versus 7 milliseconds right you can fit another round trip so we had to tune tcp to try to send as much data in every round trip pre-warm all the connections and there was there's a lot of things that compound from having these kinds of round trips but in the grand scheme it was just like well we have to beat the latency of whatever we're up against
swyx [24:13]: Which is like they I mean Notion is a database company they could have done this themselves they do lots of database engineering themselves how do you even get in the door like yeah just like talk to that kind of
Simon Eskildsen [24:26]: Last year I was in San Francisco, I was talking to one of the engineers actually who was one of our champions at Notion. And they were just trying to make sure that the per user cost matched the economics that they needed. Like it's like the way I think about it is like I have to earn a return on whatever the clouds charge me and then my customers have to earn a return on that. It's like very simple, right? And so there has to be gross margin all the way up and that's how you build the product. product and so then our customers have to make the right set of trade-offs the turbopuffer makes and if they're happy with that that's great
swyx [24:57]: Do you feel like you're competing with build internally versus buy or buy versus buy?
Simon Eskildsen [25:02]: yeah so sorry this was all to build up to your question so one of the Notion engineers told me that they'd sat and probably on a napkin like drawn out like why hasn't anyone built this and then they saw turbopuffer like well it's literally that so And I think AI has also changed the buy versus build equation in terms of it's not really about can we build it, it's about do we have time to build it. And I think they felt like, okay, if this is a team that can do that and they feel enough of an extension of our team, well, then we can go a lot faster, which would be very, very good for them. And I mean, they put us through the test, right? Like we had some very, very long nights to do that POC and they were really our biggest, our second big customer off the Cursor, which also was a lot of late nights, right?
swyx [25:46]: Yeah, I mean should we go into that story that the sort of Cursor story like a lot they credit you a lot for working very closely with them so I just want to hear like i've heard this uh sorry Francois this point of view but like i'm curious what it looks like from your side
Simon Eskildsen [26:00]: I actually haven't heard it from Swale's point of view. So maybe you can now cross-reference it. The way that I remember it was that the day after we launched, which was just, you know, I'd worked the whole summer on the first version. Justine wasn't part of it yet because I just, I didn't tell anyone that summer. remember that I was working on this I was just locked in on building it because it's very easy otherwise to confuse talking about something to actually doing it and so it's like i'm not going to do that i'm just going to do the thing I launched it and at this point turbopuffer is like a rust binary running on a single eight core machine in a t-mux instance and me deploying it was like looking at the request log and then like command seeing it or like control seeing it to just like okay there's no request let's upgrade the binary like it was like literally the the the scrappiest thing you could imagine it was on purpose because just like at Shopify we did that all the time like we like move like we ran things in Teamworks all the time to begin with before something had like at least the inkling of PMF it was like okay is anyone going to care about this and one of the Cursor co-founders Arvid reached out and he just you know the the Cursor team on like all io imo like um contenders right so they just speak in bullet points and and facts there's like this amazing email exchange just of this is how many qps we have this is what we're paying this is where we're going blah blah blah and so we're just conversing in bullet points and I tried to get a call with them a few times but they were so they were like really riding the pmf bull here just like late 2023 and one time Swale emails me at like five five no what was it like 4 a.m pacific time saying like hey are you open for a call now and i'm on the east coast and it was like 7 a.m like yeah great sure whatever um and we just started talking and something then I didn't know anything about sales it would something just compelled me I have to go see this team like there's something here so I went to San Francisco and I went to their office and the way that I remember it is that Postgres was down when I showed up at the office did Swale tell you this no okay so Postgres was down it's just like they were distracting me that and I was trying my best to see if I could if I could help in any way like I knew a little bit about databases back to tuning auto vacuums like I think you have to tune auto vacuums while they um and so we we talked about that and then um that evening just talked about like what would it look like what would it look like to work with us and I just said look like we're all in like we will just do what we'll do whatever whatever you tell us right they migrated everything over the next like week or two and we reduced their cost by 95 which I think like kind of fixed their per user economics and it solved a lot of other things and we were just justine this is also when I asked justine to come on as my co-founder she was the best engineer that I ever worked with at Shopify she lived two blocks away and we were just okay we're just going to get this done done um and we did and so we helped them migrate and we just worked like hell over the next like month or two to make sure that we were never an issue and that was that was the Cursor story yeah yeah
swyx [28:54]: And is code a different workload than normal text? I don't know. Is it just text? Is it the same thing?
Simon Eskildsen [29:01]: so Cursor's workload is basically they um they will embed the entire code base right so they they will like chunk it up in whatever they would they do They have their own embedding model, which they've been public about, and they find that on their evals, there's one other evals where it's like a 25% improvement on a very particular workload. They have a bunch of blog posts about it. I think it works best on larger code bases, but they've trained their own embedding model to do this. And so you'll see it. If you use the Cursor agent, it will do searches. And they've also been public around how they've, I think they post-trained their model to be very good at semantic search as well. Well, and that's how they use it. And so it's very good at like, can you find me other code that's similar to this or code that does this and just in just queries. They also use grep to supplement it, of course.
Alessio Fanelli [29:47]: it's been a big topic of discussion like is RAG dead because grep?
Simon Eskildsen [29:51]: And I mean, like, I just, we see lots of demand from the coding companies, we see demand. And so, I mean, And I like case studies. I don't like like just doing like thought pieces on this is where it's going and like trying to be all macroeconomic about AI that's has turned out to be a giant waste of time because no one can really predict any of this. So I just collect case studies. And I mean, Cursor has done a great job talking about what they're doing. And I hope some of the other coding labs that use turbopuffer will do the same. But it does seem to make a difference for particular queries. I mean, we can also do text, we can also do regex. but i should also say that Cursor's like security posturing into turbopuffer is exceptional right they have their own embedding model which makes it very difficult to reverse engineer they obfuscate the file paths they like you it's very difficult to learn anything about a code base by looking at it and the other thing they do too is that for their customers they encrypt it with their encryption keys in turbopuffer's bucket so it's it's really really well designed
swyx [30:50]: and so this is like extra stuff they did to work with you because you are not part of Cursor.
Simon Eskildsen [30:55]: Exactly.
swyx [30:56]: This is just best practice when working in any database not just you guys okay yeah it already sets yeah I think for me like the the learning is kind of like you're like all workloads are hybrid like you know uh like you want the semantic you want the text you want the reg x you want sql I don't know um but like it's silly to like be all in on like one particular query pattern
Simon Eskildsen [31:15]: I think like, I really like the way that Swale at Cursor talks about it, which is, I'm going to butcher it here. And, you know, I'm a database scalability person. I don't know anything about training models other than what the internet tells me. And what the way he describes it, this is just like cache compute, right? It's like you have a point in time where you're looking at some particular context and focused on some chunk and you say this is the layer of the neural net at this point in time. That seems fundamentally really useful to do cache compute like that. And how the value of that will change over time. I'm not sure, but there seems to be a lot of value in that.
Alessio Fanelli [31:54]: maybe talk a bit about the evolution of the workload because even like search like maybe two years ago it was like one search at the start of like an LLM query to build the context now you have a gen-tech search however you want to call it where like the model is both writing and changing the code and it's searching it again later yeah what are maybe some of the new types of workloads or like changes you've had to make to your architecture for it
Simon Eskildsen [32:17]: I think you're right. When I think of RAG, I think of, hey, there's an 8,000 token context window and you better make it count. And search was a way to do that. Now. Yeah, everything is moving towards the age, just let the agent do its thing, right? And so back to the thing before, right? The LLM is very good at reasoning with the data. And so we're just the tool call, right? And that's increasingly what we see our customers doing. What we're seeing more demand from from our customers now is to do a lot of concurrency, right? Like Notion does a ridiculous amount of queries in every round trip just because they can't. And I'm also now when I use the Cursor agent, I also see them doing more. more concurrency than I've ever seen before so a bit similar to how we designed a database to drive as much concurrency in every round trip as possible that's also what the agents are doing so that's new it means just an enormous amount of queries all at once to the data set while it's warm in as few turns as possible yes
swyx [33:11]: Can I clarify one thing on that? Are they batching multiple users or one user is driving multiple queries?
Simon Eskildsen [33:16]: One user is driving.
swyx [33:21]: Cognition also did this for the fast context thing, like eight parallel at once.
Simon Eskildsen [33:25]: Yes.
swyx [33:25]: And an interesting problem is, well, how do you make sure you have enough diversity so you're not making the same request eight times?
Simon Eskildsen [33:33]: And I think like that's probably also where the hybrid comes in, where that's another way to diversify. It's a completely different way to do the search. That's a big change, right? So before it was really just like one call and then, you know, the LLM took. however many seconds to return but now we just see an enormous amount of queries so the um we just see more queries so we've like tried to reduce query we've reduced query pricing um this is probably the first time actually i'm saying that but the query pricing is being reduced like 5x um and we'll probably try to reduce it even more to accommodate some of these workloads of just doing very large amounts of queries um that's one thing that's changed I think the right the right ratio is still very high right Right. Like there's still an enormous amount of rights per read, but we're starting probably to see that change if people really lean into this pattern.
Alessio Fanelli [34:21]: Can we talk a little bit about the pricing? I'm curious because traditionally a database would charge on storage, but now you have the token generation that is so expensive where like the actual value of like a good search query is like much higher because they're like saving inference time down the line. How do you structure that as like, what are people receptive to on the other side too?
Simon Eskildsen [34:42]: Yeah, the turbopuffer pricing in the beginning was just very simple. The pricing for search engines before turbopuffer was very serverful, right? It was like... here's the vm here's the per hour cost right great and I just sat down with like a piece of paper and said like if turbopuffer is like really good this is probably what it would cost me a little bit of margin and that was the first pricing of turbopuffer and I just like sat down I was like okay like this is like probably the storage amp or whatever on a piece of paper and vibe priced it.
swyx [35:12]: Vibe pricing.
Simon Eskildsen [35:13]: It was very vibe priced and I got it wrong um well i didn't get it wrong but like turbopuffer wasn't at the first principle pricing right so when Cursor came on turbopuffer it was like like I didn't know any vcs i didn't know like I just like I don't know I didn't know anything about raising money or anything like that I just saw that my gcp bill was was hot was a lot higher than the Cursor bill so justine and I was like well we have to optimize it um and I mean to the chagrin now of of of of the vcs it now means that we're profitable because we've had so much pricing pressure in the beginning. because it was running on my credit card and justine and I had spent like like tens of thousands of dollars on like compute bills and like spinning off the company and like very like like bad canadian lawyers and like things like to like get all of this done because we just like we didn't know right if you're like steeped in san francisco you're just like you just know okay like you go out raise the precede round I i never heard of word precede at this point in time
swyx [36:14]: when you get Cursor you had Notion you had no funding
Simon Eskildsen [36:17]: um with Cursor we had no funding yeah by the time we had Notion Lachy was Lachy was here yeah so it was really just we've vibe priced it 100 from first principles but it wasn't it was not performing at first principles so we just did everything we could to optimize it in the beginning for that so that at least we could have like a five percent margin or something so I wasn't freaking out because Cursor's bill was also going like this as they were growing and so my liability and my credit limit I mean was like actively calling my bank is like I need a bigger credit like it was yeah anyway that was the beginning yeah but the pricing was yeah like storage writes and query right and the the pricing we have today is basically just that pricing with duct tape and spit to try to approach like you know like as a margin on the physical underlying hardware and we're doing this year you're going to see more and more pricing changes from us
swyx [37:09]: Yeah.
swyx [37:09]: and like is how much does stuff like vpc peering matter because you're working in an AWS land where egress is charged and all that you know
Simon Eskildsen [37:17]: we probably don't like we have like an enterprise plan that just has like a base fee because we haven't had time to figure out sku pricing for all of this um but I mean yeah you can run turbopuffer either in sass right that's what Cursor does you can run it in a single tenant cluster so it's just you that's what Notion does and then you can run it in in byoc where everything is inside the customer's vpc that's what for example Anthropic does
swyx [37:38]: What I'm hearing is that this is probably the best CRO job for somebody who can come in and help you with this?
Simon Eskildsen [37:46]: like turbopuffer hired like, I don't know what number this was, but we had a full time CFO as like the 12th hire or something at turbopuffer. I think I hear a lot of companies, I don't know how they do it like they have 100 employees and not a CFO. it's like having a CFO is Money Mike like he just you know just handles the money and a lot of the business stuff and so he came in and just helped with a lot of the operational side of the business so like COO CFO like somewhere in between
swyx [38:16]: to quickly mention Lachy just because i'm curious i've met Lachy and like he's obviously a very good investor and now he's physical intelligence um I call it journalist super angel right he invests in everything um and I always wonder like you know is there something appealing about focusing on developer tooling focusing on databases going like i've invested for 20 years in databases versus being like a Lachy where he can maybe like connect you to all the customers that you need
Simon Eskildsen [38:39]: This is an excellent question. No one's asked me this. Why Lachy? Because... There was a couple of people that we were talking to at the time. And when we were raising, we were almost a little, we were like a bit distressed because one of our peers had just launched something that was very similar to turbopuffer. And someone just gave me the advice at the time of just choose the person where you just feel like you can just pick up the phone and not prepare anything and just be completely honest. And I don't think I've said this publicly before, but. I just call Lachy and was like look Lachy like if this doesn't have pmf by the end of the year like we'll just like return all the money to you but it's like I don't really justine and I don't want to work on this unless it's really working so we want to give it the best shot this year and like we're really going to go for it we're going to hire a bunch of people and we're just going to be honest with everyone like when I don't know how to play a game I just play with open cards and Lachy was the only person that didn't that didn't freak out he was like i've never heard anyone say that before as I said I didn't even know what a seed or precede round was like before i'd probably even at this time so it's just like very honest with him and I asked him like Lachy have you ever have you ever invested in database company he was just like no and at the time I was like am I dumb like but I think there was something that just like really drew me to Lachy he is so authentic, so honest, like, and. there was something just like I just felt like I could just play like just say everything openly and that was that was I think that that was like a perfect match at the time and and honestly still is he was just like okay that's great this is like the most honest ridiculous thing i've ever heard anyone say to me but like that like that
Alessio Fanelli [40:16]: Why is it ridiculous to say competitor launch this does not work out?
Simon Eskildsen [40:20]: It was more just like if this doesn't work out i'm going to close up shop by the end of the month the year right like it was I don't know maybe it's common I i don't know he told me it was uncommon okay I don't know um that's why we chose him and he'd been phenomenal the other people were talking at the time were database experts like they knew a lot about databases and Lachy didn't this turned out to be a phenomenal asset right I like justine and I know a lot about databases the people that we hire know a lot about databases what we needed was just someone One who didn't know a lot about databases, didn't pretend to know a lot about databases, and just wanted to help us with candidates and customers. And he did. And I have a list, right, of the investors that I have a relationship with. And Lachy has just performed excellent in the number of sub bullets of what we can attribute back to him. Just absolutely incredible. and when people talk about like no ego and just the best thing for the founder I like I don't think that anyone like even my lawyer is like yeah Lachy is like the most friendly person you will find
swyx [41:20]: okay this is my most glorious recommendation i've ever heard yeah
Simon Eskildsen [41:23]: He deserves it. He's very special.
swyx [41:25]: yeah okay amazing
Alessio Fanelli [41:27]: Since you mentioned candidates, maybe we can talk about team building, you know, like especially in a step, it feels like it's just easier to start a company than to join a company. I'm curious your experience, especially not being in a staff full time and doing something that is maybe, you know, a very low level of detail and technical detail.
Simon Eskildsen [41:46]: Yeah, so joining versus starting. I never thought that I would be a founder. I would start with like turbopuffer started as a blog post and then it became a project and then sort of almost accidentally became a company and now it feels like it's it's like becoming a bigger company. That was never the intention. The intentions were very pure. It's just like, why hasn't anyone done this? And it's like, I want to be like, I want to be the first person to do it. I think some founders have this like, I could never work for anyone else. I really don't feel that way. Like, it's just like I I want to see this happen and I want to see it happen with some people that I really enjoy working with and I want to have fun doing it. And this has all felt very natural on that sense. So it was never like joined versus found. It was just this found me at the right moment.
Alessio Fanelli [42:30]: Well, I think there's an argument for you should join Cursor, right? So I'm curious like how you evaluate it. okay I should actually go raise money make this a company versus like this is like a company that is like growing like crazy it's like an interesting technical problem I should just build it within Cursor and then they don't have to encrypt all this stuff they don't have to obfuscate things like was that on your mind at all or
Simon Eskildsen [42:56]: Before taking the small check from Lachy, I did have a hard look at myself in the mirror of like, okay, do I really want to do this? and because if I take the money I really have to do it right and so the way I almost think about it is like you kind of need to have like you kind of need to be like fucked up enough to want to go all the way and that was the conversation where I was like okay this is going to be part of my life journey to build this company and do it in the best way that I possibly can because if I ask people to join me ask people to get on the cap table then I have an ultimate responsibility to give it everything thing and I don't think I think some people it doesn't occur to me that everyone takes it that seriously and maybe I take it too seriously I don't know but that was like a very intentional moment and so then it was very clear like okay I'm gonna do this and I'm gonna give it everything
Alessio Fanelli [43:48]: A lot of people don't take it that seriously.
swyx [43:51]: uh let's talk about you have this concept of the p99 engineer uh people are 10xing everyone's saying you know maybe engineers are out of a job I don't know but you definitely see a p99 engineer and I just want you to talk about it
Simon Eskildsen [44:05]: Yeah, so the p99 engineer was just a term that we started using internally to talk about candidates and talk about how we wanted to build the company. And, you know, like everyone else is like, we want a talent dense company. And I think that's almost become trite at this point. What I credit the Cursor founders a lot with is that they just arrived there from first principles of like, we just need a talent dense. talent-dense team and I think I've seen some teams that weren't talent-dense and like seen the counterfactual run which if you've run and been in a large company you will just see that like it's just logically will happen at a large company and so that was super important to me and Justine and it's very difficult to maintain and so we just needed we needed wording for it and so I have a document called traits of the p99 engineer and it's a bullet point list and I look at that list after every single interview that I that I do and in every single recap that we do and every recap we end with I end with um some version of i'm going to reject this candidate completely irregardless of what the discourse was because I want to see people fight for this person because the default should not be we're going to hire this person the default should be we're definitely not hiring this person and you know if everyone was like i'll maybe throw a punch then this is not the right career
swyx [45:24]: Do you operate like if there's one there must have at least one champion who's like yes I will put my career on on the line for this you know yeah on the line maybe like a chair yeah you
Simon Eskildsen [45:34]: you know like um I would say someone needs to like have both fists up and be like i'd fight right and if one person said then okay let's do it right um and it doesn't have to be absolutely everyone right and like the interviews are always designed that you're checking for different attributes and if someone is like when it's like knocking it out of the park in every single attribute that's that's fairly rare um but that's really important and so the traits of the p99 engineer there's lots of them there's also the traits of the p like triple nine engineer and the quadruple nine engineer
swyx [46:02]: Okay.
Simon Eskildsen [46:02]: right this is like it's a long list um i'll give you some samples right of what we what we look for I think that the p99 engineer has some history of having bent like their trajectory or something to their will right some moment where it was just they just you know made the computer do what it needed to do there's something like that and it will occur to them at some point in their career and hopefully multiple times, right?
swyx [46:29]: Give me an example of one of your engineers that like
Simon Eskildsen [46:31]: I'll give an engine. So we launched this thing called ANN v3. We're also working on v4 and v5 right now. But ANN v3 can search 100 billion vectors with a p50 of around 40 milliseconds and a p99 of 200 milliseconds. maybe other people have done this I'm sure google and others have done this but we haven't seen anyone at least not in like a public consumable sass that can do this and that was an engineer the chief architect of turbopuffer Nathan um who more or less just bent this the software was not capable of this and he just made it capable for a very particular workload in like a you know six to eight week period with the help of a lot of the team right it's been there's numerous of examples of that like at turbopuffer but that's like really really bending the software and x86 to your will it was incredible to watch um you want to see some moments like that.
swyx [47:23]: Isn't that p999?
Simon Eskildsen [47:31]: Nathan is uh Nathan is like yeah there's a lot of nines off that p. so I think that's one trait I think another trait is that uh the p99 spends a lot of time looking at maps generally it's their preferred ux they just love looking at maps you ever seen someone who just like sits in their phone and just like scrolls around on a map or did you not look at maps a lot?
swyx [47:52]: I guess i'm not appearing there I don't know but uh
Simon Eskildsen [47:55]: What about trains do you like trains?
swyx [47:58]: No, I mean they're okay. This is just like weaponized autism is what I call it.
Simon Eskildsen [48:04]: um I love looking at maps like it's like my preferred ux i'm just like I you know I like lots of different things.
swyx [48:10]: of like random places?
Simon Eskildsen [48:11]: Yes
Alessio Fanelli [48:12]: So instead of like random places Like how do you explore the maps?
Simon Eskildsen [48:17]: no it's it's just a joke.
Alessio Fanelli [48:19]: It's like you are just obsessed by something and you like studying a thing.
Simon Eskildsen [48:24]: the origin of this was that at some point I read an interview with some IOI gold medalist and it's like what do you do in your spare time it's just like I like looking at maps I was like I feel so seen like I just like love like scrolling I was like oh canada is so big where's baffin island i don't know I love it um anyway so the traits of p99 p99 is obsessive right like there's just like you'll you'll find traits of that we do an interview at at turbopuffer or like multiple interviews that just try to screen for some of these things um so There's lots of others, but these are the kinds of traits that we look for.
swyx [48:55]: I'll tell you, as some people listen for like some of my dev rel stuff, I do think about dev rel as maps. You draw a map for people. Maps show you what is commonly agreed to be the geographical features of what a boundary is. And it also shows you what it's not doing. And I think a lot of like developer tools companies try to tell you they can do everything. But like, let's be real, like your three landmarks are here. everyone comes here and in here and in here and you draw a map and and then you draw a journey through the map and like that to me that's what developer relations looks like so I do think about things that way
Simon Eskildsen [49:29]: I think the p99 thinks in trade-offs, right? The p99 is very clear about, you know, hey, turbopuffer, you can't run a high transaction workload on turbopuffer, right? It's like the right latency is 100 milliseconds. That's a clear trade-off. I think the p99 is very good at articulating the trade-offs in every decision. Which is exactly what the map is in your case, right?
swyx [49:50]: Yeah, my world, my world.
Alessio Fanelli [49:54]: How do you reconcile some of these things when you're saying you've bend the will the computer versus like the trade-offs you know I think sometimes it's like well these are the trade-offs but the three nines it's like actually it's not a real trade-off because we can make something that nobody's ever made before and actually make it work
Simon Eskildsen [50:12]: The way I think about the bending trajectory to your will is... If you sit down and do the napkin math, right, where you're just like, okay, like if I have 100 machines, they have this many terabytes of disk, they have this bandwidth, whatever, right? And you sit down and you just do the like high school napkin math on this is how many QPS we should be able to drive to it. Similar to how I did the vibe pricing, right? If you can sit down and do that and then you observe the real system and you see, oh, we're off by like 10x. Bending trajectory to your will is like just making the software get closer and closer to that first principle line. the p99 might even be able to cross the line right by finding even more optimizations than than than from first principle so bending the software to your will is about that right like 100 millisecond p99 to um to S3 I mean now you're talking like someone really high agency that like goes to seattle finds the S3 team and it's like how are we going to make this 10 you know like it's that's not quite what we talk about right but yeah
swyx [51:11]: What's the future of turbopuffer?
Simon Eskildsen [51:13]: turbopuffer started out, act one of turbopuffer was vector search. That's was all we did to begin with. Act two of turbopuffer is is and was full-text search. turbopuffer today has a fairly state-of-the-art full-text search engine. We beat Lucene on some queries, in particular very long queries that we've optimized for because those are the text search queries we see today. They're generated by LLMs or augmented by LLMs and we see them on web-scale data sets, right? Like someone searching for a very long text string on all of Common Crawl. we beat Lucene on some of those benchmarks and we expect to continue to beat Lucene on more and more queries. That's the performance and scale. turbopuffer does phenomenally now at full-text search performance and scale. What we've worked on now is more and more features with full text search. People expect a lot of features with full text search and full text search is still very valuable, right? If you go in and you press command K and you search for "SI" and embedding based search might be like, oh, this is something agreeable because that's si that's yes in Spanish, right?
Alessio Fanelli [52:21]: That's in Italian too.
Simon Eskildsen [52:22]: But in full text search. that's the prefix of maybe a document of like you know these are all the reasons I hate simon right like this this is like that's a completely different so that augmentation to like how the human brain works and mapping like data to user is very important but it's a lot of features that feature drawing is what we're firmly on and you will see us just adding to the change log every month just more and more full text search features um so we're like fully compatible and we see we're seeing people move from some of the traditional search engine onto turbopuffer for um for that that's a big focus of turbopuffer this year the other the other focus of turbopuffer this year is just on scale we're seeing more and more companies that want to search basically common crawl level types of data sets um both internally a company and externally at a time like query like 100 billion vectors or 100 billion documents at once this is tricky and we want to make it cheaper and we want to make it faster um that's a big focus for turbopuffer this year that's you know we just released ANN v3 which we talked about before we're working on ANN v4 and we're also at plan but we're going to do it ANN v5 right and then on full tech search we're working on a lot of these features will be like FTS v3 but it will all roll out incrementally those are some of the really big features and then the other thing is our dashboard have any of you ever logged into the turbopuffer dashboard there's not very much there it almost looks like if um a founder two years ago just sat down and wrote enough dashboard that there was at least something there and then other people just sort of added stuff on for the next two like the the following two years and then at some point as a so and other things to just catch up and it may or may not be what happened but adding like I want php my admin back like do you guys remember like it was it was so good right And I think that that like software hardware integration between the dashboard of the console of the database and the database itself, I'm really excited for that. There's lots of other things that are going to come out in the next two. Like we talked a bit about some pricing and things like that, but those would be some of the big hitters right now.
swyx [54:25]: You talk about eras of like turbopuffer. I just I have to ask like yes there's the stuff that you're working on this year but like i'm sure in your mind you already have the next phase that you're already thinking about
Simon Eskildsen [54:35]: Act three, act four, act five?
swyx [54:40]: the candidates, yeah
Simon Eskildsen [54:43]: I'll just say that if you want to build a big database company, the database over time has to implement more or less every query plan. because when you have your data in a database you expect it to over time not just search but also hey I want to aggregate this column I want to join this data all of that but when you're a startup your only moat is really just focus so you have to lay out the acts and you have to not get overeager and i think we've seen some of our peers get very overeager and overextend themselves and what I keep telling the team I was just having breakfast this morning with our cto and chief architect and we were talking about like what we're most likely to regret at the end of the year is having tried to do to do too much. And so actually candidates could be, you know, a bunch of simpler OLAP queries, right? It could be lending ourselves a little bit more into, we see some people who want to do traces and logging and things like that, some very simple use cases could be that, right? It could be maybe some time series, some people are trying to do that, right? Like there's lots of different things that you can do with turbopuffer, but for now, like if you're trying to do not search on turbopuffer, it's the primary use case. use case you probably shouldn't but we see some customers that are like oh um like at some point Cursor moved like 20 terabytes of Postgres data into turbopuffer because like it's it's there it works and these particular query plans we know work well and so they just moved it all to defer sharding um so we look for patterns like that in what future acts of turbopuffer are going to be before firmly doubling down on them but we wouldn't if today if you're using turbopuffer it should be because search is very important very important to you. And then we might do a lot of auxiliary queries to that, but that should not be the main reason to go to turbopuffer at this point in time.
swyx [56:19]: Yeah. You didn't mention one thing I was looking for was graph type queries, like graph database graph queries. Can you basically trivially replicate this with what you already have?
Simon Eskildsen [56:29]: we see some people doing that because
swyx [56:30]: You have parallel queries and it's the same thing.
Simon Eskildsen [56:33]: exactly so we see some people doing that right like at the under like turbopuffer is just the kv right and then we expose things on top of it so we are seeing people do that and I think you know our roadmap is very much just The database that connects AI to a very large amount of data is what the path is to do that in the right order, which is what a good startup is around. What is the order to do things in? Our customers are p99 and they will tell us what they care most about next. And so some of them are doing graphs now and if they need more graph database features, they'll be banking our door and we'll prioritize accordingly.
swyx [57:04]: Okay, give us the tea. You kindly gifted us your favorite tea. This is... is yabukita kamairicha from the green tea shop
Simon Eskildsen [57:13]: That's right.
swyx [57:14]: Talk about your love of tea
Simon Eskildsen [57:15]: Yeah, we were just talking beforehand about caffeine, I think. And especially when I'm on a trip like this to San Francisco, I consume a lot of caffeine. But this is my preferred caffeine. It's this green tea. I have an air table with 200 teas that I've tried over time over the past like 15 years. And this one is my favorite. now when you drink a tea um there's different there's like six different types of tea I like green tea in particular i generally prefer chinese green tea and I don't really like japanese green tea but this little prefecture somewhere in japan has specialized in like they're like japanese but doing it the chinese way and it's just phenomenal but then the interesting thing about the tea world is that all of the different um like you can find this particular tea there's probably probably you know hundreds of places that sell it but they all go to a different family right on whatever mountain that they have these like camellia sinensis bushes on and this woman japanese woman in toronto from the green tea shop um I don't know she just like has found a really good family because that's the best one the best time of year to get this is in a few months when they do the spring harvest uh now it's like kind of old um it's just like I love the spring for the fresh tea so I hope you enjoy it but it's not the right time of year
swyx [58:33]: it's out of season
Simon Eskildsen [58:35]: Yeah.
swyx [58:35]: actually didn't even know tea has seasons this is how unsophisticated I am but I think it like it ties in with like you know loving rats and being obsessed and being p99 everything that you do um yeah but that's great
Alessio Fanelli [58:49]: Awesome. Well, as we were saying, we have instant hot water at Kernel. So any tea lover can come by anytime.
