He built a new database in his bedroom—now he powers Cursor, Notion and Anthropic. | Simon Eskildsen, Founder of turbopuffer

Simon Hørup Eskildsen (00:00:00):
I was thinking about this from the second I woke up, until the second I went to bed. During the evening when my wife and I would have dinner. I was running like different runs, right? To test different theories of how this would work and experiments, and stuff like that. I think she might have a better representation of exactly what that summer was like from her point of view, but I remember it as being completely all-consuming. I need to go meet them and so I flew to San Francisco. I showed up on a Monday afternoon, and they were having problems with their Postgres database. And so I just tried to teach them everything that I knew about running Postgres at scale. That must have convinced them that maybe I knew a little bit about databases, because they felt compelled enough that they started the migration and of course, this company is Cursor. Notion had finally ingested their first workload and it was really slow. Justin found three hundred milliseconds in the span of three hours that night. There was another time where Notion asked, can we do this, Corey? And Justin just told them in Slack, yes, we can. And then worked like I've never seen before for the next 24 hours to get it in their hands. When people talk about forcing something or willing something into existence, this is one of the first things that I think of.

Previous Guests (00:00:59):
That's product market fit. Product market fit. Product market fit. I called it the product market fit question. Product market fit. Product market fit. Product market fit. Product market fit. I mean, the name of the show is product market fit.

Pablo Srugo (00:01:11):
Do you think the product market fit show, has product market fit? Because if you do, then there's something you just have to do. You have to take out your phone. You have to leave the show five stars. It lets us reach more founders and it lets us get better guests, thank you. Simon, welcome to the show, dude.

Simon Hørup Eskildsen (00:01:27):
Thank you for having me.

Pablo Srugo (00:01:28):
There's very few people I interview in this show that happen to also be from Ottawa. But you're close by, which is nice to see.

Simon Hørup Eskildsen (00:01:34):
Yeah, I'm not from here. I moved here back in the day for Shopify. That's how I ended up in the new world. But it's actually an underrated place to build a company from. It has its advantages and disadvantages.

Pablo Srugo (00:01:45):
We'll get into all this. You're building TurboPuffer, you've got some massive logos, right? Cursor, Notion, Linear, massive companies using your product and you've done it all bootstrapped. Purposefully so, intentionally so, you're keeping things pretty much under wraps. Let's start at the beginning, give me just a little bit of your background. You mentioned, where did you move from?

Simon Hørup Eskildsen (00:02:03):
Yeah, I should specify that we're not bootstrapped. We have taken some funding. Back in early 2024, we raised from one fantastic partner.

Pablo Srugo (00:02:11):
like sub a million or around there? Kind of small pre-seed type amounts?

Simon Hørup Eskildsen (00:02:16):
A round that would look laughable in the face of what the rounds look like today.

Pablo Srugo (00:02:20):
Gotcha.

Simon Hørup Eskildsen (00:02:21):
So I grew up in Denmark. I moved to Shopify to work there as a software engineer as what I thought was going to be a gap year, back in 2013. Moved over to work on the infrastructure team at Shopify and Shopify was at the time, only had an office here in Ottawa where we both are today. Of course, now today they have many offices around the world.

Pablo Srugo (00:02:38):
Yeah, 2013 was pretty small. How many people? They're pre-IPO, they're what? Series C company or so?

Simon Hørup Eskildsen (00:02:43):
That's right. They were around a hundred and fifty people when I joined, maybe around 200 between when I interviewed and when I joined. Spent almost ten years there, building infrastructure on the infrastructure team. It was a very small team at the time and grew quite a bit as Shopify grew. We were doing a few hundred requests per second when I joined and we went into soft last sales in the millions of requests per second by the time I left. The majority of what you spend your time on if you're scaling infrastructure are the databases and the database layer. And that's where I spend almost all of my time, caching databases and everything. The database that brought me the most trouble, both in terms of the product that we could ship and in terms of the operational experience, was the search engine at Shopify. And I never thought that I was ever going to work on that again. But after Shopify, I encountered the problem again of, I'm working for a friend's company, an actual bootstrap company. I worked there for a few months just helping them with infrastructure challenges and I'm doing a short consulting stint. And they asked me to build a recommendation engine. And so I built a small recommendation engine, and used some vectors. Because I mean, vectors are great, right? They're a very good representation of what content is.

Pablo Srugo (00:03:52):
Yeah, maybe give the non-technical kind of explanation of where this comes into play.

Simon Hørup Eskildsen (00:03:55):
The way I think about a vector is that, if you take an LLM, like ChatGPT and others, and you sort of cut off their head. Then what you get is you get a bunch of numbers around, you know, maybe four thousand numbers and what these numbers are really just a coordinate in a coordinate system. You can think about this in two dimensions, where if you are Spotify, you plot all of the songs that you have into two dimensions and the ones that are similar are going to be in adjacent. And this means that you end up with clusters, right? You're going to have a rock cluster, you're going to have a pop cluster, whatever you zoom in, you're going to get all the subgenres. So you can train a model that is very good at plotting unstructured data, like text, songs, images, video, whatever. Some people call this multimodal and what it really just is, is training a model to put content that is similar adjacent in accordance system. The example I often use is that if you're Shopify, for example and you search on a store, you search for a red dress and they only have a burgundy skirt. Well, that's actually a very difficult search problem. It's devilishly PhD-level difficult to do in a generic way, with a classical model. ChatGPT can do this with ease, right? It can see that those things are very similar in the coordinate system. They'd be right next to each other and so that is what a vector is. A vector is a coordinate in a coordinate system. It turns out that we can't just plot things in two-dimensional space. There's too much information to try to compress, which is what a vector is and so we use these coordinates that are really thousands of dimensions or at least hundreds of dimensions. And the problem with these things is that they are very large, but the benefit is that they're really good at doing recommendations and doing search. And it means that we can have just search that is really good as almost this byproduct of training these LLMs. Not quite, but it's not a terrible way to think about it.

Pablo Srugo (00:05:38):
Because they're key functionalities to, I mean, in this case. In this use case, to just know what is alike, what is this similar to in some of these dimensions.

Simon Hørup Eskildsen (00:05:45):
Exactly, I mean, it's one of the things where the ChatGPT and these LLMs are best at. You ask it for definitions, you ask it for more words that are similar to this word, or you ask it for what emojis are suitable for this particular thing. They're so good at finding information that is similar to other information. That is how they're trained and so vectors are that, they're just a way to do that, that is really applicable to search. And so what we do is that you take text, you take images, you take whatever, and you turn it into one of these vectors. And we don't do that, we don't take the data and create the coordinate. We just store the coordinate system. So if you were Spotify, Spotify is not a customer, but if you were Spotify. Then you would take all those songs and put them into TurboPuffer. And then you would make searches, like, okay, Pablo, we're gonna make your Discover Weekly now or some recommendation. Let's look at everything that Pablo has listened to and then search for vectors or songs that are similar in space. That's what a vector is and TurboPuffer is the coordinate system. You can ask it questions and the innovation of TurboPuffer is that it is almost a hundred times cheaper than the incumbents at the time, to store that coordinate system.

