How Supabase became the essential infrastructure for the AI era | Paul Copplestone (Co-founder, CEO)

Speaker A: We thought we were getting ddosed at the time actually, because we just saw this customer launching lots and lots of databases.

Speaker B: For today's episode, I'm sitting down with Paul Copplestone, co founder and CEO of Supabase, the open source backend platform that millions of developers now build on. The company started as a side project and now it's the backend for a huge slice of the Internet.

Speaker A: It was obvious to me how hard, huh, it was for developers to use databases. If the problem exists, then the opportunity exists.

Speaker B: But it wasn't always like this. Before Supabase, Paul built other startups that never took off in the same way.

Speaker A: There's something like painful about the chewing glass of trying to find product market fit. And you're trying everything and sometimes you just don't know what else to do.

Speaker B: When AI app builders like Bolt and Lovable launched, every new app needed a backend, um, and many chose Supabase.

Speaker A: These are the tools that are using more the CLI MCP type workload now happening off a base of 7,8 million developers.

Speaker B: In our conversation, Paul reverse engineers why Supabase worked. He shares why he refuses to lock in customers and how he's building towards self driving databases run by agents.

Speaker A: We want to build a generational database company.

Speaker B: He also gets into the chaos of hypergrowth and how he tackled the success problems that come with scaling too fast without losing himself in the process.

Speaker A: I want to look back at the end of my life and think, oh, not only did I build a big fucking company, but I also did it my way.

Speaker B: Let's dive in. You worked on multiple companies before you started Supabase that were seemingly less successful than this company, depending on sort of how you measure it. What are your reflections on like the value of a good idea or a few of like the foundational things that clicked into place with this company that didn't click into place with other companies?

Speaker A: Well, I think a successful startup takes like a thousand things to go, right? You know, and a lot of luck. The first ones were probably never destined to be as big. The ambition behind them was not as large. So, you know, they could have been successful in a local, uh, maxima.

Speaker B: Why is that?

Speaker A: Well, they're geographically constrained. For starters. The first one was a marketplace in Southeast Asia. The reason why that first one didn't go well was it didn't have pure product market fit. We're modeling against one here in the U.S. actually called thumbtack, which is, of course markets are all different the way things operate. There's a Different mentality to how you do things in the US versus say even m. Malaysia or Thailand.

Speaker B: When you were working on it in the early days, did you have a less ambitious mindset versus where you started? All of that was. You're just saying that it turned out to be less ambitious, not the intention.

Speaker A: Yeah, I mean the mindset's still the same. I mean the ambitiousness. Could we build that to be a hundred billion dollar company? No. So I think my, my ability to assess a um, market dynamic is much more honed now. In fact I think I even worked, I would say harder on, on that when I was building 90 hour weeks or something like that to, to make it work. So we're definitely ambitious and I learned a lot from that one. I had a co founder who was extremely ambitious, great salesperson, extremely good at fundraising and all of these things were assets that I picked up from him.

Speaker B: What about sort of the second experience?

Speaker A: Yeah, it's funny because the journey kind of trickles on to Supabase. My country manager for my first startup said I'm building this company and it's going to be. He explained it and it's kind of like an office management tool but it also owning the services. So very similar to the first one but fixing many of the or ah, de risking a lot of the things that were in, in the first one. And he had some moats like some permission from the government to do certain things. So that was good. But I said to him look, I'm a developer, I'm going to launch a dev tools company.

Speaker B: That's what you were thinking about doing at the time?

Speaker A: Yep. Yeah. He said to me well just give me a couple of years. Come like brainstorm, like build it and like build with us on the side or like in inside. And so that's actually where I started building. I took a lot of those learnings from all those companies that I was launching and then I kind of honed the tech stack and I built the second company is called Nimbus. I built Nimbus with the same tech stack and that tech stack now is what is Supabase.

Speaker B: Talk more about how that actually unfolded.

Speaker A: I was building a uh, chat application as I said, many of them actually in Southeast Asia operate via Messaging. And so essentially what I was building was a platform, but it felt more like a chat app. We were using Postgres for most of our database workload but then for the chat side I was using Firebase because it's got this nice real time functionality. It's very cool. Actually, but as we started scaling up I had some, some scaling limits on that particular piece. And then I thought, ah, uh, all right, I have to figure out how to fix this. And then I was looking at our tech stack and Postgres and I realized I could build this real time feature on top of postgres itself. I needed to use this framework language called Elixir Framework of Phoenix and built it and I open sourced it and it worked very well for our use case and it started getting some traction on hack and use just the open source part of it. And so I thought, okay, timing seems good. There's interest, developer interest. I know what I want to build. I want to build a database startup. I knew I wanted to do it on postgres and so when all of these things just lined up, I reached out to my now co founder who I had met at Entrepreneur first and I lived with him and I said, this is what I'm going to build. I thought at the time, again, to de risk things, I thought I'm going to build a, uh, the most Y Combinator friendly team and apply for YC and that will help from a devtool point of view. I think that's the pitch that actually convinced him he really wanted to go to yc. And so we started and we were fortunate to get into YC very early on.

Speaker B: When you sort of came across this opportunity and you were starting what is now Supabase, was it very obvious to you and was it high conviction or was it like, well, this seems interesting. I could kind of see it going like, what was the feeling in your own psychology at the time?

Speaker A: It was obvious to me how hard it was for developers to use databases. And I just knew if the problem exists then the opportunity exists. What I couldn't have picked is how successful postgres has been. We definitely rode that wave and hopefully we contributed a little bit to that wave as well. So in that way we've had a lot of tailwinds and we've been pretty deliberate to try to capture as many of these tailwinds as possible. So each time it feels like the opportunity's getting bigger and bigger. I felt like there was a definitely a, uh, big business in it, but probably not, or definitely at the time not at the scale that I know we can reach now.

Speaker B: You were talking a little bit about this, but how were you different as a founder when you started Supabase versus when you were working on your first company?

