Simon Hørup Eskildsen from turbopuffer

Okay, imagine this. You got an idea for a great tech startup and you think it's going to change the world, but you have a problem. You just don't have the engineers that you need to make it come true.

Why?

Well, it's obvious. It's hard to find engineers. There's a lot of competition and when you're trying to keep your burn rate low, you need to conserve cash. Now imagine you had a partner who could provide you with almost half a million on demand developers right away. Now, this isn't another outsourced agency. They'll actually add engineers directly to your team and even relocate top talent to Canada for you. Let me introduce you to VanHack. Startups of all sizes choose VanHack because they only offer handpicked developers with three or more years of experience and who have strong portfolios. Great Canadian tech startups like NEO Financial Fair, Wattpad, Applied Board and League have worked with VanHack and they had amazing experiences. Go to vanhack.com and check out their talent pool without having to log in and see for yourself. And when you sign up to tell them, Evan from the hard part sent you for a 25% discount. Float is complete business finance for Canadian companies. They offer modern financial services, powerful software and industry leading support designed for every industry and stage of growth. Their integrated suite of products including corporate cards, fx, bill pay, expense management and high yield accounts gives finance teams everything needed to manage spending and cash flow efficiently so they can help pace with the demands of their business. I am a huge fan of Float and almost every founder and investor I meet with in Canada when we go out somewhere whips out their Float card and the team is constantly shipping and I'm hugely impressed and have been tracking their journey since the beginning. To learn more, visit Float Financial.

Com.

Just because the economy is uncertain doesn't mean your shred claim has to be. Bloom is all about predictable value. They're the only shred firm that guarantees their work. They meet with you every quarter, order and show you exactly how much you've accrued. And their pricing is posted online with a cap so you know what to expect. No guessing, no surprises. Head to Shred CA and see why more Canadian innovators are choosing Bloom as their shred partner. Hello everyone and welcome to the hard part. The hard part is focused on interviewing Canadians in tech.

Regardless of where they are, whether they're

based in Canada, the U.S. or anywhere else. We dive into the stories, the tactics, trying to get into the meat of what's behind companies, venture firms, operators and more. We really trying to shine a light on Canadian tech. The stories are undertold versus our American counterparts and sharing these stories is incredibly important to inspire the next generation of builders.

Simon, I'd love to start with some of your case studies. Like obviously I was on the site, cursor notion, linear, some like awesome, awesome companies. I'm sure there's others as well, but just kind of curious. I think it's a great way to start the episode is talking about customers and how customers use Turbo Puffer. We'll just kind of help that audience have a good understanding and set that base for the rest of the episode.

I think a little bit of background on me and the company and then we'll get into some of the case studies. I spent almost 10 years building infrastructure at Shopify, which primarily means working on the database layer and the data database. That company that I started two and a half years ago is one to build a new type of search engine, a search engine that is 10 to 100 times cheaper than the incumbents at the time. What a search engine does, right, is that you give it an enormous amount of unstructured data, like text or images or whatever, and then it allows you to search across that and find, you know, a song that is similar to another song or an image that is similar to some piece of text, right? Maybe you're searching for images of buckets or whatever and the semantic model will know how to do that. So we found a way to make that orders of magnitude cheaper than everyone else. And that turned out to hit the market at just the right time, as every company on earth was trying to connect enormous amounts of unstructured data to LLMs or transformer models in general. So I realized that there was a new storage architecture you can do to realize these gains. And I think to create generational database companies, you need the ingredients of a new workload. In this case, connecting large amounts of data to an LLM through a search engine with better economics. And the second one is that you need a new storage architecture that allows you to store the data in a different way, either for more performance or generally for lower cost in our case. So I built it in the summer of 2023. It was just me at the time and the day that I launched a small company in Hayes Valley, San Francisco, reached out and said, hey, we're using a vector database today and we're using it to search enormous amounts of code, and our bill doesn't line up with the value that this is providing for us. We Want we're okay if it's slower, but we need the economics to work out. That company's name was cursor. And in 2023 this was a small company with, you know, probably around six to seven people in a small office in Hayes Valley, San Francisco. And so I went there and I went to the office and at the time there, when I waltzed into their office, their postgres database was having issues. And I helped. So I helped them figure that out and come up with a plan for what they needed to do to a postgres database to make it healthy. Because of course in 2023 was when the hockey stick had started per cursor and I must have impressed on them that maybe I knew a thing or two about databases and they decided that okay, well maybe we can make it work on TurboPuffer. And they migrated from a database that had a more traditional storage architecture that was onto TurboPuffer and realized a 95% reduction in cost by moving to us. And of course now we're recording this, almost two years later we still power Cursor. They're obviously one of our biggest customers. And if you use Cursor today and you open up code in cursor, it's indexed into TurboPuffer. And if you follow along with the agent is doing, we're saying where's the code doing this, where's the code doing that? That's all using TurboPuffer underneath. So probably many of your listeners are using TurboPuffer every single day. Another one of our customers is Notion and they use Turbo Buffer for similar reasons. They have enormous amounts of text, obviously images, attachments, all these different types of data and they want to connect that to LLMs in the same way that cursor connects the two LLMs to give you better code completion and, and code suggestions and so on. Notion uses it to. You can ask the workspace any question and, and, and the LLM will help answer it and give you a summary. They use TurboPuff for similar reasons, right. They wanted economics that lined up where they could search enormous amounts of data and connect it to LLMs. And LINEAR is really the same story, right? They have a lot of data and they expect that they're going to have even more data. And TurboPuffer sort of serves as that foundational search area that powers all these SaaS features that we now expect from an AI enabled SaaS product.