Pablo Srugo (00:06:50):
And by the way, why did you leave Shopify in the first place?

Simon Hørup Eskildsen (00:06:52):
I left Shopify because I have been there a very long time. Working on infrastructure and I wanted to see infrastructure in other places. I thought that it was time. You spend ten years in one place and you want to see computers in a different place.

Pablo Srugo (00:07:06):
And you left for your friend's startup? Or you left and then kind of that happened?

Simon Hørup Eskildsen (00:07:10):
I left to get in the best shape of my life, at first over that summer and then I started working with my friends' companies. I called it angel engineering, where I went for a couple months to my friends' companies, invested mainly equity, and helped them with some infrastructure challenge. I did some of that before I did this particular one, but this was the one that was part of the founding journey of TurboPuffer. Where we mostly database scalability stuff and for this one, what I did was build this recommendation engine. This was a real bootstrap company that had spent $3,000 or so per month on their Postgres and I ran the back of the envelope math for this recommendation engine I built with the coordinates, right? You put these articles in a space and you recommend other articles.

Pablo Srugo (00:07:49):
What was the use case? What did they want recommendations for?

Simon Hørup Eskildsen (00:07:52):
Yeah, have you heard about this company called Readwise?

Pablo Srugo (00:07:55):
Readwise, yeah, yeah. That sounds familiar.

Simon Hørup Eskildsen (00:07:58):
So their first product was you take your Kindle highlights, you send an email every day, taking some of your Kindle highlights and showing them back to you, and helping you retain your reading better. But now they have a reader product, where you can save articles, you can save books, you can save PDFs and then read them on your phone in a nice standard web interface, right? And so you can imagine in a product like that, you might want recommendations. I think they still don't have recommendations, but this was the founding use case. So I built a very small recommendation engine and it worked okay. For something very simple, it actually works okay. What I learned though was, that I did the napkin math on putting this in production, right? They have hundreds of millions of articles and it would have cost about 30 grand a month. To put in the production on one of the incumbents at the time, and that was just way too much, right? They could not earn a return on that kind of cost. It just didn't make sense for the per user cost based on what they were charging. So we tabled it, it was going to work, but we tabled it because the cost wasn't there. I just couldn't stop thinking about that. It's like, why, the token costs will probably come down. I mean, they haven't really come down, but eventually, they'll come down. Who was going to do that for search? Because here was one use case in one company. There's got to be thousands, if not tens of thousands of these.

Pablo Srugo (00:09:06):
Was there something that told you that it should be cheaper? Much cheaper than what it was?

Simon Hørup Eskildsen (00:09:11):
The fact that they didn't ship a feature. Because the infrastructure just fundamentally wasn't at a price point, where they could earn a return on what the infrastructure provider was charging them. Not because the infrastructure provider was bad, just because that's how they implemented it. Just made me, you know, I have this GitHub repo called Napkin Math, and in Napkin Math, I have a list of numbers of what a computer can do. How many gigabytes per second of memory can you read? How many gigabytes per second can you read from a disk? How much can you read over a network? What's the latency from Sydney to New York? All these kinds of numbers. So the way that I approached the problem was, OK, well, is there a fundamental compromise that you could make here where you give something up and you get the cost in return? It turned out to me as I stared enough at the numbers and drew this enough time. That there might be a way now that you could build a database that you wouldn't have been able to build ten years ago. That would make this really cost efficient. There is this, have you heard of S3? Do you know what it is?

Pablo Srugo (00:10:07):
The S3 bucket, like with AWS stuff?

Simon Hørup Eskildsen (00:10:09):
Yeah.

Pablo Srugo (00:10:09):
Yeah.

Simon Hørup Eskildsen (00:10:10):
So for the readers who don't know what it is, S3 is this incredibly cheap way to store data. If you put data in memory, it costs maybe two to five dollars per gigabyte of data you put in memory, right? And if you put it in an S3 bucket, the data, it costs about two cents per gigabyte.

Pablo Srugo (00:10:26):
Wow, okay.

Simon Hørup Eskildsen (00:10:27):
A true two order of magnitude cheaper. But no one had really built a database that would be fast enough for recommendations and for these types. For storing the coordinate system on top of S3. The fundamental thing that you give up is to write into S3 takes hundreds of milliseconds. That's not acceptable if you're building a checkout system at Shopify, or you are browsing the Netflix catalog, or some other consumer use case. It is not an acceptable latency to write new data.

Pablo Srugo (00:10:57):
Because that comes up when? In that use case? Like you're checking out, now you have to wait two hundred milliseconds for the checkout to go through or whatever?

Simon Hørup Eskildsen (00:11:03):
When you do a checkout, you're doing much more than one write to the database. You're potentially doing hundreds, right? So you multiply two hundred milliseconds by a hundred, and you end up in tens of seconds. A normal database can do a write in hundreds of microseconds, right?

Pablo Srugo (00:11:14):
Gotcha.

Simon Hørup Eskildsen (00:11:15):
Three hours of magnitude faster than you can do it to S3. So, okay, you might give up three orders of magnitude in write latency, but actually you don't have to give anything else up. And then you have this true two orders of magnitude decrease in the base cost of the system. That's a great compromise if you're building search. Because when you're building search, you are okay with, you know, if you add a new title to the Netflix catalog, or you're adding new songs to Spotify, or even if you're adding a new product to Shopify. It's okay that it takes two hundred milliseconds to make it into the search engine. It's an acceptable latency.

Pablo Srugo (00:11:49):
It doesn't really matter, because the thing about search is when you search, you want it to be fast, but when you add something to that database search, no big deal.

Simon Hørup Eskildsen (00:11:55):
Exactly, so we could build that database. S3 and disks, and a bunch of other things, that are kind of boring and nerdy. Sort of meant that we couldn't have built this database ten years ago, but now we can build it with this particular architecture and then if you query it a lot, right? We just put it into memory, right? If the data is active and pay a little bit more for it. That's the fundamental architecture that I came up with in 2023, and then sort of locked myself in, and came out with the first version of the database over the summer of 2023.

Pablo Srugo (00:12:25):
How quick was this, by the way? From the time where you hit this, okay. This is not gonna be affordable for Readwise until you have the epiphany. Just walk into a timeline, the epiphany, and then you lock yourself up.

Simon Hørup Eskildsen (00:12:35):
Yeah, so I worked with Readwise on this in around September, October of 2022, right? So this is around when ChatGPT was coming out. The problem bothered me for the next six months, and I was working with some other companies during the time. And then finally, in May of 2023, a consulting agreement fell through. It's just like, it was not gonna work out. I was talking to a friend and I was explaining to him, it's like, I think you could build a search engine with these compromises. And God bless this guy, he's one of my best friends, he actually helped me design the website. Well, he designed the website. I mostly just provided really annoying feedback on the website and I think he would agree that he did not understand what I was going on about. Hopefully I'm able to articulate it better now than I was then and he just said, you should just do it.