Speaker A: Well, first of all, when I started on my first startup, I don't know how familiar you are with the Kiwi mindset, the New Zealand mindset. I'm from New Zealand. We've got this thing called tall Poppy where you don't, you don't ever want to be the tallest poppy because then you, you get cut down. So you always make yourself smaller or. I don't know. It's a hard culture to explain. I quickly unlearned that in my first startup. I remember my co founder, as I said, he was very good at fundraising. I, I learned a lot from him. Um, how to fundraise and it's a little bit like sales, it's slightly different, but I had to learn that. So actually that's one thing. I treat the process of fundraising and building a business as two distinct things. Now, hopefully both of them, you do phenomenally, but you could do one or the other separately quite well. I learned really the dynamics of fundraising investors, why it's important when to raise. I also learned the value of not blitzscaling too early. So find product market fit before you blitzscale. I probably learned that lesson a little bit too hard at Supabase. We're very small and we've got to ramp up really fast for our scale. Yeah, I held that lesson too long, I think at Supabase, where, you know, we've got a lot of growth across, uh, everywhere and a lot of people are stretched. But it was good to see that internally at my first startup. Um, like how we hired, maybe too fast on too many areas that didn't matter. What was good on that one? My co founder was very diligent about keeping the bar extremely high. That one has always stuck. I think that one's universal if you can keep the best people. It was at YC yesterday and so on was saying, should I take someone who's high agency or should I take someone who's high performance? And it's very clear to me it's both like, you just don't compromise on any of those. So we at Supabase are a, uh, fully distributed team. We have no offices, so we're in three countries. In my first startup and we had an HQ in Malaysia and whenever I'd visit Singapore or Thailand, they'd always feel like decisions were made away from them because the gravity of the co founders is too high. Of course, everyone went fully distributed during COVID and then there was a big push to go back in or do hybrid is very clear to me. No, you don't half ass it. You just go all in if you're going to do remote, we went completely async and now actually I think it's, uh, a superpower for us.

Speaker B: What about if you take a crack at reverse engineering? Why Supabase was an outstanding idea that maybe you didn't even fully grok at the time, but now you have the benefit of hindsight and so like dissecting it and saying, okay, here's actually why it turned out to be so good.

Speaker A: How would you articulate it with the benefit of hindsight? Lots of tailwinds. That's always good. Hard problem to solve is also good. We have competition, but it's not like a competitor, uh, can spin up. So for example, now if I was building in the AI area, there's a lot of things that are getting launched fast. That means a competitor can get launched fast. Where we are is not in the build space, we're in the operate space. We operate the databases. So it's not just enough to launch something. You have to prove that you can operate it over many years and do it at scale. So there's this kind of moat that was important. We also leaned very hard into our community and the PNG motion. So that was good. Not trying to split our focus between let's go upmarket really fast, We've just kept our finger on the pulse of the community and the, uh, PLG motion, even though we get a lot of pressure all the time to move really fast across and win all types of workloads. And this was important because as well, postgres is so versatile. It can serve anything that, uh, enterprises wanted. You can use it for this thing, that thing, whatever. And so we're often trying to find out exactly what that ICP should be and only build kind of increments on top. So it's like a onion getting larger rather than kind of splitting our focus all around. So from this point, I think it was beneficial that we just had a lot of market drag, a lot of market pull anyway. And you know, in my earlier startups, you know, when you don't have product market fit, you lose focus because nothing is clearly winning. So you're jumping around a lot.

Speaker B: What's your definition of product market fit?

Speaker A: I don't really have a definition, but you kind of just know it. Like when, when things are growing a lot faster and when you're doing nothing and it continues to accelerate, that's kind of how it feels.

Speaker B: What was the very first moment that you sort of felt that real pull? What was the product maturity at that point? Like, what's the story if there was a day or a number of days that it felt like the ball started

Speaker A: rolling down the hill, I can kind of peg a few key dates. At the start of like 2020, we got into YC and we did this accidental launch. Someone put us on Hacker News. And usually you do a launch Hacker News. Someone, um, put us on Hacker News. And it was the day after I changed the tagline, I changed the tagline to Open Source Firebase Alternative and someone put it on Hack News that next day. And immediately it went like to the top of Hack News. It was very upvoted, lots of comments. And that was kind of the first lesson in that product market. Fit often is just like a product positioning fit. Sometimes you can just change some things and that's all that matters. And there are some people in the world that want whatever you're building, even if it's a niche product. You just kind of need to find them and, and tell them in the right way. So that was the first thing, a, uh, good lesson as well, just on how to position things for developers. From there, a lot of people in those threads said, uh, oh, we really need auth. This is a product that Firebase have because we're now putting the Firebase positioning out there. They actually wanted these other things. And of course I only really wanted to build the database offering, but AUTH made sense because I thought we could do a better product for the market by putting your AUTH users in your postgres database. Actually something that I never really understood from other AUTH providers, keeping your users outside your database. So we did it and we managed to launch that before the Y Combinator demo day. And again, like, we just saw the slope of the chart change and we thought, uh, all right, like these launches are, uh, clearly things that work. So off the back of that we said, all right, demo day's gone. In three months time, we'll just move from alpha to beta and we'll say all the things we've shipped on this one day, just keep launching. Yeah. And we just, we ship, ship, shipped, and then on that day we just rolled everything up into like a single page and put it on Hack News. And it, uh, went up again and we thought, oh, that's great. Well, we launched and why don't we just turn this into, instead of one launch, can we do a launch every day for a week? And then that was our first launch week, maybe I think four months later. Again, we just kept seeing these 20% bumps each time we would do these product launches. So it felt like sometimes inside those launches there were some things that fired really well, some things that didn't. You know, you can tell those ones that have product market fit just have direct demand.

Speaker B: Did the early roadmap come from people just saying, I need this and I need that, or did it come from more of a, uh, technical taste perspective? Like you had an opinion on how this thing should work and what we should build and so you just kind of manifested it in the world?