I think most listeners are definitely like familiar with LLMs at a high level and how they work. I'm curious from like that search aspect of like, hey, whether it's searching through like the Internet or an internal company's database or code or whatever, how is like search been done, like from an existing standpoint? And how does kind of Turbo Puffer kind of reinvent that for this age of AI and all these things that kind of come with that?

So traditional search is a great question. Traditional search is what we call lexical search. Lexical search is essentially I search in a very large corpus's text for Evan and every document that matches Evan will show up. If a document matches Evan multiple times, like it's talking a lot about Evan, then it will rank higher. And one of, of course, the, the, the original search engines was Google, right? What search is really about and lexical search is about is ranking the search results. So, okay, there might be a lot of articles that mention Evan, and maybe the ones that mention Evan many times are more important than those that mentioned it just once or not at all. But the, obviously the insight behind Google was, well, if, if New York Times mentions Evan, then that's going to be a more important article than someone putting it on their dinky block on geocities, right? And, and the way that we know that New York Times is scalably a, an important source of information is that it has a lot of other links, right? So lots of people are linking into New York Times. That was the fundamental insight that led to Google, right? So it's just you search for text and then you do this ranking. This algorithm is called PageRank. That is more or less how we've done search until more or less into the 2010s where we just got really good at matching on some text. That's how we, we, we did search also at Shopify when I work there, right? If likely research protects. And then you do certain things like, okay, I'm searching for, I'm searching for a shoe, but everywhere in the catalog it's called a sneaker. So we train a big synonym dictionary, right? A thesaurus of all these words and all these things to try to optimize these queries. We look at queries that don't have a result. And if we do these things, we might say, okay, well if sneakers in the title, then it's more important than maybe there's like a sneaker cleaning kit, right? And that would be less important important. So we do all these kinds of things to, to try to make lexical matching good. Lexical matching works. Well. The problem with lexical matching is that it more or less takes like a team of PhDs to do really good search results with Lexical matching, right? Because you were trying to take these big strings of texts and turn them into things, right? Because like you don't if you're searching for red dress on an e commerce store and they have a burgundy skirt, like you don't care if they don't have a red dress, you still want that burgundy skirt to match. And training and creating a search algorithm just using strings and text is very difficult now. We've entered now a new era of how we do search with these things called vectors or vector embeddings, depending on the context. The way, easiest way to think about vector embeddings is that you can kind of chop the head off of an LLM and out comes numbers. And what those numbers are are essentially coordinates in a coordinate system. So if you bring up your, you know, like your grade seven, like X, y axis and plot a point, well, two points close to each other would be things that would be semantically close to each other. So what that would mean is that you search for red dress and you plug that into the coordinate system. Well, that burgundy skirt is going to be really close by, right? And the, the shoes are going to be, you know, adjacent. The red shoe is still adjacent to it, but it might not be a very good match. And these, these beddings of course are very good at synonyms, right? Like if you ask it for a synonym, it can come up with some of the best ones that you could ever imagine because it's very good at finding relationship between things. And so that's the big development in search, is that now we have these vector embedding models starting in the 2010s and really have become ubiquitous in the 2020s, where we can do sort of Spotify grade, song similarity search or photo search very, very easily. So now we don't have to turn strings into things. We just give a thing or a photo an unstructured piece of information and then out comes a point in a coordinate system where things adjacent in that coordinate system are also generally adjacent in the real world. That's the big development. The problem is that the traditional search engines don't really support this because these coordinates are not in two dimensions. They're actually more like in 3,000 dimensions. So you have 3,000 numbers for every piece of text. So often that like that point in a 3000 dimensional space is larger than the original data. So you now have this text, say you have maybe 200 bytes of text, 200 characters of text, and it could turn into almost 10 kilobytes of vector data. So you have this like all these points in this coordinate system that are producing really good search results. But it's so expensive because for every kilobyte or gigabyte of data you store, you actually have to store tens or even hundreds of gigabytes of data to make it searchable. But the search results are so good, so it's hard to resist. And the innovation of Terrible Buffer is now we can do the vector search at similar prices or even cheaper than we could do the text search in the past. And the results are a lot better

if we get into the technical aspect of what goes behind, making that more efficient, adapting to this vector search. With all these AI companies, what exactly is going into that infrastructure? What exactly is happening from a technical standpoint where you can decrease that cost with all this increase in data?