Pablo Srugo (00:13:20):
He just saw your passion. I mean, he knew you well enough to be like, dude.

Simon Hørup Eskildsen (00:13:23):
Yeah, I was like, should I? This guy's kind of being annoying with this consulting agreement and I don't know if I want to do it, but I have this other idea, and it's percolating in my head. He's like, you should do it and I said, I think we could do this cool thing with a website where it feels ASCII and sort of retro. And I think there's something there, but not take it too far. Because then it's going to feel in the uncanny valley and we're sort of riffing on that. And he's like, you need a name, and I was like, well, how are we going to come up with a name? And he said, you should choose a name that has an emoji that doesn't have any other connotations. We're just like, you know, looking at our phones on a couch in the Airbnb in Copenhagen, and we find the pufferfish emoji. And we both agree that, okay, well, no one knows what this emoji means, or it doesn't have any other connotations. And then we're sort of throwing it around. I think our wives wake up around this time, and his wife says, TurboPuffer. And she said it in an Australian accent. Which is, by the way, that and the French accent of the superior accents to say the name in. I'm not going to try to.

Pablo Srugo (00:14:19):
 You're not going to try? Come on, man.

Simon Hørup Eskildsen (00:14:21):
I'm not going to try. I'm not going to try.

Pablo Srugo (00:14:22):
TurboPouffeur, something like that.

Simon Hørup Eskildsen (00:14:24):
Something like that and it just made us happy. That's really what it is. Today, the way that we explain it, right? Is that you put the data on S3 and it's slow, and cheap. And then when you query the data, it gets faster, and faster as we sort of puff it up into RAM, alright? And disk as an intermediate layer, but that is the origin story. So, September of 2022, October, I'm working on this recommender system at Readwise and various things to integrate. The first GPT models that were really good into that experience. Then I did another consulting agreement with another company called Replicate and then I went, and started building this in May of 2023, is when the great lock-in happened.

Pablo Srugo (00:15:01):
Did you have a sense of just how big the market was? Or was this just like, this needs to exist. I'm going to build it. We'll see kind of what comes of it. Do you know what I mean? How much did you size things out, in terms of the opportunity in front of you?

Simon Hørup Eskildsen (00:15:10):
I didn't do anything. I can articulate why now I did it, but at the time it was your personal neural nets gradients are trained on your experience and what I just saw was that there are these vectors. They are enormous, right? So what we didn't talk about with these coordinates is that because they're in thousands of dimensions. The coordinate in the coordinate system, this is very counterintuitive, but the coordinate in the coordinate system is larger than the original data. If you take a paragraph of text, the coordinate that represents it is actually larger than the paragraph of text and so it is just so much data. It's so large that the costs are so great, that it's very difficult for most companies to earn a return on and that was the fundamental first insight. So this is really big and it's just too expensive. And the second thing was that S3 buckets and disks, and a bunch of other things. There's some technological advancements that meant that we could build a database in a way we couldn't build before. The way that I articulate this now is a little bit more structured. If you want to build a generational database company, you need two and a half things. The first thing that you need, is that you need a new workload. Because if you want to make it as a really large billion dollar plus database company, you need a reason for more or less every company in the world to need a new database. Or at least use new products that use your database. That new workload is that we have AI that wants to be connected to enormous amounts of data. We are the latter part of that, right? We are the coordinate system, right? That AI searches in. When you train an AI model, you're trying to basically compress all of human knowledge into a few terabytes. That's impossible, you can't do that, at least not by any computer science or any science really known. It does not make sense that you can compress all of human knowledge into a few terabytes. What you can compress into a few terabytes is a way to reason about the world and a mental model of the world. But in order for you to use that, you have to have access to tools, and the tool that we are is search over all of the unstructured data potentially in the world, inside of every company in the world. And that's the new workload, connecting data to AI. That's the first thing you need to build a very large database company.

Pablo Srugo (00:17:26):
How much was this front and center at that time? That this would be the new workload for you?

Simon Hørup Eskildsen (00:17:30):
The new workload was completely overfit on Readwise, right? It was like.

Pablo Srugo (00:17:33):
Right, right. 

Simon Hørup Eskildsen (00:17:35):
Readwise has this new workload, maybe other companies do, right? It was completely overfit on that one customer. So I assume that, that latent demand is when there is demand in the market that is pent up and you can't access it. Because pricing or availability, or there's some force at play that means that you can't get what you want and what Readwise wanted was a search engine that was about one to two orders of magnitude cheaper. Because then it would have been a no-brainer to search it. So I felt, well, there's got to be a hundred other companies. This feels worth at least writing an article about, right? It's the output of the summer and I was in a good position where I was looking for a project, and the project found me. That was a new workload. Second thing you need to do to build a really large database company, is that you need a fundamentally new way to store the data. That's what we just talked about. Put it on S3, two orders of magnitude cheaper in RAM, and then the stuff that you actually need to put in RAM. You put into RAM when needed, but you only puff it up when you need that to actually serve the data. That's the new storage architecture. None of the existing databases have that storage architecture. Because otherwise there's no reason why the other big database companies like Snowflake and Databricks and MongoDB and Oracle would not just get good at it. Unless it fundamentally challenges assumptions that they built on top of and relied on for decades. The third thing or the two and a half thing that you need to build a large database company is a way to suck up a lot of data really quickly. You don't strictly need this, but if you're impatient, then you want this. Because otherwise you need to wait a long time for the compounding function to work on a smaller base. That's what you need and I could not have articulated it at the time, but it felt like that was in the air, right? The way that we think about innovation is that, I mean, it's more of a discovery than it is about doing anything genius and the discovery here was that there's a set of compromises we can make. And it's uniquely suitable for this new workload, slower writes, and no other real compromise.

Pablo Srugo (00:19:24):
The other framework for that, the innovation piece, the Mike Maples thing, right? About kind of living in the future and so this idea that you're kind of out there doing things, like you're not actively trying to start a company or trying to find a problem. You're just doing things as you were doing things and then you came across this search situation, and you just went out and solved it. And then AI happened to be this wave that has made the opportunity so much bigger. It's just crazy how things work out.

Simon Hørup Eskildsen (00:19:47):
That's right. So that summer, it was never a business. It was a project, and it was a project where I thought that I was maybe publish a really interesting article. And I actually did, and I wrote an article about the experiments that I'd done. Sort of like a month or two into it and I sent it to a friend. And he said, you should turn this into a real service. And that was enough encouragement for me, because he was one of the industry leaders in this space and practitioners. And so I just kept working at it, and there were some real problems to solve, surely. But it was not something I felt like I know a lot about databases and so on. But it was nothing that was uniquely really complicated, right?

Pablo Srugo (00:20:26):
And it was just you?