Speaker A: Bit of both, Yep. It was a, uh, hybrid. So we knew as well, again, because of our positioning, all the things that Firebase had, we didn't want to do all of them because we wanted to keep the database side. And I just thought of some ways to do it or as well. The team had some ideas that they wanted to build and they seemed to fit. And we largely think in primitives. We try to offer just pure primitives rather than products. And the primitives can be mixed and matched to allowing developers to do many, many things. I think the only one that was really, really like, demanded from the community was functions. We went through our edge functions. We went through like three launch weeks and we. People kept saying, oh, um, I hope they launch edge functions this launch week. And we were thinking, no, we, we don't want to because we're a database and we're telling them, use next JS or use, huh, whatever you're using. In the end, the demand was so, so high that we had to launch it. So, yeah, and this turned out to be a great product.

Speaker B: When you think about the first year, building the first product, starting to launch, what felt at the time very hard and what felt somewhat easy, I mean,

Speaker A: it was a grind. Slots of schlent. It didn't really feel that hard, if I'm, um, kind of honest. Once we felt like we had product market fit, I mean, it's all problems of scale, right? It's really just about navigating community and feature requests and building as fast as you can. And these things are largely exciting. And we had a lot of people joining the team. I remember this is how I know it wasn't necessarily hard. A lot of those ex founders were coming to us and they were like, burned out. I remember one in particular. He was burnt out from doing his own company for five years and we said, ah, uh, you know, just come help us. We've got so much work to do. Just spend a bit of time if you want, take a break from your own company. And he came in and instantly he was reinvigorated because he no longer had to deal with product market fit. It was just solving these cool technical problems for our customers. And he joined Supabase time and time again. I saw this from founders where they were burnt out from their own thing,

Speaker B: they were burned out from it. Just not working, just not working on it.

Speaker A: There's something like painful about the chewing glass of trying to find product market fit. And you're trying everything and sometimes you just don't know what else to do. Maybe because there is no way to get your vision into the hands of the right people. But we didn't have that. It was just problems of shifting as fast as we could.

Speaker B: What is your reflection now on the interplay between skill and luck, specifically and originally getting into product market fit?

Speaker A: Uh, well, it depends on the time of the market. The things that I'm uniquely served to solve might not be perfect for the timing. What happens when you get product market fit is usually or even the funding. Like for example, if I just went out and raised a lot of money, then the temptation is, okay, well let's hire lots of people. Ten people don't help you solve product market fit. Right? You have to iterate, you have to do it small. So we're launching a product at the moment and there's just no engineers on it. It's just a product person engineering. It's. And people say, oh, should we staff this up? And I say, well, absolutely not. They don't have the idea baked yet. And so it needs to be really, uh, a fast and tight feedback loop. What we did well, and what I would do, I think if I was to start again, is, yes, I'd raise the funds. That's important. But I'd still operate as if I only have a hundred thousand in the bank account, you know, where you just got to iterate really fast with a small group of people. Try find that thing. And then you've got to be really honest about whether you're actually got fit or not. As we've said, it means many things. So, uh, whether people will use something, whether they'll pay for something, whether they'll upgrade on that thing, whether they'll want to take it into an enterprise. All of these are, uh, different stages of fit that you need to de risk.

Speaker B: What else did you learn, if anything, about the relationship between you as a founder and what you should actually work on? And this may be sort of too reductive, but it sounds like the first company was just not as perfectly fit to you as Supabase. Do you have any Reflections on that.

Speaker A: I think that's okay because as the cto, me being a techie, of course I want to work on tech things, but there are so many opportunities outside of the tech bubble that need to be techified. Well, maybe we're seeing that now with AI and that can leak out into these domains, but I don't think they necessarily failed because I wasn't passionate about the space. And in fact the second one is quite successful. Um, of course not to the degree that Supabase is, but my co founder there's done a phenomenal job of scaling it and I helped him a lot. I really like the space, I like helping service workers, but yeah, I'm passionate about tech.

Speaker B: How do you now approach building new products at Supabase and getting those into product market fit?

Speaker A: We could just kind of push things out and people would adopt them and we didn't have to worry about, you know, 8 million developers trying something out on day one now. And also we've got a very well functioning business, so.

Speaker B: So. But back then it was a little bit more improvisational and you would have one or two engineers work on something that you thought was good, the customers thought was interesting, and just put it out in the world, and that was that.

Speaker A: I think in our second launch week, one of our engineers had built Supabase storage, somewhere where you could store, I think it was storage, I can't remember exactly, but for storing files and videos and things like that because you can't stick them in your database. I remember we're about to launch it for launch week and literally two hours before we launched it, he wasn't happy with the DX of the client libraries and he just kind of rewrote them and launched them after that to be more like Supabase. So it was very much like that. We were just kind of like bouncing ideas off each other, trying to make like a perfect integrated suite and we could test these things out and we weren't too scared to put something new out into the world.

Speaker B: And so then how does it work today, running at an outscale business?

Speaker A: When you're building something new, you have to be able to scale up. That's rule number one. You probably need billing on it. People will abuse things, strong security, guardrails. There's all these things that you need to think about before you can really push it out. And so now where we're moving towards is more like a, uh, pipeline. We're used to have this pipeline, which is private, alpha, public, alpha into beta. Now we're thinking, well just put it out into labs where we'll have a smaller subset and people might discover it organically, but it doesn't necessarily have to have the full marketing weight behind it. And then we get feedback from that and then it uh, can start moving natively into the platform.

Speaker B: What do you think makes a great developer experience? If you had to talk about it in the most concrete, specific way or you were teaching someone like your ideas about what it means for something to be truly incredible. From a developer experience perspective, what are the underpinnings?

Speaker A: I think the key metric is time to value. You want to get the developer to their aha moment as soon as possible without getting blocked. You know what a bad developer experience is? Just a ton of paper cuts where you're getting blocked all the time. You're trying to achieve a goal. You usually have a goal in mind. I want to build a uh, to do app and you just get stuck on three or four things and then you give up. So a good developer experience is take any one of those whatever their goal is and the ability to get them to that point as soon as possible.