So fundamentally, there's three ways to store a byte of data in a computer. There's a couple of others, right, and some that are. But these are sort of the fundamental ones. The first one is memory, right? So good old dram, and this costs you about $5 per gigabyte per month to store. A lot of databases rely on the majority of the data being in memory. But this gets very expensive very fast, right? $5 per. Per gigabyte per month. And because memory is volatile, you know, you, you reboot the box and the memory is no longer there. You have to often store copies of the data or store it on disk. Then you have disks. Disks, when you account for a bunch of different factors, cost around $0.20 per gigabyte per month. So it's nice because it's an order of magnitude, right, 20 times or so cheaper than storing in memory. But it's also about 100 times slower. And when you store something on a disk, that disk can fail. Probably many of you have had a disk that failed on a, like security camera or whatever, right? So they fail. So you generally have three copies because then it's very unlikely that you're going to lose data. So in reality, you're not actually paying 20 cents per gigabyte. You're paying for three disks, right? So you're paying 60 cents per gigabyte. Three times 20 cents, right? So it's, it's still pretty expensive per byte. Now there is today there is a third way to store data that. Where more data is stored probably in the clouds than anywhere else, which is S3. S3. And what S3 is, is that it's essentially just a Very large farm of very, very slow disks that Amazon and Google and others can buy at ridiculous prices. And they can get the cost down to around $0.02 per gigabyte if you store it there. The downside is it's very slow. The probability that you're going to lose the data is extremely low, but it's pretty slow. And so what we built is a database that stores everything on S3 right at these $0.02 per gigabyte. That is 30 times cheaper than storing it on disks and it's a hundred times cheaper, actually 200 times cheaper than storing it on, in memory. So at the at from first principles, right? Then if we take all the data and put it in S3 and it's really slow. Well what we can do is that if you're actively querying the data, we can cache it on just one disk. And if we cache it on the disk, we can run it on lower cost disks that cost less than 20 cents per gigabyte. We can actually do it at around 8 to 5 cents per gigabyte. And we can also get cheaper memory for a variety of reasons. So now if you're actively using the data and we need to have it in memory, then we can have it there. But we only need one copy instead of three. So still, even when all the data is actively used, it costs less. That would be the main innovation is that we build a database that is taking advantage of the S3. And no, at the time there was not an example of a database that had been built that way.

What are some, some trade offs or some things that, you know, maybe that is not a good fit for. Like obviously we like are focusing on a lot of these AI companies, but is there some trade offs there?

Yeah, so the trade off is, the fundamental trade off is that writing into S3, into this $0.02 per gigabyte place to store data is a bit slow. It can take a couple hundred milliseconds for a search workload. That's generally fine. Like often a lot of these things happen in the background. Like you update some code and then it gets indexed in the background. You update your notion page and it takes a couple hundred milliseconds. Now if you're trying to run, if you think about this as a generic database and not just a search engine, then and you're trying to do like an E commerce website and you're doing transactions to like Capture payments, then 100 to 200 milliseconds every time you have to write might be too slow. That would be the Fundamental trade off. The other trade off is that because all the data is not always in RAM or always on a disk and sometimes has to be fetched from S3. When it has to be fetched from S3, it takes about a half a second. So it can be a little bit slow when we don't cache it on some of these more expensive, faster storage mediums. If, if it's, if it hasn't been

used recently, like, if I'm taking a look at like the architecture page, right? So like the client can access everything through API. We talked about S3. What about like this, this cache kind of like memory component. Like, how does that kind of come into play and how does that, can that help increase the speed or offset some of these trade offs?

When you open a code base in cursor, you open a notion workspace, right? It will send a request to TurboPuffer to start putting it into cache so that we're ready to serve the request when it's there. Then only some percentage of all of that needs to be in cache at all times, which means that we can have these better economics. So that's what the caching layer helps with. So fundamentally, when it's warm, it's just as fast as everyone else. And you just have to hint to us that, hey, I'm gonna, I'm about to start using this and then we can put it into the cache.

Can we dive a bit more into like what cache is like? I'm sure everyone's gone like, oh, you gotta clear your cache. You know, your Chrome browser is running slow, whatever that may be. How have you really, like utilized the cache? What is it fundamentally? And like, how does that kind of really assist Turbo buffer?

When we talk about building databases, we talk about like, where, where, where is the source of truth of the data? Like, where is it, where do, where is it actually committed to? And in this case it's 2s3, right? And so caching is really just like, it's a volatile medium, right? If it goes away in a minute and it's there the next, it's really just to make it faster to access the second time. Similar to on your machine, when you load a piece of software or a very large document, it will exist on the disk and then we'll load it into memory. And then when you're not using the document anymore, slowly it will just move it out. So the cache is sort of just for performance. It's there when you're actively using something. And the source of truth is where, what Actually has is given the, the responsibility of making sure that this data never goes away.

How do you think about like growth and scale? Right. Like obviously you gave that kind of like Cursor story and like notion linear. These are all massive companies and scaling tremendously. Working with Turbopuff or working with like a small startup just initially, okay, like things are working, but as these companies are just scaling at a tremendous level, how have you kind of like maintain that, especially from like a database company and being like a key piece of their infrastructure?