Simon Hørup Eskildsen (00:20:27):
It's just me and inside of the company, we make a lot of fun of what we call V1. There's almost none of V1 left now. Other than some pieces and we all make fun of it. And my joke is that, they make fun of it but it's the reason they have a job. 

Pablo Srugo (00:20:41):
Yeah.

Simon Hørup Eskildsen (00:20:41):
Now, this doesn't really resonate, because these people are so good that it would not be an issue for them to get another job. I was obsessed that summer, it's all I did and we would have guests, and I couldn't stop thinking about it. I was just in a notebook. My wife was very patient, but also a little bit annoyed, rightly so.

Pablo Srugo (00:20:57):
How all in, what are we talking about? What would a normal week be or day be for you in that, those two or three months where you're building?

Simon Hørup Eskildsen (00:21:04):
I was thinking about this from the second I woke up until the second I went to bed, right? And then if during the evening, when my wife and I would have dinner. I was running like different runs, right? To test different theories of how this would work and experiments and stuff like that. I think she might have a better representation of exactly what that summer was like from her point of view. But I remember it as being completely all consuming and I remember not being as present as I wanted to be when we had guests. And we were hanging out with people because I couldn't stop thinking about it. I was truly in captivated and I felt that if I didn't do it, someone else was going to do it. And every day the opportunity felt, larger and larger. I did three rewrites during that time. I tested every single way that I could think of to do it to make sure that what I did was the best. I changed platforms, I tried so many different things and finally, it was the 4th of October. Two years ago and change from when we were recording. I finally released it on X.

Pablo Srugo (00:21:53):
Did you have a following? Let's start there, what's the context of you on X. Are you big? Are you posting a lot? You got people following you, technical people.

Simon Hørup Eskildsen (00:21:59):
I just have an egg avatar and two hundred followers.

Pablo Srugo (00:22:02):
There you go.

Simon Hørup Eskildsen (00:22:04):
No, because of my articles on napkin math and when I was a child. I did a lot of talks at conferences about scaling databases and things like that. I had accumulated a small following on X, and so it got really good traction on X. People were encouraging and it was enough for me to feel that maybe I have something here.

Pablo Srugo (00:22:20):
Do you remember what, like what it would of done? A thousand, ten thousand views, a hundred thousand views? What are we? What kind of order magnitude of attention did you get?

Simon Hørup Eskildsen (00:22:27):
I can pull up the tweet right here, because I was just reposting it the other day. Post engagement, almost four hundred thousand views.

Pablo Srugo (00:22:35):
Okay, yeah. So it was pretty big.

Simon Hørup Eskildsen (00:22:36):
The website was really simple, great encouragement, and I hadn't shared with anyone that I was working on this. Because the problem is when you talk about what you're doing. Talking about it feels almost as good as actually doing the thing. So you've got to just do the thing and I launched it, and I got a really fun email. I got a fun email from a company in San Francisco. Small company in San Francisco, they were just six people and they more or less said that, hey, we're working with this peer of ours and the trade-offs that they're making, and the economics just don't make sense, right? They were spending six figures on this and the fundamental problem they had was that the per user cost was, let's say, a dollar per user. I don't know what it actually was, right? But something that was untenable and maybe they're charging the $20. Maybe it was $5 per user. It was growing at a trend where the per dollar cost was not something that they could earn a return on.

Pablo Srugo (00:23:27):
Very similar to your Readwise original kind of issue.

Simon Hørup Eskildsen (00:23:30):
Exactly, and Readwise wasn't even the first customer. They only became a customer actually a year later. Which is very funny, and I think that if I hadn't gotten so busy. I would have just gone inside of Readwise and then shipped the thing, right? On TurboPuffer, but we got really busy really quickly. So I got this email, hey, we're spending six figures, the economics don't work for us, we're very interested in what we're building and knowing that team now. I know that they would have sat around the dining table and said, why hasn't anyone just put all of this on S3? And when you query it, you put it into RAM, and it's as fast as anyone else. And you just paid a little penalty of at the very beginning when you start interacting. It's a little slow and then it gets fast, and then high the write latency. Exactly the compromise we've made, and for whatever reason, I had the conviction at the time to do two things. The first thing I did was that I texted who I thought was the best engineer that I worked with during my time at Shopify, Justin, and I asked Justin. Justin, do you want to come on? I can't pay you anything, but maybe you can work something out. This is what I'm working on and then I sent in a bullet point list of the things that they would work on. And Justin said, let's take a walk. And we took a walk, and Justin started working on it in the beginning. A little part time and three or four days in, they said, I want to be all in. And then Justin came on as co-founder. The other thing that happened around that time is that for whatever reason. I had the conviction with this small company in San Francisco that I'd never heard of, I'll reveal the name in a moment. That I should fly to San Francisco and meet these guys. And so I did, I flew to San Francisco.

Pablo Srugo (00:24:54):
Why was that?

Simon Hørup Eskildsen (00:24:55):
They were impossible to track down. They were so busy that the only call that I could get with them was that at one point, one of the co-founders emailed me at 05:20 a.m. on a Thursday and said, hey, can you meet now? I'm free, after missing two meetings because of outages.

Pablo Srugo (00:25:11):
05:20 Ottawa time, by the way? Or which time?

Simon Hørup Eskildsen (00:25:13):
Eastern, yeah. So for him, it would have been 02:00, 02:20 AM.

Pablo Srugo (00:25:17):
Right, right.

Simon Hørup Eskildsen (00:25:18):
And I happen to be up. And so I was like, yeah, we can jump on a call. And we hopped on a call, and explained all of it. And after that call, I felt, OK, we have this email exchange. I need to go meet them, because it's too hard to get them on a call. I just need to go see them in person. And so I flew to San Francisco, and I didn't tell them that I was in town for them. I said, I'm in San Francisco on Monday. Let me drop by the office, no problem. I showed up on a Monday afternoon, basically the day that I got there and when I showed up at the office. And this is how I remember the story. I need to actually confirm this with the team, how they remember but this is how I remember it. But you can't trust your memories on these things and the way I remember it is that I showed up, and they were having problems with their Postgres database. Maybe it was down, there was some issue with it, and they got it back up. And then I, doing my consulting, I spend a lot of time with Postgres, and so I just tried to teach them everything that I knew about running Postgres at scale. Installing these different things, just helping them as much as I could. That must have convinced them that maybe I knew a little bit about databases. Because then when I told them what TurboPuffer, where I was going to take it and all of that. They felt compelled enough that they started the migration.

Pablo Srugo (00:26:18):
Which is a massive deal to be clear. Just in terms of trust, it's not like trying out a normal product.

Simon Hørup Eskildsen (00:26:23):
And of course this company is Cursor, right?

Pablo Srugo (00:26:26):
We have tens of thousands of people who have followed the show. Are you one of those people? You want to be part of the group. You want to be a part of those tens of thousands of followers. So hit the follow button.