Speaker B: What did you do in building the product? Or from a product strategy perspective to solve the graduation problem where, you know, I think a lot of people's early critique would be oh, Supabase, great to hack on the weekends and get going, but when you're doing real and production workloads at scale, you're eventually going to move away and you guys have managed to keep just incredible customers at incredible scale. Did you think a lot about that or did you just make the product better and better or what was true about what you did? Where Firebase, obviously that was a critique for a long time, which is a great place to get started, but not a great place to scale.

Speaker A: Yeah, we thought a lot about this and it's actually kind of right from the start part of our strategy. So we want to build a generational database company. We had seen many database companies come at it and say, I'm going to build a bigger, better whatever and then people will want to use us. And they didn't really succeed. If you look back over the past 20 years, probably the only database companies that have really managed to do well are, uh, Firebase and Mongo. And they did well because they targeted these day zero workloads there. You kind of would choose them before you even knew what you were going to build back when you were a developer. So we knew if we wanted to build that bigger, better experience, we first had to win The Day zero experience like the Mongos and the Firebases. So that's where the positioning open source Firebase Alternative came from, where we just pushed that quite hard because we knew that people were choosing Firebase at the start. Well, let's give them another option. And then we smuggled Postgres in at the start we didn't promote too much that it was Postgres. We weren't sure if people would understand it necessarily why we were doing that, or they might even say, uh, I don't want postgres, I want MySQL at the time was more popular. Over time it became clear that postgres was winning. And so we slowly started to migrate our tagline from Open source Firebase Alternative to just this build in a weekend scale to millions. And the positioning helped that slow positioning and we started doing. A lot of our marketing is largely around memes, a lot of Postgres memes, uh, just talking about Postgres, promoting Postgres, doing what we could to promote it to developers and sticking up for Postgres where we could in the uh, ecosystem and defending it for different things and leaning into its features as much as possible.

Speaker B: What is the role of open source in the company's history and how has that been such a input driver to the success of the company?

Speaker A: So everything we develop is open source. We have either a, uh, MIT Apache 2 or Postgres license with the exception of like the platform code, all the billing and everything like that. But if you want a Supabase stack, you just can do Docker compose up and you get the Supabase experience. We don't put any tracking on that. If you want to use it, you get it for free. We try to stack it with as many features as possible. If features aren't there, it's just because we haven't quite got around to it and we sometimes things move faster so there's no real strategy like, oh, we'll uh, use it as an onboarding tool to get people on and we'll gate some features. It's really just because Ant and I, ah, are philosophically aligned with open source and I love open source. Postgres itself is open source so we get a lot from it and we want to as well contribute back to the ecosystem as much as possible. It means that we can employ a bunch of open source maintainers from around the world and that's nice as well. We hope that we can employ more and more open source maintainers, which I think is really just good for the world.

Speaker B: Would love you to talk more about the incredible AI tailwind that emerged for the business. What was the story behind what it was like on the inside? Because you obviously built the company. We're having a lot of success before everybody started Vibe coding and diying, and it seems like it just created just incredibly explosive growth and then it caused you to rethink the roadmap and direction. Or maybe you could talk a little bit about that experience kind of re accelerating years into building the company.

Speaker A: I see it in three distinct phases. So phase one was the kind of. Everyone was getting into embeddings on the database side, vectors and embedding. So we were one of the first to offer PGvector. In fact, I think we were the first and helping to promote that. We put that out and that saw a lot of uptick as well. End of 2024 was when the likes of Bolt and Lovable launched. And that was also an interesting. That was kind of the second tailwind. We thought we were getting ddosed at the time actually, because we just saw this customer launching lots and lots of databases or these two customers and they

Speaker B: chose when they launched to have you all as the sort of standard. Hey, do you just want to set up a Supabase, uh, instance?

Speaker A: Yeah. The experience would be you'd come in, you click, uh, a connect to Supabase, and it would bring back your database credentials. So then you could build on top of it and you just prompt your way through a, through a backend. It's gone through several iterations. But yeah, I mean, the growth was very strong immediately. And you know, it's always vague. I mean, in hindsight you think, oh, uh, it's very clear this is the right move. We should definitely support all these platforms. But I remember at the time, even internally people were saying, uh, ah, these are just prototypes, Vibe coding. Lots of slop back then, lots of slop now sometimes. But I mean, good products and bad products being built. The thing that was clear for us was that principle that we had at the start. We want to be there when people are getting started and then make sure that they never want to leave. So even if they were getting started building things that weren't going to be huge businesses, we still needed to be in that space to learn to understand and as well, uh, I mean, a lot of thinking on, uh, you know, do we need our own front end? But we kept, you know, we're clear that we just want to be a database company. This is all we want to do. So that kind of helped to hone what we should be in that wave, which was just this platform that will supply the backend for all of these AI builders. And that became the focus of 2025. And we built out this product called Supabase for platforms. It kind of looks like an enterprise offering where an enterprise might need a single pane of glass to see their databases and which ones are secure and tools around them and usage and everything. So this was the thing that helped us. We knew that we could kind of map this product that we're building for platforms. It was kind of mapping to our enterprise roadmap anyway, but you know, on different sequencing and a slight twist. So we just got to work building that product and uh, it was a huge growth lever for 2025. And then phase three is largely from, from January this year, the likes of Claude Code and Codex and everything that are just ramping up really, really fast. And these are the tools that are using more the CLI MCP type workload. And we're seeing huge adoption from them, in fact, acceleration the likes of what we saw even at YC, but now happening off a base of 7,8 million developers.

Speaker B: So is it just year after year, it feels like there's just so much more that you need to do than you can get done at any given point in time. And it just feels quite chaotic even at this scale.