Cursor is one of the fastest growing companies in the history of time. And fortunately scaling Shopify for so many years meant that we put a lot of the lessons we learned into scaling very, very quickly into, into how we think about writing software. So I'm very proud to say that Cursor has repeatedly mentioned that we're one of the only pieces of infrastructure that they have not had to worry about as they've scaled right to a billion in annual recurring revenue and all of the traffic that goes along to that. Turbo buffer has been one of the most reliable pieces of software. So we've done of course lots of work for Cursor, but overall we've stuck to the same principles of how we've developed this database in a way that we knew would be incredibly scalable from everything we learned at Shopify and everything we've learned since then. So it has not been a distraction where we've had to firefight. It's been a very, very stable product based on all of the assumptions that we made. Right. They were essentially a design partner. So we knew the workload very well. When you look at something like Cursor and you, you work the product and the constrained around the scale that it brings, it affords a lot of room for everyone else that we can run on very, very low utilization. Right. It's like you learn to play soccer with an iron football, you're going to be really good by the time you just get a normal one. Right. So now we have like, we have customers, right, that are, that are, that are trying similar like or that are trying to be at the kind of scale that even Cursor sees. Right. But we, we, we've just grown up with that scale. We don't know any different. And so the, the small, it works incredibly well for the smaller companies.

I think for me it's just like being in the driver's seat of like fundamentally like this shift. Like obviously AI native companies are, you know, needing that kind of solution like TurboPuffer. But you're seeing all these other companies being AI adopters, whether they're like traditional industries or existing tech companies. How do you just see this kind of like industry shift, like those conversations that you're having?

I think we see two types of companies right now. We see the ones that are doing fairly simple ways to connect LLMs to their data. So generally they'll use existing tools to bring context that they have within their company into the context window of the LLM. That's most companies, that should be the first iteration for most companies to understand how to do it. But what we now see from the frontier companies like Cursor and Notion and Linear is that they want to have very tight control over what goes into the context window and they want the amount of data they can pull into the context to be to draw from many more resources than it did in the past because it allows them to give better product. Right. So notion AI, for example, can connect into third party data sources to try to draw in context that's not even in notion itself. Right. Cursor draws in context from the global web. They draw in documentation context and of course even from other code bases than the one you're working on. So the frontier of AI we see right now is really around not just what like giving data to an LLM, but finding the right data to give to an LLM. And for that, those frontier companies is where something like turbopuffer makes a lot of sense because you can't get away with just taking all the data you have on a customer, stuffing it into the LLM and hoping for a good result. You need to draw on way, way, way, way more data in a way that doesn't fit in the context window. It's not performant or the cost is not there for doing it. So that's generally what we see now at the frontier and where TurboPuffer is fitting into these companies.

With TurboPuffer, like having to ingest all the, say, like we talked about cost, we talked about speed. How about just like that, that volume, just like that amount of data like you talked earlier about like just so many more data points. How are you kind of like learning from all these things? How are you scanning all these things? How are you going through all these things kind of in like an efficient manner and like delivering like that value to the context? I'm just like, for me it's just kind of like it feels like overwhelming. So how are you kind of building a solution to kind of deal with that quote unquote overwhelming issue?

So Are you thinking about it in terms of like, how do they pump all the data into turbopuffer? Or are you thinking about it in the, in the context of how do we, how do we manage all that data?

I think two pieces like, yeah, like, how are you actually like pumping that in, in like an efficient way and making that work and, and then just on, on your end as well, like, just with like that amount.

So, so in terms of the pipeline is the turbopuffer. Generally most companies have something that they use for moving data from A to B and generally they'll use that for turbopuffer. We try as hard as we can to not be the bottleneck so that you can just throw as much as you want after that. And we found with many of our customers, that's worked really well because often you have to do very large backfills into turbopuffer. On our side, one of the largest scalability concerns with these things is the storage layer. S3, where we store the data, is one of the most SC systems on the planet. So we can drive tens of gigabytes per second into that system as long as we've implemented our side efficiently. So that's generally the hardest part about building a database is scaling that storage layer. But we have the large teams at Google and S3 doing a lot of that so we can focus on the database features that our customers want and performance on the parts that we control. You give up a little bit in performance here, but you make up for it in the insane volumes of data that you can pump through without, without needing that, you know, like one millisecond latency before recording.

We just talked about, you know, like that important things with a database company. And obviously when building a company, everything is important. I'm not saying that like there's some things that are more important that than others, but with a database company, what kind of nuance exists there? Like, what key. Whether that's like hires or decisions from a product perspective or ways that you operate you think are critical to being successful.