Simon Hørup Eskildsen (00:26:37):
Little company, four founders, they were six people then and I don't know how much revenue they were at, right? This is in, what is this? This is in October or November of 2023, and they needed two features. And, Justin and I worked very hard to get them those two features. They started onboarding, they had a few billion vectors. Which at the time was one of the largest workloads in the world and they just did it. Over the course of a week, they migrated everything that they had and their first bill was ninety-five smaller than their six-figure bill that they had before, right? So they went from a six-figure bill to a four-figure bill and of course, Cursor has grown a lot since. But it started a very special relationship and in the beginning, I was so honored that they called me once sometimes, and asked me to help them with infrastructure candidates. To explain the opportunity at Cursor. I was probably one of the few people looking at our dashboards that could see their growth, and I sold them as hard as I could to the few candidates that came through.

Pablo Srugo (00:27:33):
I'm sure they're very happy now.

Simon Hørup Eskildsen (00:27:35):
I don't know why they needed me for this, frankly, because they are so good at recruitment. That I always felt honored when they asked and happy to do it. And they even asked me for infrastructure advice, and how to lead teams, and things like that. And I think they're probably much better at me than that at this point. But they were humble and they asked for advice where they could, and it forged a very special relationship at the time. One that I think continues to this day. We were in Slack and these are not their words. But we truly felt like we were part of the Cursor team and we had our little function. And we just tried to make sure because my goal was. One of the things that almost brought me to tears at some point was just Sualeh, one of the co-founders. Just saying sort of, you know, this is one of the only things that we just don't worry about. We just don't, we have not had to worry about it as we scaled up and as someone who has been on call for a pager at Shopify that lost millions a minute if something goes down. And, it's an absolute honor and privilege when one of the fastest growing businesses of all time by revenue tells you that you are one of the pieces of infrastructure that they've had to worry about the least. So we leaned in heavily, our only customer to begin with, and we built everything to make sure that it worked for them. And they used every single line of code in the product. And we just worked very hard, Justin and I, to make sure that this was going to work.

Pablo Srugo (00:28:46):
Just the two of you kind of at that point, and how quickly did that Cursor take you to a million in ARR?

Simon Hørup Eskildsen (00:28:51):
Not just Cursor alone, right? We reached a million in ARR about a year after we launched, but we had more customers then, than just Cursor. We also had Notion and a bunch of other customers.

Pablo Srugo (00:29:01):
So we'll get into how you landed those others, but Just on Cursor. I'm curious, going back to that Readwise thing, because with Readwise and these other examples. It was at the point where without TurboPuffer like thing, they just couldn't launch the feature, right? Now, you made it way cheaper for them. If you hadn't come along, could they even have scaled to what they've scaled to without either TurboPuffer or something like TurboPuffer to make the numbers work?

Simon Hørup Eskildsen (00:29:22):
I think that if TurboPuffer hadn't come along, they would have built it themselves in-house.

Pablo Srugo (00:29:26):
But they would have needed to have that sort of decrease in cost to make everything else make sense.

Simon Hørup Eskildsen (00:29:31):
They would have built TurboPuff for themselves and I think they would have done a great job. But it would have meant that they would have had engineers that were solely dedicated on that. Really good engineers who could be working on making Cursor better. It was a great partnership, right? And that I think was very mutually beneficial. But now there are many companies that have launched TurboPuffer, right? Again, it was a discovery. It was not that it's like fundamentally the hardest thing to do. But of course, you need a lot of good engineering for a long period of time to make sure the product is really good. But Cursor could have built it for sure. They have one of the best engineering teams in the world.

Pablo Srugo (00:30:02):
I mean, to be fair. That goes for many products, like many products could, in theory, be built but most people want to focus on their own product and especially the infrastructure. You know, kind of use others. So you and Justin, you're working on Cursor, just Cursor for how long?

Simon Hørup Eskildsen (00:30:13):
You could sign up in December. So we had a bunch of other smaller companies. Believe it or not, but the second larger deal in the thousands of dollars per month was TELUS. So for those of you who don't know. Pablo knows, but TELUS is one of the largest, if not the largest telco in Canada and they are very much what you would consider an enterprise company. But someone inside of TELUS, this guy Justin. Just saw TurboPuffer and similar. He'd had all these problems with director search and search in general with these other providers. And he saw something in us. To this day, I give Justin so much credit because it's very rare that an enterprise gets that amount of leeway to bet on a startup.

Pablo Srugo (00:30:53):
At the database layer too, yeah. No less.

Simon Hørup Eskildsen (00:30:56):
Yeah, we spun up a Canadian region for them, within a few hours after them asking, and we're just like, look, we're going to work very hard for you. We know that you're putting yourself a little bit on the line here. Tell us what you're paying and I think we can do a lot better than that. We just had a frank conversation with him and they're very happy customers still.

Pablo Srugo (00:31:11):
Where do they power, by the way? What's the use case for them?

Simon Hørup Eskildsen (00:31:13):
They have a bunch of internal systems, but they have this platform that they work with their customers on integrating called Fuel iX. Where they use TurboPuffer to search, right? And then they have a pluggable model layer, and then they sell that to their customers. And I think they use it for a bunch of things internally. They call them internal co-pilots, and that they use for a bunch of different things.

Pablo Srugo (00:31:31):
So it's AI use cases but a lot of the internal, okay.

Simon Hørup Eskildsen (00:31:34):
Yeah, inside of TELUS. They were our second larger customer.

Pablo Srugo (00:31:38):
In December, you said? Two months after?

Simon Hørup Eskildsen (00:31:40):
No, this is in maybe February or March.

Pablo Srugo (00:31:42):
Okay, so maybe four or five months.

Simon Hørup Eskildsen (00:31:44):
And then there was a bunch of random small startups. There's this company called, this Chrome extension called Merlin. There was a company called Fixie, and they wrote an article. It was an ex-Shopify founder, now they're doing voice agents. They built this, you know, when you watch a sports roster where they trial all these databases against each other and that ended with TurboPuffer winning. And that article was really generous for us. It was a bunch of startups like that, like a dozen or so back then. I mean, Cursor was not that big. I didn't even know them back then, right in the beginning of 2024. They just launched in May of 2023, I believe it was, so they were not that big in October 2023.

Pablo Srugo (00:32:23):
How did TELUS? How did these other startups find you? Is it through X? Is it just word of mouth? Or are you doing anything actively to get customers?

Simon Hørup Eskildsen (00:32:31):
It was just X. That's just how they found it. We didn't have any other channel.

Pablo Srugo (00:32:35):
Did you keep posting though on X? You were doing that pretty consistently?

Simon Hørup Eskildsen (00:32:38):
For sure, yeah. I was like, ah, just improve performance by twenty percent. You know, things like that. Yeah, for sure. I was very active on X, Justin was active on X and the TurboPuffer account was active, right? I think one of the things early on that also caught people's attention is that the website looks very similar now to what it looked like back then. But it had a very particular brand and flair. And, me and Jørgen, who is the designer that helped me come up with the name and the initial website. We spent so many hours on that, right? Jørgen was basically the first outside person other than Justin and I on TurboPuffer. Just working on the design, and that design got a lot of attention back then. And now I think it's, I don't really know. We didn't have any inspiration that was super close to it, but we just spent an enormous amount of time on it and I think now I would probably look at it. And be like, why did we spend hundreds of hours on this?