Speaker A: Pretty much, yeah. So like now, of course, the, I, uh, mean at these scales that you start getting to, then you've got these like success problems, which is just keeping up with the growth really. And strange things like in certain areas we're going to run out of IP addresses in four months or something like that. And you've got to quickly solve all these problems, otherwise the whole business can't launch another database. You know, lots of things that just crop up that you have to swat away all the time and they take a lot of focus away from that product marketing, like launch, launch, launch. But that's just the phase that we're in. I think you see it with all the AI, uh companies now, where you're either launching a lot or your stability is not so high. And so from our point of view now we're just making sure that we can scale to the next 10, 100 million developers.

Speaker B: If you break apart the company's life into a few chapters, how is your time spent changed in any given week?

Speaker A: Yeah, uh, chapter one was pretty clear. I was just building and there's a lot of fun because as well, there's nothing more fun than building for People who want what you're building. We spent a lot of time doing that iteration. When we got to around probably 50 people, we start splitting into teams and I was maybe doing a bit of a hybrid of managing people.

Speaker B: But weren't you doing a tremendous amount of recruiting then? If you had 50 people or.

Speaker A: No, we've never really had problems recruiting. I think this, we've got so many reasons to work at Supabase. The brand is well loved, it's open source, it's developer tools, we're fully distributed. So a lot of the time we were finding people who they were either building a tool that we needed or they were contributing to our um, repositories and we could see that they were doing a phenomenal job. And we just said, uh, do you want a job or. A lot of ex founders actually were just coming to us asking to work at Supabase. So I don't think we were doing a ton of outbound if I'm honest. But eventually that became more of a thing and my co founder is very good at that and he is very keen on keeping the culture very distinct as well. So we shared that between the two of us and we're both developers so we know what we want in terms of the culture of the company. Yeah. So recruiting became a, uh, big thing, probably more. Last year we had, in the early stages, you know, I said at the start I had kind of this, these scars from blitzscaling without product market fit. And we had this idea that we'd only hire when we had a hair on fire problem for the first probably four or five years. And so we got to maybe 200 people with that mentality or 150 people with that mentality. And then we quickly had to change. Like halfway through last year we just said, all right, there's just way more work than anyone can do. So we just need to get people, get people in as fast as possible. And then, yeah, it really became a, uh, hiring, uh, hiring became a top priority, not just for us, but for all of the team.

Speaker B: Do you think given how much technology is changing, it's productive to spend time thinking about a three year time horizon?

Speaker A: Yes. In some ways I don't think you need to think about exactly what products to push out. Like we don't need to think about exactly what product to push out, but we need to think how our platform will evolve. So a good example is when we started, the company was very dashboard. First developers would come in, they'd launch the database from the dashboard, they'd Use it. Now with agents they're becoming very CLI first. And so this one's kind of obvious to everyone. But you know what spills out the other side of this is, okay, what that means is that everything is very code first, it's very git first. And so what we want is, you know, on the cli, for example, one thing that I want the whole thing to shift towards is that if you use the cli, you get this Supabase folder and that should be a pure representation of everything that's on your platform. So in code essentially, infrastructure as code inside your data, your folder, and that should include your database schema, uh, declarative schemas. Everything should be there for the agent to understand. It shouldn't have to reach out to the platform. So what this means is that we just get parity across every surface area that we can. Dashboard, cli, mcp, all of them should kind of match. Then what spells out the other side of that? Okay, well people want to branch on git, so everything needs to be branchable. Whether it's buckets for images, your database needs to be branchable. You need to have testing environments that are, that are cheap and ephemeral for doing these branches. And then of course like there's the obvious stuff. If agents are uh, building now, then they'll probably be operating in the future. So at the moment maybe uh, developers in looking at things whether the database is healthy or not, but of course they probably don't want to be doing that. And that's actually where most developers don't want to spend any of their time is looking at whether things are healthy or not. So building out the infrastructure that will have kind of self driving databases on all vectors, the performance could be improved, the reliability, the uh, security of it can all be improved by agents essentially. And then you can choose where you want to be inserted into the agentic flow.

Speaker B: What is distinctive about the Supabase culture and why have you chosen it to be that way?

Speaker A: We're completely distributed and asynchronous. We chose this one largely because of it's a bit of path dependency. We started during COVID and then out of that we continued on this way.

Speaker B: Do you think if Covid didn't happen you would be a traditional in office company?

Speaker A: I think we would have been forced to through yc. They really want you to come to SAF and be based here and built here. And that is the right approach I think for 99.9% of the companies. I think for us it's worked well because we're open source, we hire a lot of database people. Those people are spread out around the world. So it's worked well. Yeah, and now it's a bit of a superpower because our attrition is extremely low. But the, uh, leaning into the Async culture has helped because everything's written, everything's recorded, everything's captured in Slack or Notion or one of our sales meetings is ingested into our warehouses. And this kind of solves the Metcalf law issue as we scale up. So because everything's there, ready to be searchable, AI has solved this for us. Instead of our CFO coming to me and saying, hey, when is Multigris going to launch? Then I can say, oh, uh, you can just ask the AI the timelines and he can do it without reaching out to a developer and him being non technical, he might not even understand all of the intricacies of a product and he can ask the AI, oh, uh, can you explain it to me from a finance point of view, what does it mean? And so this body of knowledge, the whole history of Supabase has now been embedded and you can search through it. And I think that's going to be a critical thing as we continue to scale up.

Speaker B: Um, what about distinctive in the sense of how you behave, who is a great fit for Supabase and who isn't, what behaviors are celebrated, what gets someone exited? Like, how did you land on those type of distinctive things?

Speaker A: First of all, of course learned very early that not everyone are uh, built for Async and you have to be of a certain ilk to really love it. And if you didn't love it, you just weren't going to love Supabase. So that's the trade off. I mean you just have to be clear about that with people and you'll miss out on some people who just could be good but they won't work at your company. The other thing that is really important to us is we have quite an egoless culture, which often people think like means unambitious or something like that, but actually like superpace is hyper competitive. It uh, boils down to the open source mentality, especially like old school open source people who, you know, you're out there probably grinding in public, putting out your code for free, but you want it to be top notch. You know, that's a certain mindset, is hard to explain and hard to find, but you can definitely find it in the open source ecosystem. So we've tried to really capture that ethos inside our company as well.