I think that at a database company, if you look at most databases generally there's, there is a, there's a small number of individuals that are really contributing to that database and they're contributing the big insights. So you need, you need to choose those people very carefully because you need to build a database that will age well. These are, they're massive R and D projects that would take a very long amount of time. And of course at the, at the edges there would be lots of work that can be Parallelized, but on some of the most delicate parts, you will just have a small number of individuals who deliver a lot of impact and you have to trust they make the right decisions. So for us, we've always thought this and so we've been very, very picky about who we hired to work on that and build out the initial database. So we built a phenomenal team. I think we have probably the best early stage database team in the world, if you look at how well rounded it is, both on the operational from the theoretical point of view, from the database point of view, from the storage point of view, and so on and so forth. So it's really about that density of talent. This is not, in some SaaS products, you can throw more engineers at the problem and different surfaces and run more experiments. And that's a really good way to build these kinds of businesses. But you need absolute like there were very few engineers at places I've worked in the past that are at the caliber that everyone at this company are at. And that's just required when you're building a database company because it's one of the most difficult software projects that you can take on to say on that

kind of line of team, how have you really thought about, you know, finding other co founders? You know, you mentioned earlier in the conversation, 2023, kind of starting at the solo, have you found like co founders from a team perspective? How have you really thought about like, like hiring, bringing on folks, bringing on the right folks, finding those folks as a people that maybe you existed, maybe you worked with, whether it's at Shopify or just other projects. Like how have you really kind of found that? Especially early days building the company?

Yeah, I think this is, this is what makes a break to early stage companies is how, how well can the founders hire? I, I built it in, in the summer, like just me. But as soon as, as soon as we started onboarding Cursor, it was very clear to me that I needed a co founder. So I approached Justin. Justin was in my opinion the best engineer who ever worked at Shopify. Maybe outside of the initial founding team of Shopify, just a phenomenal engineer. And I approached Justin and Justin agreed to join and we made it work for Cursor. It was a very long November and December, but we made it work. And since then we expanded the team and I intentionally didn't want, I didn't want it to be all Shopify people. And in general Shopify doesn't have necessarily database expertise in the way that we knew that we needed for this team. Next person we hired for the team was Bojan Boyan and I went to IOI in when we were both in high school. Are you familiar with this competition?

No, I'm not.

So I.O.I. is a, is an international computer science competition that high schoolers around the world qualify for. So Canada has a national team. US has a national team. Around 100 countries around the world have a national team. I was on the national team for Denmark which is a small country so it was not that hard to qualify for compared to the Canadian or the American teams. But I made it on and that's. I competed for that in high school and I met there Bojan who is one of the founding engineers on our team. Bojan got a silver medal in computer science, but he also did the math competition. That's considered even harder. These are the ones that the new ChatGPT and the new Gemini models that are still unreleased have achieved a gold medal in. This is a remarkable statue because these are unknown problems that they haven't seen before. But these are all high schoolers competing at this. And Boyan did incredibly well and we met there the northern Macedonian team that he was on refer to him as God. And 10 years after, after we, I, I saw him last in, in Brisbane, Australia, we found each other again and he joined the company as the, as the first employee after Justin and I. And since then we've expanded the team like Morgan, who's in, who's in Vancouver and done a search startup while at the University of Waterloo, met on X and he joined later. Xavier, who had worked in early early on at Shopify, who'd gone to pursue a PhD in Paris for certification in Rust, joined the team and then we hired two phenomenal database engineers out of New York to start our New York office. So those were the first, first hires that we did at turbopuffer. And since then the team has grown a lot larger than that. But that's the team that's. We've done a lot with a very, very small and very talent dense team of people who are just excited to build the best database.

How have you kind of really structured things from like, like shipping. Everyone's always like talking about hey, what did you ship this week? You know, like what have you done this week? How have you really kind of structured the team? Like obviously amazing talent, amazing folks. How have you kind of structured things from like actually shipping, building product, talking to customers, also having a bit of your own kind of product roadmap and intuition there.

I think there's there's two things that we've done. So one is that I've always taken the weekly meeting that most engineering teams have incredibly seriously. For us, that's essentially a list in a notion that just has week one, you know, 20, 25, and I sit down and I write out for every single person what I think that they're probably going to be working on that week. And then we've reconcile in the meeting sort of the difference between what they're planning to work on and mine. And this works out to be an incredible flow in reconciling that diff. I'm not dictating what they should be working on. They are ultimately in charge. But reconciling the diff between my neural net and the inputs that I have, and theirs is incredible for adjusting scaling, this process is very difficult. We could get into how to do that now that we're a much larger company than, or not much larger, but larger company than we were in the beginning. But this is by far the most efficient way that I found to run an engineering team in terms of talking to customers. We consider that every engineer at turbopuffer is basically doing customer support. And we will continue to adjust this over time. Now, as we hire people who are solutions engineer and actually know how to do customer support. But working directly with all of our customers this way, Cursor and Notion and Linear and all of the others, from the very beginning has just created a culture inside of the company where everyone is so connected with the customers. Everyone has customers that they DM for feedback on features that they work on. Right. Everyone has met them. One of our engineers today is in Stockholm to work with a few of the customers there because he's normally in Paris and, like, it worked out to go meet some of our customers, right? And he's working on the database from our customer's office. I think this is something that just felt very natural to us is just to work so closely with our customers. And it really hit me that this was how much our customers value this. When at some point that someone at Notion told me that they thought about us as being part of the Notion team and we felt that others have spoken similar. It's like, yeah, it felt like you were an immediate extension to our team. When I did a case study with Linear a few months ago, the head of engineering there was saying, yeah, sometimes I'm a bit weirded out. Like, I feel like maybe we're your only customer or something with how responsive you are. I think that's exactly the kind of respect that you should pay your customer,