Pablo Srugo (00:33:26):
That was going to be my question, why did you? You can go both ways on websites. There's people who think it's huge, you know, matters so much. Other people could say easily, who cares? The name and the whatever, like, if your product's great, your product's great. You know what I mean? You could take both sides of that debate and I'm sure find examples for both.

Simon Hørup Eskildsen (00:33:41):
Doing my time at Shopify, I have looked at if not hundreds of database websites, right? And again, what you care about with a database is just, what does it do? What are the tradeoffs? What are the guarantees? What are the limits? Who's using it? What does it cost? It's really all you care about and I just wanted all those questions answered on the homepage. And I wanted an aesthetic that said, we care about design and UX, and you're going to have a great time. And we've spent some time to make sure that everything is organized in a way that makes sense, but not so much that you're not sure if you're buying a database or a sneaker. So that's really what I wanted with the website and then we had this particular monospace type of aesthetic that we've iterated on in many, many iterations since then. But it just felt to me that it was so important to position as we care about your experience, we care about DevEx, we are hardcore database engineers, and we want to make it very clear for you to understand whether this is the right database for you. And if not, that's cool.

Pablo Srugo (00:34:40):
I mean you literally had, I don't know if this is how you start it, but you can toggle around depending on your workload. To see exactly how much it's going to cost you.

Simon Hørup Eskildsen (00:34:47):
That's right, yeah.

Pablo Srugo (00:34:49):
So, you went through X, now we're in 2024, right? Yeah this is February, when do you realize that Cursor is like, holy shit. These guys are growing at an insane, insane rate and they're going to be a huge customer for you guys.

Simon Hørup Eskildsen (00:35:02):
I think we were just always wondering, when are they going to stop growing? Compounding is a very weird thing. Where it's very slow until it's incredibly fast. It was not clear to us, we were so focused on Notion. Because at the time, right? They sort of, they started POCing with us in the spring of 2024, and we were so focused on them.

Pablo Srugo (00:35:22):
They also came inbound? Like same thing through X?

Simon Hørup Eskildsen (00:35:25):
No, outbound.

Pablo Srugo (00:35:26):
Okay, yeah. Walk me through that, what were you doing on the outbound side?

Simon Hørup Eskildsen (00:35:28):
So, I mean, maybe we can. The other things that were happening around then at the beginning was that we were, a bunch of VCs got interested. Generally, these were the VCs who were very technical. Who also saw, but maybe also couldn't quite articulate that there's something here and we ended up choosing this investor called Lockheed. And the reason that I loved Lockheed was for three reasons. The first reason was that I met him on the first trip that I went to San Francisco. I was actually introduced by the ReadWise co-founder. He said, just go talk to this guy and I went on a walk with him. And he told me on the walk, Simon, if you're serious about this company. You need to get this lawyer because he's the guy that always leaves me basically crawling out of the room, and it's just like, it's such an odd recommendation for a VC, right? Now I'm like, that's incredible. Because yeah, if you are serious about your company, you need one of the best lawyers in the world. It's completely underrated and this lawyer team that we work with at Wilson Sonsini. They take a small bit of equity. So they're completely aligned with you, common stock, and they just see more transactions than anyone else. And people underestimate how much this matters. But then I talked to one of the funds, and the fund's like, do you have a lawyer, right? Because it's a good sign whether a startup is serious and I said, oh, yeah, this guy. Rob Broderick and Damien Wise at Wilson Sonsini, and he said, oh, no, no, no, no, no, don't talk to those guys. Here's my guy, that's how I knew that this is a good lawyer. That's how you know.

Pablo Srugo (00:36:46):
And they've been helpful? I'm curious on this, where have they had the most value for you?

Simon Hørup Eskildsen (00:36:49):
I think the concept of having lawyers for different things, before being a founder was a very nebulous concept to me. But a corporate lawyer is essentially the person who cares about stock option grants, like your cap table. Anything that revolves basically exchanging equity for cash, right? Or for more equity or whatever, right? So these people become very important on partnerships, they become important for optimizing equity for employees, they are important for optimizing taxation for employees, they're very important for if you want to sell your company, then you want people who are your coach in your corner and you If you are raising money, then you of course need someone who sees a lot of that. If you are thinking about your corporate structure in, what should you have in the US versus Canada. You need really good corporate lawyers. We have corporate lawyers in Canada and in the US. But you want a corporate lawyer who sees a lot of activity and ideally a corporate lawyer who never works with VCs. But only ever works with founders and ideally your corporate lawyer is available on WhatsApp within five minutes at all times. For any questions that you might have and that's what these lawyers are. And that their incentive aligned with you on anything that might happen, whether you're IPOing, whether you're selling your company, or whether you're doing investment. Because they have the same stock that's looted exactly the same as you and all of the employees. I talked to other lawyers at the beginning, and when they told me they're hourly, you can just see their daddy issues come out through their eyes. That is not what you want.

Pablo Srugo (00:38:10):
So this VC makes that recommendation. When do you go back to him and decide, do you want to raise?

Simon Hørup Eskildsen (00:38:14):
Yeah, so the other thing he did was, that he was just helpful immediately, right? I got to taste before I bought, and he was just incredibly well, and responsive. And then there's another thing, which was that he didn't know anything about databases. And he was honest on it, and he just said, yeah. I said, have you ever invested in a database company? No, I've never invested in a database company nd he just said it with such conviction that I was like, oh, maybe that doesn't matter. Maybe it's actually a good thing, because Justin and I should know about databases. The people that we hire should know about databases. It doesn't really matter if the investor knows about databases other than they might find us earlier. and he was just incredibly well-connected. So yeah, those were the reasons that went into choosing him.

Pablo Srugo (00:38:48):
When you went and decided to raise some small pre-seed. That you won't say exactly how much. Why did you need that money for, I assume you wanted to hire. How many people did you want to hire with that.

Simon Hørup Eskildsen (00:38:56):
Yeah, so in the beginning, everything just ran on Justin and I's credit cards. So we were trying as hard as we could to not lose money. I mean, we didn't know how to raise money. We didn't know how all this stuff worked. So we're just trying to not lose money. So we were optimizing the cursor workload like crazy to just not lose money and then when I was in high school, I went to this competition called IOI. Have you ever heard of this?

Pablo Srugo (00:39:16):
No, I haven't.