Speaker B: How do you figure out if somebody has that before they join?

Speaker A: You know, you can talk about in the past, the uh, projects they've worked on, problems, conflicts that they'd had, how they dealt with them, even knowing how they, they talk about things inside the interview. Is it lots of me, me, me? Is it the team and putting the team first and things that we worked on? Yeah, there's lots of little towns.

Speaker B: Do you think it's relatively easy?

Speaker A: Well, especially for my co founder. He's the key bar raiser and he can suss it out. He can suss it out very well.

Speaker B: How, uh, why is that so important to you?

Speaker A: I could be doing this business for 30 more years, you know, and I want to work with people like that. I don't want to work with assholes.

Speaker B: There seems to be this kind of warm, kind quality. And my conversation with you, do you feel like that is who you are?

Speaker A: I guess so. I mean, if you feel it, then, uh, uh, yeah.

Speaker B: Well, there could be a whole different side of you. I mean, the thread I'm pulling on is I find that, you know, a lot of conventionally successful and ambitious CEOs are like very difficult, oftentimes cruel at times. And I don't, I'm not experiencing that in our interaction. Yeah, maybe you actually are that. Do you? You know, maybe it's some of that New Zealand.

Speaker A: Yeah, yeah, yeah.

Speaker B: Sort of generous spirit. Do you think a lot about that at all in the context of like your identity as a CEO? Like you're building one of the most spectacular infrastructure companies. There's a certain kind of kindness about you that comes through.

Speaker A: Yeah, I think probably, as you point out, because I'm, uh, from New Zealand, we're generally sort of as a kind population. A lot of CEOs I know are uh, definitely, as you say, they can be cruel or Machiavellian or something like this. And I see that. I mean, Even with the CEOs that I interact with or in the space that we're in, there's a lot of that. I don't think we need to be like that. Like, I'm very much a, uh, rising tide. We'll raise all ships. The, uh, database space is going to grow phenomenally for everyone. You know, I want to look back at the end of my life and think, oh, not only did I build a big fucking company, but I also did it my way and like people ways that people look back and say, oh, that's actually respectful, like. And I have a certain Affinity to especially like the, uh. I've actually been doing tech for a long time. You know, the old school open source mentality where people are just out there building things and putting their code there and contributing and. Because they love it. Yeah, because they love it and I love what we're building and I love the space. I love seeing what people are building. Like, I've got no qualms with anyone operating their way. But inside, like the realm, the sphere that I'm operating in, I just want to operate like a good human and see other good humans succeed.

Speaker B: And so do you think ultimately the culture is just a reflection of you two and your values and who you want to work with?

Speaker A: Yeah, I think it comes down a lot to that. And of course then you hire a couple of people who are like that as well, who are self perpetuates. Yeah. And, uh, self perpetuates who've got some values like ego list, true seeking, batteries included. And we did this thing at our off site where we got everyone to rank the five different values. I'm pretty sure they ranked them in the same order that I had ranked them personally. You know, inside the company, which is kind of crazy because one of them is just to be undeniable means like so great that you can't be denied. And we have like a few examples of those people who are just titans of industry, you know, undeniably good, and yet still the egoless part of it was the thing at the top. And that was the thing that someone got off and said, you know, I've never been at a company that is so successful and yet puts that on top. And so you can see that you get people around you that are of that mindset. It's kind of obvious to a lot of people. Of course, if you could have both an undeniable culture and an egoless culture, uh, why would you not want that? I think it's just that many people think that these two are at odds with each other and they can't coexist. But that's the thing that I think is untrue. It got pushed a lot by our investors and I just said, no, no, no, this is not true. This is how it's going to be.

Speaker B: You just mentioned investors. You talked at the beginning about fundraising. If you had to teach somebody how to be excellent in raising capital, what's like the little course that you would

Speaker A: run, a little playbook other than the

Speaker B: most obvious thing is build a spectacular business that investors are tripping over themselves.

Speaker A: That's rule Number one, if I was to do a tactical plea book, it's probably like, first of all, you need to be in touch with a lot of investors, otherwise you don't have any of your lead gen. So I'd probably start meeting a lot of investors. And you really treat it like a completely different play from startups. You switch mentality from builder to fundraiser.

Speaker B: What does that mean?

Speaker A: I will normally, especially talking to developers, underplay a lot of what we're doing. But with developers, that hedging is to your detriment. In fact, they'll discount anything you say anyway. So if you tell them, uh, you know, we're going to be a billion dollar company, they'll probably think, well, they'll only be a $500 million company. You say 10 billion, they'll probably think, oh, only a billion dollar company, you know, so whereas with a developer I'll always, um, under promise and over deliver,

Speaker B: what do you think makes a great pitch? Or when you're telling your story or you're having a catch up with someone at coffee and you want them excited about the Supabase story? What is different about that than when you're talking to customers or people that you may recruit, other than maybe what you said, which is you have to be maximally ambitious because of the sort of discount that an investor might apply in their own brain.

Speaker A: Believing that you are going to be that ambitious is actually the thing that matters and then sequencing of it. So it's a bit ridiculous to be ambitious and think that you're going to get there anytime soon. But where we are today and where we want to get to is going to take, you know, 10, 30 years. And being deliberate about how we're going to get there and having clarity about the steps to get there is kind of what matters to an investor. So they need to both believe that ambitiousness is true and that I, or whoever it is pitching has thought about how to get there.

Speaker B: Do you enjoy raising capital?

Speaker A: Yeah, not really at all. Actually it's a huge distraction from what really matters. But for a database company it's a very necessary part.

Speaker B: Over the life of the company it seems like you've been very PLG focused, kind of, at least in the early days, didn't get pulled into mega enterprise with an endless roadmap. And obviously more recently you uh, have companies of almost all scales building on top of Supabase. Did you think much about when you would really think about a, uh, global 10,000 company using the product and what they needed was that sequenced in A specific way or did you just wake up one day and say okay, we're a big company now, we can take something like that on?