like you mentioned there, with scale. Would love to kind of like dive a bit deeper into that. Like as you add more and more customers, more geographies, more time zones, more team members, the things you're talking about are super, super interesting. I love those kind of concepts and those frameworks. How do you kind of think about scaling those as the business grows? Whether it's like a headcount thing, more customers, geography, et cetera.

Yeah, I mean we review constantly what are the highest priority hires for us to make. Right. And I think that we do, we do take the time zones into consider. Right. The majority of our customers are in Pacific time. So most of the people who are customer facing need to be in North American time zones. Right. Right now the team is centered on the east coast with quite a few Europeans and this works really well for us. And that's how I also built teams at Shopify. Bordering those two time zones actually works really, really great. So I mean it's pretty classical like headcount planning, right. You look at your, your, your financial planning and analysis numbers, your FP and A, and you look at what kind of hires you want to do and you just consistently every week look at the list and along with your leadership team, decide what hires it makes sense to prioritize.

I'd like to touch on this concept of like accuracy and like hallucinations or just like hey, when like this volume of data is just immense and hey, it's not just off a page rank or how many things are mentioned like what's your thoughts on accuracy? Just from a search standpoint, especially in this new kind of AI era.

Yeah, I think that's where we see that putting a search engine into your AI product really helps to make sure that model is not hallucinating by grounding it in something real. So I think that that's definitely what a lot of our customers are doing. Not just like making sure that model is not hallucinating, but also drawing in context that the model couldn't possibly know what the policies are around expense guidelines in the turbopuffer notion. So you have to somehow tell it that. Right. Otherwise it might just tell you something that's the average of the Internet. Right. So I think a search engine is very important and when you talk to frontier models, they spend a lot of time searching because they know that you can't just compress the entirety of human knowledge into, you know, 100 billion parameters or whatever the frontier models are using. It's just not possible. So you need to derive and basically yank a pipe into these models and put like classical methods on the other side. Right. It has to converse with something.

How do you think about search from like, you know, typically off keywords like hey, I'm, you know, typing in Paris or something and hey, it's pulling up all the things of Paris. But like, maybe I'm looking for like specific context, like, you know, like what time of year? Like I'm curious on the, you know, the keyword search, how is that developing? You know, I've used some AI products in the past where it's like, hey, like I want to find everyone in my network that went to that works in like AI. Like that's a very broad thing. And like how is kind of search kind of diving a bit deeper, taking that context beyond keywords?

Yeah, so it goes back a bit to what I was talking a bit about when we talked about lexical versus the more semantic search, right? Where in the lexical search you search for AI? Well, if someone has machine learning and their title is just not going to match, right. Whereas that embedding model knows that, hey, AI and machine learning are very adjacent in the coordinate system. So profiles that match both will search. So LinkedIn for sure is using an embedding based search and there's lots of startups now that will draw on and embed your network to be able to do this. I think one that I've seen people start using is one called Happenstance, right. Which will draw on the network and then try to embed this and basically plot them into this big coordinate system and then do this simple geometry to find anything that's similar. We see that used a lot, a lot of our customers are doing it for sales, right, where you try to find companies that are similar to existing companies you've already sold to, so you know who to target. So almost everything in the world will benefit from you knowing what's close to it, right.

From like an API perspective, what kind of nuances exist there just to make a really great product, a really great company in that space, like it was awesome. You're talking about, you know, very close relationships with your customers. What other things kind of go into that? When there's tools that a lot of tools that these companies are plugging into, how do you really kind of stand out and just be like really impressive on that side of things?

I think being, being on the other side of not selling, but being on the buy side my whole career of databases, I think it was very clear that when I Go to a website for any technology. I just want to know, like, what is this? How does it plug into my stack, what value does it provide, what does it cost and what are the trade offs? What are the limits? That's really all I want to know. And if you go to turbopuffer.com, that's what you find, right? It's just like, this is what it costs, this is how fast it is, this is what you use it for. These are our customers, this is what they use it for. This is how. This is the architecture, these are the limits. And in the docs you'll find the trade offs and the guarantees and everything else. And that's exactly what our customers like. We show, we don't tell and we're very transparent about when it's a fit and when it's not a fit. And in a lot of my prospect calls, I'll say, no, you're too small, it doesn't make sense for you to use it. Like you can continue to use your existing database for this particular workload because you only have a gigabyte of data. But once you get into the tens or the hundreds of gigabytes of data, which happens once you found pmf, then come talk to us. But I want the customers to have a little bit of pain before they start on us. Right. And over time we expect that we'll have feature sets and we'll be able to help our customers so much that it makes sense that even on like day zero, day Turbo Buffer is your first database.