Simon Hørup Eskildsen (00:39:17):
So IOI is an international competition where ninety to a hundred companies send their four students. It's basically like Computer Science Olympics in high school. Yeah, the problem is that no one's heard about it, but it contributes more to GDP than the real Olympics, and let me give you an example. The founder of Cognition is a gold medalist. The founder of this company called MobileApps is a gold medalist. A lot of Silicon Valley and the founders of this generation are people who did really well in these competitions in high school. I did not win a medal, but Bojan did and Bojan, and I met in 2012 in Italy. Where we both went to the competition. He was on the North Macedonian team, I was on the Danish team, and we got along. The Macedonian team called him God, because he was very good, very good at the competition and he was a silver medalist. And we got reintroduced by a friend, and he was the first employee at TurboPuffer. But we didn't have the money to pay him, and we'd already paid enough money out of our own credit cards, Justin and I. We needed to have someone on board and that was the reason why we raised.

Pablo Srugo (00:40:11):
So the other thing I want to talk about, the outbound piece. So you said you actually, you got Notion through outbound. What outbound motions did you start running?

Simon Hørup Eskildsen (00:40:17):
We just knew that Notion was such a good fit for our architecture and we got introduced, I forget who exactly introduced us the first time. But we got reintroduced many times, most people just ignored us to begin with and then eventually someone took a call, and then nothing happened for like five months. So it's hard to attribute because Lockheed is also an investor in Notion. So, you know, I don't know what exactly he worked, but at some point they just reached out and said, hey, geoeconomics are holding us back a little bit on product. And so we want to try some other suggestions. Later I learned, I was just at dinner last week with one of the people at Notion that worked with TurboPuffer, and apparently they said that him, and a guy on his team that we now work closely with. Had sketched out what they thought that the right architecture for Notion was for search and they had basically come up with TurboPuffer, and then sort of matched that. And so I don't know exactly how we ended up on this call but we had a call and there's, six people in the room and it was just me on the call on our side. And they just braided us with questions about can you do this, and can you do that, and so on. Now I understand that they had already had the product vision that they're executing on today. Notion AI, you know, it's the Cursor for pros and they needed the right search engine to power all of that. With the right economics that they could earn a return on and so they asked for a region in Oregon, and we spun up a region in Oregon within a day, and they just started testing. And Justin just pulled tricks doing this POC that, I mean, Justin and I worked together for almost eight years at Shopify. And Justin was always one of the best engineers I'd ever worked with. What I saw Justin pull to make sure that Notion was going to work was beyond anything I'd ever seen before. I remember distinctly, Morgan, our second employee, had joined at the time and we were doing a little team offsite in Quebec, Canada. And we came back from dinner, and Notion had finally ingested their first workload. And it was really slow, it was like five hundred milliseconds for a query and we wanted less than a hundred. Justin found three hundred milliseconds or something like that in the span of three hours that night. Just kept banging out PRs from looking at the workload, and there was another time where Notion asked, can we do this, Corey? And Justin just told them in Slack, yes, we can. We just need to expose it in the API and then worked like I've never seen before for the next 24 hours to get it in their hands. This is how Justin worked on this deal. When people talk about forcing something or willing something into existence, this is one of the first things that I think of and it was weeks, and weeks of that POCing different angles, right? And then I was working on the pricing because we didn't even know how to charge for this at the time. Bojan was working on a completely rewrite of TurboPuffer on the side and Morgan was working on the full-text search. And we were just, we were so focused. And finally towards the summer, we got the feeling that maybe they were going to commit. We'd felt a little like it was slow and they had some commits with the other vendor that they were riding out. And on the 25th of July, it was getting really close. My wife was seven or eight days overdue with our first child. 

Pablo Srugo (00:43:06):
Wow.

Simon Hørup Eskildsen (00:43:07):
I was working so deeply on the billing system, because otherwise we were going to lose money on Notion. Because we needed to put this new billing in place. Finally, they signed on the 25th of July in 2024. I invited Justin and our virtual CFO, Mike, who's now on full time. We were the only ones in Ottawa, and then we had Morgan, and Boyan in on a video call. And we're all just awkwardly on a call. My wife was there as well, very pregnant and Justin says to my wife, wouldn't it be funny if your daughter was born today? And this is the biggest jinx of all time. Because this was, you know, late afternoon. They all leave, Justin and I hang out for an hour. I cried a little bit that day. It was just like, we'd worked so hard on this and Justin in particular. And Justin left, and then my wife came down. And said, I think something is happening.

Pablo Srugo (00:43:54):
No way.

Simon Hørup Eskildsen (00:43:55):
And three or four hours later, our daughter was born.

Pablo Srugo (00:43:58):
That's amazing. First daughter?

Simon Hørup Eskildsen (00:44:00):
First daughter. That was a wild, wild day.

Pablo Srugo (00:44:03):
It would be hard to craft a better story than that and did you know at the outset. When you're sizing these deals, like Notion. Obviously it's going to be a massive customer, but do you know how much revenue that's going to generate exactly? Or is it an estimation? Because you're not really selling like per seed or whatever, obviously. So, how much do you know about how big it'll actually be?

Simon Hørup Eskildsen (00:44:22):
Yeah, I mean, at the time I was spending probably a third of my time doing engineering and a third of my time on a pricing. You know, an updated pricing that was going to work for them and making sure that we could stay afloat. And then the other third of the time selling. What we did right, is you sent them a form saying this is the approximate size of your workload and then we generate a quote for them. Notion came back and said, are you going to lose money on this? Now I know that Notion was legitimately concerned that we were going to go out of business. Because it was so much more cost effective than what they were doing. So yeah, we knew exactly what we were going to earn on it, right? And we knew like the rough margin profile. You never really know until the rubber hits the road. Yeah, we knew exactly and at this time, that workload was bigger than Cursor.

Pablo Srugo (00:45:03):
This is where I'm curious to dive into this, because at this point. So you've got TELUS, you've got Cursor, which you don't know how big it is, but it is, you know, it's a growing customer. We've got a bunch of little customers. Now you sign Notion. I would argue ninety-nine percent of founders in that situation, especially these days. They're going around, they're raising a $30 million series A. I mean, you've got all the, like everything you need to have to go out and do that. You don't do that and you haven't done that. Why not?

Simon Hørup Eskildsen (00:45:26):
There's six reasons to fundraise. Reason number one, was the reason that we fundraised in January of 2024. Exactly how much money that we needed to prove to ourselves, that we could find product market fit. If Justin and I could not find product market fit by the end of 2024, we were just going to close up shop. Justin and I were very clear about this. We even told the investors who were invited for that round in 2024. That we were going to close up shop by the end of 2024, if we'd not found PMF. That was terrifying to everyone but Lockheed. We raised enough money that we knew that we could fund R&D for 2024. The second reason to raise is to fund growth. It's to fund marketing and other ways that you think that you could grow the business, once you have a proven way to turn dollars into more dollars and mindshare. The third reason to raise, and this is probably the most popular reason. And it's kind of what you're getting at here, it's for ego. It's also known as raising because you can or because there is momentum, or because you got preempted. These are not first principle reasons to raise capital, which has real downsides, right? It dilutes employees, it ups the strike price, it has all kinds of ramifications that you now have to live with. That might put your business at risk. The fourth reason to raise is to fund liquidity for the employees, right? That have believed and that have been here for a long time. The fifth reason to raise is for trust and or publicity. So you raise basically to build credibility for your business. That would not have been an illegitimate reason for a database company to raise, and the sixth reason to raise is for strategic partnerships. This can either be, you know, a VC that you really think is going to make a dramatic difference for you. Either because they've proven it or they have connections or whatever that you need. But it could also be institutional investors, right? Where you know that if you get this customer, they get our new cap table, it's incredibly important for your business, right? If you're building software for movie studios, you might do that for Disney, right? Or something like that. Those are the six reasons to raise and if you are raising for any other reason than those six reasons. You are raising at reason number three, which is to fund ego.