Speaker A: No, the sequencing was important. So if you think of uh, types of companies from like risk averse enterprise, which will be not even just enterprise, like bank or something like that. Yeah, mega enterprise and then like indie developer right down here and then like a bunch of getting started use cases. So like launching their bank is like up here. Production workloads we started down the bottom left and I think the big problem is that most people try to then jump. If they're doing plg, they try to jump as well to the top. Right. Whereas we just thought of like adding these layers. So we're just building out even today. Of course we couldn't host a bank on our platform but you know, I've got no doubt we'll get there one day and it's just about making sure that we're adding those layers incrementally. So an enterprise actually could come in and be one of those players. And as long as it's one of those workloads that fit within the sphere that we uh, are currently operating in, then we're happy to work with them. Innovation workloads for example, if they want to get started, even if they're a bank or maybe um, they've got a big open source prison and they actually want to understand how they can use some of our open source tooling, we'll chat to them about it so that we're building the relationship with them.

Speaker B: But in any given point in time, your resource constraint, like your ambitions and the roadmap is multi decades long and you can only ship something. So many things in X period of time. How do you think about do I want to make what we're doing better? Am I willing to go up and sort of move out and sort of the visual that you represented.

Speaker A: Yeah. As you add more people then the uh, roadmap kind of like it was very linear, like small and linear when we were getting started because we only had a few people. So adding products but then you've got to add all the operational stuff plus the products and get all the certifications. So you need to build out those, those teams over time. We just saw enterprises coming in and they might say, well not even enterprise, it could have at the start it was an SMB and they'd say uh, we need this and that type of thing to add whatever they needed. Might be, you know, only say three or four months on the roadmap. And so we knew that we could achieve it and then we added and it's available then for all of the startups on, on our platform. Now if an enterprise comes in and they say something that is also going to benefit maybe a thousand customers, then we'll add it. But if they say something that's bespoke to them, then of course we'll just end up saying no because we really want to make sure that everything we're building benefits a huge pool of customers at this stage.

Speaker B: What about on the go to market side? Has that evolved a lot?

Speaker A: Yes, yes. So we do have now as well an enterprise motion where they'll come in and it's more like a uh, sales growth. But you know, in terms of the sales team, their focus on that, it's very much like a 10% of focus, 20% of focus. The key focus for us is moving from plg, which is just purely organic. People sign up, put down their credit card to a uh, product led sales motion. I don't know how popular it is. I think it's not, especially not the way we do it. What we have done is take a lot of signals from our PLG motion. It could be like for example someone is, you know, they're thrashing their disk on the database side or like they're hitting CPU limits or something like this. So they're probably having, encountering a problem. And we pick up a lot of these things, we call them triggers, product triggers. And then when we find one of those, if they fit some, some category, we actually do like an automatic automated outreach to them. An email saying uh, hey look, looks like you're having this problem on your database. Do you want to jump on a call with one of our teams? If they respond then we essentially can get this report from their usage and we can see all the products that they're using and um, we can give it to one of our success team, sales team and say here's all the things that they're having an issue with and just go help them. So our sales actually just looks like support and that's important. We actually don't really want to sell to people, we want to help them to grow if they want. Then we take all the cohort of people who respond and we rank it against all those who don't respond. So we've got that kind of as a, as a control group and what we do is we measure those who don't respond, how much did their usage grow? And um, actually we know like quarter over quarter. It's 25% versus those who have chatted to a success person and that's 125%. So we can see the incremental uplift from those who are chatting to our support team, our uh, sales team.

Speaker B: Is the sales team quota carrying?

Speaker A: Yeah. On the incremental uplift only which I think is the big difference from what was traditionally done. You know on a PLG motion you could easily say ah, uh, get a salesperson in so on um, like reach out to anyone and then you pay them on, on the revenue generated by that customer. But if that customer was going to pay you a hundred thousand dollars without talking to a salesperson then you don't really want to be saying oh, the salesperson could actually just be getting in the way. So we only measure and over time want to continue to measure that incremental uplift and then that's what they get comped on.

Speaker B: Are they salespeople or are they truly support or technical support or sales engineering style?

Speaker A: Sales engineering? Yeah, we've got a mix of both. So um, account managers and salespeople and customer solution architects. And the most important seeing at our stage especially going from a PLG is very much like a very technical engineer who actually can understand the product, talk to the developer. If it's from maybe a thermographic point of view or someone who is more on the business side and they want to say spin up thousands of databases then it could be more of a

Speaker B: salesperson, less technical in the process of helping that customer. Are they selling them new products? Hey, have you thought about using this? Or we can help you with that

Speaker A: or they can do but that's you know if they understand the workload and it seems relevant then then they can. But you know developers are um, not, they're quite allergic to sales and so we definitely don't want anything to be forced down anyone's throat. So it's really the guiding principle is just be helpful to the customer and, and that's all that matters.

Speaker B: When you zoom out and you think about the trajectory of the company thus far. Are there any other unconventional or non consensus decisions you've made or ways you've organized the company that have mattered a lot to the success of the company?

Speaker A: It's literally embedded in our product principles in the docs we don't like lock in. We try to build on protocols and open standards so if you ever have an issue you can kind of like with our postgres PGDUMP and take it somewhere else. It's your data and this forces us to build a great experience and compete on that experience. To be honest, again, I don't know if this is a strategy that works. In fact, sometimes I see it doesn't work and you never kind of really learn the counterfactual. I don't see many people online saying, oh thank God, Supabase have this principle and now I'm going to do everything with them. But for me I just know like if I was to use myself as a model of the customer that I want to build for, I think that's just important from the ethos of how the platform should feel that everything feels like simple primitives protocols and it can work without lock in. And I think developers feel lock in very early on in their investigation of a uh, platform and it scares them away. It scares me away from things that I feel uh, too locked in. And it's hard for us as well because of course like when it comes to developer experience, I'd love to just do something that Postgres completely does not do to achieve some, some goals that we want from the product side but it's hard for us to do it in the postgres way. But if we can pull it off then there's a certain elegance about it, like a craftsmanship that I think seeps through and m, maybe that's the one that I can point to. I see online people pointing out how the elegance of the platform that is using these open protocols and primitives, but somehow makes it feel very integrated in uh, it like a single product.