Well, that's a. I think that's kind of a nice segue into just kind of sales, especially from like a founder LED sales. Like, how have you kind of really done that? Well, like obviously, like the story you mentioned about Cursor and I'm sure there's just organic things, like people are coming to you because they're hearing things and hearing great things. But when it just comes to that sales cycle, like, what have you kind of found of like, who's the right person to be talking to? You know, I appreciate, like in the last question, just talking about like the openness, like if anyone goes to the TurboPuffer site, they can see all these things that you were talking about. Is that a really key part of it? Maybe your experience from being a buyer as well?

Yeah, I think, I think that the sales was something that I had to learn and for better or worse, I didn't have any experience doing it. Right. I did a little bit of consulting between Shopify and Turbopuffer for, for some of my friends companies, helping them with infrastructure challenges. And I think that probably taught me more about sales than I realized until maybe a few months ago. I think it's always been very clear to me that in order to know whether someone is good or someone is really bad at something, you kind of need to have done it yourself. And so I think my philosophy on the sales was that early on in Turbo Buffer I started getting introduced to sales leaders, right? It's like, oh, you could hire this VP of sales, you could hire this person. I think the truth is that there is no zero to one sales talent. Like that does not exist. And I think you would do a discredit to anyone that you hire in a zero to one sales role. That is not a thing that is the founder or at least one of the co founders. And you need to have a co founding team or an early team where someone has the ability or is willing to learn how to do that. Because otherwise how are they going to be a sales team? How are they going to be the sales culture? Because every startup is the marriage of a good go to market and really good product execution. And if you among the founding team don't have those ingredients then you're not going to make it. So I don't think that you can. Even if you have a good product, you can hire a bunch of salespeople because the first sales, the first salesperson needs to have full control over the roadmap, right? Like if I go to cursor and I go in there and they say we need this feature, that first salesperson that's zero to one needs to be able to say that hey, you're going to get that feature tomorrow and then possibly stay up all night implementing it, right? So I don't think there's zero to one sales talent. I think that has to be the founders. In our case that was me. Like Justin is a better programmer than I am and, and I think I mind being on the call slightly less than Justin. So it made sense. It was very natural. It's not even a conversation, it's just what happened. And now of course we have, we have a sales team and I spend a lot of time with that sales team on like how do we uniquely sell turbopuffer? And I think that we uniquely do it in a way where we're very comfortable saying no, I think you should use this or I think you should use our competitor's product because it's actually a better fit for your workload or no, not Yet I think we're very confident that it will be good a lot of these things over time. But ICP and choosing the right ICP is I think also the like the CEO and the founder's job because if you try to stretch the ICP too far, you're going to kill your product team and you're going to widen your sales funnel too much. So I think the ICP and, and the founder doing it really well, like the founder needs to be the best ae. And I think that at the best companies you will find even when they're further on, the best AE is still the, are still the founders. And I don't know very many counterexamples to that.

How have you thought about pricing? And I'm not trying to talk about a specific dollar amount, but just like your pricing model, have you thought about that? You're seeing all these AI companies, it's all like usage base and all these things. Like how have you kind of thought about it and what do existing database competitors do? Have you adopted that or have you thought about something more unique for Turbo Puffer?

I think that one of the things that no one told me about starting a company was how much time you're going to spend talking about pricing. Never would have expected that. I don't think it would have made any difference if someone would have told me, other than I would have maybe felt better about the months of my life I've spent on this. To me, the pricing, it just comes from the observations on the buy side, right? You just want to know what it costs. And a lot of databases traditionally have been based on how many servers am I buying and how many CPUs that they have and how much memory. Well, I don't know. How am I supposed to know that? Right? You can't calculate that. And if the sales team on the vendor side also doesn't know, well, it depends on your workload. Just try it. It's really fast. So to me it made a lot of sense that you should be able to predict like anyone at the company who works closely with the thing should be able to go on the website, move three or four sliders of like roughly ballpark what they think the numbers are and then they should have a price that should be within some reasonable error bars of what they'll see in production. That was the pricing philosophy and it's worked very well. And then in terms of the margins on that, well, you sit down with piece and paper and you think about it from first principles, what does it cost me to store a gigabyte of data. How many gigabytes of data do I have to store per gigabyte of data? In blah, blah, blah, you do some calculations. I had to write thousands of lines of code to simulate lots of scenarios to make sure that the pricing was right. And I think pricing was one of the things that we got right. And I think that then you test it with your customers, right? You ask them straight up like, hey, like, how can you earn a return on this? That's what they care about, right? They want to earn a margin on your margins. And so that's what you just asked them. And you are the design partner, right? And you, I think if you develop a good relationship with them, but they're early customers, they, they will work with you on this. Right. And it doesn't have to be so hidden, but it's hard to get there with them. Right. But like, that's what you have to do as an early startup. You have to build the relationships and the trust that you're going to charge a reasonable amount and, but also understand and be very sympathetic in the fact that they also have to earn a return on that on the other end. And that's why they go with you in the first place.

I'd love to talk about like the pull to like move to the US Whether it's just like, you're based there, the company's based there and I find it kind of funny that you were, you worked at, you know, Shopify, which is infamous for, you know, making that decision to stay in Canada. I'm just kind of curious like what that pull has been. Like, what's your, what's your thoughts around it? Is it just a continuous thing that's always there?