Pablo Srugo (00:47:26):
There's a lot of reasons there that I could argue, yeah, why not? You know, you get more credibility, you'll get more go-to-market, whatever. All those reasons could in theory apply to you.

Simon Hørup Eskildsen (00:47:34):
I mean, I could go through every single one of them and we can see why they didn't apply at the time.

Pablo Srugo (00:47:38):
Or even today. I'm curious on, maybe not every single one but the ones that would be most obvious out of what you said, would probably, credibility. Which would in theory help you, hire and things like that even faster than you already are, and go-to-market. I mean, those would be the two that jump out at me as like, yeah, you could raise for that. You know, small dilution, why not?

Simon Hørup Eskildsen (00:47:54):
On the growth piece, we don't have a growth motion. Where we can put dollars in and get more dollars, and mine share out the other way. That may be true over time, right? That's the team, that's the team I'm working on building right now and then we might raise for that reason alone.

Pablo Srugo (00:48:10):
Because it's mainly inbound still that your growth is coming from?

Simon Hørup Eskildsen (00:48:13):
Yeah, mainly inbound is the majority of our growth and then on the trust piece. We have found that that has not been a limiting factor. Now we got very lucky, right? We've worked so closely with Cursor and they grew from being maybe not a particularly known logo to an amazing brand to be associated with.

Pablo Srugo (00:48:31):
Huge.

Simon Hørup Eskildsen (00:48:31):
In a very short order. So we got incredibly lucky, but there's lots of downsides to raise. I don't have a neat list for you. When we hit one of those triggers, that's when we would consider racing and we would look at the people that we've worked with. That we've liked working with, and when the time comes.

Pablo Srugo (00:48:46):
How many people are you in the team?

Simon Hørup Eskildsen (00:48:48):
The team now is, as of October 9th. We are seventeen people.

Pablo Srugo (00:48:54):
Seventeen people and so I assume. Obviously you're profitable.

Simon Hørup Eskildsen (00:48:57):
If you want to build a database company, it is a long-standing endeavor and so we are profitable for that reason. Because we want to build an enduring, large, independent business.

Pablo Srugo (00:49:07):
Maybe my last question on fundraising, like you don't need twenty or thirty more people on the product and engineering side. And then be unprofitable, but not have to worry about longevity, for example. That's just not a need for you.

Simon Hørup Eskildsen (00:49:18):
If you find me thirty database engineers of the caliber of the ones that I already have. Then yeah, then we need to raise. I'm constrained in finding those people and getting them to join TurboPuffer more so than I am on capital. And by the way, these engineers want equity. That's what they're most interested in.

Pablo Srugo (00:49:36):
You purposely, I mean, you started off the call. I think it was before we started recording, but you're like, Ottawa was a great place to hide, right? You're kind of purposefully somewhat stealth. You're buying into the stealth piece and even on revenue sharing. You don't want to share revenue. What's the strategy behind that? What's the thinking behind that?

Simon Hørup Eskildsen (00:49:50):
We want to build the best database. How does disclosing various things, how do these things help me be a big database company? If something is difficult to price and it has externalities that are difficult for me to price. I just don't do it, alright. What is very clear is building a world-class database team and working on the database. And connecting our databases, and many companies as possible that need it. That's very clear ROI and that's why I spent my time doing that. Of course, we need everyone to know what TurboPuffer is and that time is coming.

Pablo Srugo (00:50:23):
Got you, cool. Well, listen, let me stop it there. Let me ask the three questions that we always end on. The first one is, when did you personally feel like you'd found true product market fit?

Simon Hørup Eskildsen (00:50:33):
It was that day that Notion signed because Cursor was still not that big. They were an incredible customer and we loved working with them. But when Notion signed, that's when I realized that this could be a really big business.

Pablo Srugo (00:50:46):
Second question is, was there a point? I mean things have gone really fast. So I feel like the answer is no, but was there ever a point where you thought things just wouldn't actually work out?

Simon Hørup Eskildsen (00:50:54):
About three months after we had gone to market. Our biggest peer basically launched TurboPuffer, and that's when, Justin and I had to look each other in the eye in January of 2024. And decide whether we were going to go up against this or, if we're just going to go and do something else, right? And we spent a lot of time debating that, and ultimately decided that we're going to do our darn hardest here. Because we're excited and we have a great set of customers. But if we don't find it by the end of the year, we'll close up. We want to build a big database business and if we can't do that, then there's no point.

Pablo Srugo (00:51:29):
By the way, how do you go up against that? Is that a product thing, like your database is just better or that's what you're trying to do? Just be better than them, be cheaper than them? Is there big ways to differentiate?

Simon Hørup Eskildsen (00:51:38):
We thought that it was going to be incredibly difficult, right? When an engineer sees something. I think a good engineer will always assume that it's the best version of what it is and we knew what we were building. And we knew how to get to the best version of it. And we assume that that's also what they had, but for some reason, customers kept coming inbound, right? Even though we were a small company. So, why that happened, I don't know, right? Maybe it wasn't as suited for some of the workloads that they had optimized before in R&D. Maybe they rushed it, I don't know, right? But I know that customers were testing us against it, and we were performing better. And that's why they chose us.

Pablo Srugo (00:52:13):
And then last question, what would be your number one piece of advice for other early stage founders?

Simon Hørup Eskildsen (00:52:19):
You are going to encounter a lot of very articulate advice from VCs and other advisors. But if you truly have the founder company fit or whatever founder market fit. You will really have to trust your intuition. That is a lesson that I've had to retell myself many, many times. Because it's very easy to be persuaded by someone who's very articulate and spent a lot of time in the market. You've got to just lean into the things that make your business and what you think is right weird, right? And that's what makes your business unique. Otherwise, it becomes a cookie cutter thing. Comes out of Silicon Valley, exactly as the VCs think that the playbook is, but every playbook that's worked has always been a little weird.

Pablo Srugo (00:53:00):
Simon, thanks so much for jumping on the show, dude. It's been awesome.

Simon Hørup Eskildsen (00:53:02):
Thank you, Pablo.

Pablo Srugo (00:53:03):
Wow, what an episode. You're probably in awe. You're in absolute shock. You're like, that helped me so much. So guess what? Now it's your turn to help someone else. Share the episode in the WhatsApp group you have with founders. Share it on that Slack channel. Send it to your founder friends and help them out. Trust me, they will love you for it.