Speaker B: And that's sort of what's really guided these decisions.

Speaker A: Yeah, yeah, very much so.

Speaker B: What have you found to be very hard? Have there been these intense pivotal moments? It feels like so much of it has been immense amount of work but not like soul crushing or near death experiences or there's a calmness about what's happened with the company you've built. I don't know if you, how you would articulate it, but sort of in the rear view, have there been these intense crossroad moments, these very hard tricky things, or has it just kind of felt very natural and kind of just flowed out?

Speaker A: No, I think like, I mean it's hard to emphasize how painful it can be for a lot of people. Scaling like this is a uh, success problem. But scaling for some people like myself included in the early days meant like you know, grinding very, for very long hours. And yeah, I mean we've got some people in the company who going through periods, you know, get burnt out because there's just so much to do because as I said, we had this hiring philosophy that didn't allow them to offload. And then you get this hero culture internally where they're the only ones that can solve it. But that's very hard to solve because the only people that can solve a hero culture is the heroes themselves. They have to hire those people and train them up and offload a bunch of stuff. So this is kind of like a mini thing where, um, like my painful experience was giving away my Lego and all the things that I kind of wanted to do. And they as well have to learn to do that themselves. Even though they might just be an engineer and they don't think about having to do that. They don't get people telling them all the time, this is how you escape a hero culture. So a lot of the hard periods is just hitting these scaling dynamics and that can lead to all sorts of issues. I mean, whether it's like running out of capacity on, as I said, the IP addresses or literally just servers capacity and things like this. And these things are very hard to deal with because they're kind of like unsolvable in many ways and we have to scramble to do all sorts of things. But you want to make sure that you're doing your best for your customers and for a customer centric company to not be able to do an amazing job in some areas. That's what I take. Painfully. Yeah.

Speaker B: Uh, what about you has made the company work like you've been to date immensely successful as the founder and CEO of this business. And so like, what about you or your temperament, skills, abilities, do you think is like the input driver?

Speaker A: I think the main thing that matters is I think in processes. So I think a lot of people think in outputs or like fixed points and things like that. And I very rarely think this way. It's more. We have a term which comes from the Toyota production system that we use a lot, which is called Kaizen. Kaizen means to incrementally improve all things from the CEO to the assembly line worker. So in the Toyota production system, they literally mean down to the cleaner, we'll look for perfection and how they clean and doing it as a system. So I love this way of operating and thinking of things. Always like, well, things go up, things go down, they're. They're just processes. How much they go up and down is what we need to matter. There are control targets on, on all of these things. So, you know, I largely for a long time thought in Kaizen and used that a lot internally. So from the product side, just incremental the product, make small improvements, ship and shout to the business itself. We've got processes. The RFC process is broken, let's change it. Just make a small change and never trying to make anything a big bang change. It's always just incremental. Then from there you can map your business into processes. So that's where we're kind of at at the stage which are uh, more isolated. You can look at you know, your top of funnel and that's isolated maybe to the marketing team or the devrel team and you might look at your churn as a process and that could be isol to the product itself. And then largely, you know, towards the tail end of this year or even now, starting to think more in systems. So going up a level again and the system is from what end to end does it matter? You know, it's no good for example automating some small part of the business. What actually matters is making sure that a uh, full end to end part of the business can be completely automated. So that includes the system of, especially as we've grown now into multiple teams. Product team, engineering, team design. How did these three teams operate as a single unit from one end of the spectrum to another and the kind of handoff between the teams then becomes what, what is the most important thing? Anyone can iterate really fast in a small ecosystem like a startup does. But as you grow, what matters most is having these improvement cycles within the entire system.

Speaker B: Talk more about why you think this way of seeing the world has mattered so much for the company.

Speaker A: I think because people unblock um, themselves a lot. If I always scope things down to being small improvements, small improvement, you always see people getting blocked on the big things. They'll try to do something really ambitious and it's obvious why it happens. I call them like we do RFC's requests for comments, which are kind of like our PRDs. The design team might put something out and I might like a hundred things inside what they've done. If it's a huge thing and I might dislike that one thing and I just comment on that one thing that I dislike, you know, so it's obvious where things get blocked. You want to have small changes which can easily get through the systems of blockers. Avoiding the blockers and giving people a uh, mentality to avoid those blockers so that they continue to ship is important. And then enabling other leaders in the company to remove those blockers if necessary is also a critical part. So defrag we call it in Supabases from the product side, but also from the business side. We went through a cycle of looking at all the systems that kind of are a bit broken and like a defrag. The old defrag, and in, uh, computers, like, tightening those up.

Speaker B: So I just wanted to wrap up with. What is it that you want your customers to say about you and your team members when you're not around?

Speaker A: Me, personally?

Speaker B: Yeah. What's like the North Star for you?

Speaker A: For my team, I would hope that they don't say much about me. I would hope that they think we did it. You know, that's more important to me than, like, oh, Copple was in and he, like, he's such a good leader or something like that. I would far rather them feel like, oh, we're smashing it, you know? So that's way, way more important to me than anything that they would say from the customer point of view. I think the thing that I would want them to think, I don't need them to say anything about me, but to think that I actually want to solve their problems. That's pretty much it. And just like to film that, you know, I'm in the community with them. I'm, um, like them. That's how I feel. Like, I'm just a builder as well, and I'm in there just to fix some hard problems. And, you know, over time, I would hope that I'm building the platform that they kind of want to see in the world. Cool.

Speaker B: Thank you so much for doing this.

Speaker A: Thank you.

Speaker B: I really appreciate it. This was great.