If I didn't have the, the, the, the experience and, and, and like, maybe like a little bit of the pride, then we would have gone to the US a long time ago. There's just like literally no reason to stay in Canada. And so, and there would be, but you will be given a lot of reasons to go to the US right? The providing infrastructure for startups is a lot better. All of the investors are going to push you and pressure you and you may not feel like you have the levers to push the other way because they qualify for various exemptions if you're US based and they'll know how to advise you better, right? Like you'll get better legal knowledge. Like I, I had to fire three Canadian lawyers before I finally found my way to someone who could give me a good Answer to the question I wanted to know, like, just give me the pro and con. This is staying in Canada versus the U.S. those lawyers of course exist in Canada. There's maybe like, I don't know, maybe there's like a dozen of them who like really at that level, but in the US there's hundreds of them. So it's just a lot easier to find them. And so it's not that these things don't exist in Canada, it's just that they're much, much harder to discover. So I think, I think Canada could do a better job. I have like a list if you want to go through the list. I think there is, there's, I think there's cultural things and I think that there are like very practical things. But in general, other than shred, there's very little reason, even if you're a Canadian to, to incorporate and pay your like corporate taxes in Canada.

I know you got the list there and I don't want to go through the whole list because that could be a whole episode itself. But curious, like, what, what are some. You mentioned like kind of like that national pride and, and other things. Like what other kind of things have just like made you stay in Canada? Like I think it's just, you know, it's a constant question that's always on, on X and everyone's always talking about how do we stop this brain drain? How do we keep, you know, talent in Canada? Like, you know, what are some thoughts if, if you were to like advise other founders that maybe are coming to you that are just starting?

I think, I think the biggest thing is that there are like a bunch and you need to talk to a really good lawyer to fully understand this. Like there are like some, some considerable benefit if you have an exit in Canada, like in any, any way, whether by going public or by acquisition and the right lawyer. But most of them, again, there's probably only 12 that will actually walk you through exactly what this means. Right. The other benefit is that the capital gains in Canada is extremely simple and is actually better in a very large access scenario than it is in the US the meme that goes around of high Canadian taxes mostly comes down to income tax, which is a real thing. But for a startup exit for the first employees, it doesn't matter. But the big thing that Canada should just fix is that the long term capital gains exemption should just match QSPs. It's ridiculous that it doesn't because it permeates this lien. But like, I'm doing like, I'm doing tax calculations all the time when we hire Americans on like their exodus. Like the Canadian tax on capital gains is a lot better than it is in the US The Canadian one doesn't distinguish between how long you've held the healthy option and, and, and then it ends up being comparable or even better than Florida in a lot of examples. And people just don't know that. Right. And then the, the long term cable gains matching to the US equivalent just needs to be done. But I don't think that people realize that upside. I think shred is great. I think it's ridiculous how much of a cottage industry has evolved around the complexity of it. I wish you could just buy some revenue growth or whatever qualify for just getting this through and getting the subsidy. We didn't claim it for a longest time because we just didn't have time. And frankly the companies that don't have time to claim it are probably the companies that you should give it to. I have a, like a huge list. But I think that one of the things that feels ridiculous to me is just like, give me like direct flights to all the Canadian tech hubs from all the like to, to all the US Tech hubs. Like why is there not a direct flight to San Francisco from Ottawa? That's a very inhibiting factor for me.

I'd love to jump into my typical closing question. It's just how do, how do you deal with hard times? Like building a company is not an easy thing to do. Is there anything that keeps you centered or balanced? Or maybe you don't view it like that and it's more just like it gives you that horsepower, that ability to push through.

It's a total roller coaster ride to try to start a company. So you're going to go through a lot of hard times and you're going to like, you might even want to give up once or twice, especially early on when there's not as much. I think it comes down to who are you working with and do you have the emotional connection with them as well that you also feel like this is hard and you can rely on them. Right. And I think that one someone once told me that I really like this person because I feel like they spend as much time worrying about something or they're, they're going to worry as much about something as I worry about it and that you need a lot of that in a startup among the early employees. Because if you feel that there's just a few employees who are worrying more than anyone else, then it means that they're going to have to take that burden. So I think, I think it's a pretty emotional ride. And, and you've got to make sure that everyone has the support networks in place, both outside of work, but also at work to, to, to, to work through some of these. Right? Because often, you know, it's really hard for a few days and then, and then you, you, you regain it. I don't know if I, I have much more to say than that other than just being, being acceptable if that's part of the reality you signed up for.

I love it.

Simon. It's been a lot of fun. I really appreciate the time and willingness to come on the podcast and excited for all to come again.

Thank you everyone for listening to the podcast. The most important thing that you can do is follow the show on listening and viewing platforms, primarily Spotify, Apple Podcasts. If you use any other type of podcast player, YouTube X and more, this is one of the most meaningful things you can do is obviously sharing the podcast. But also just following the podcast on these platforms is the most important. That way we don't get lost in the algorithm of other social media platforms and you get the episodes straight to you automatically. Thank you for following subscribing on these platforms.