Paul Copplestone:

Who says no to a million dollar contract, especially when you're getting started?

Jack Bridger:

I'm joined today by Paul, cofounder and CEO of Supabase. If you don't know Supabase, it's a tool that helps you build in the weekend, scale to millions.

Paul Copplestone:

Slowly, like, you'll make a lot of money, but over time your growth tails off. It's kinda like the point of no return has already passed.

Jack Bridger:

How did Supabase earn the trust of over 3,000,000 developers?

Paul Copplestone:

This became like rule number one, don't kill the channel. You trade cash for culture, basically.

Jack Bridger:

Enjoy the episode.

Paul Copplestone:

Next year, we'll be, like, flying, what, 200 people to to Vietnam, and then, like, putting them in a resort in Vietnam, and then, like, you know, what to do over those seven days. Like, do you build up a whole team to do this once a year, or do you just have someone kind of working with external people?

Jack Bridger:

So and I guess you're choosing external people.

Paul Copplestone:

Yeah. Yeah. A bit of both, you know, but, like, the the mandate is essentially, like, hire the minimum number of people internally and then work with people externally.

Jack Bridger:

Yeah. That makes sense.

Paul Copplestone:

You trade cash for culture, basically. You wanna keep your culture tight and then the external contractors are more expensive. But, you know, we can keep our teams smaller.

Jack Bridger:

Yeah. You're not getting that drift around, like, people that are, like, very far from, like

Paul Copplestone:

Yeah.

Jack Bridger:

Devs and open source and stuff as well.

Paul Copplestone:

Yeah. And then yeah. Like, not only that, I mean, like, even the developers that we have internally, you know, as you add in people, it's kind of like a I don't know what they call them, the game where, like, you you whisper and then you whisper the whisper game or whatever. Like, that's kinda how it feels like maybe Ant and I spent a lot of time, like, setting the culture, or maybe not even setting the culture, like, just we just work and then we get less FaceTime for better or worse than with all the new hires. And so how do we make sure that they kind of get the culture from from the source as much as we can while we obviously can't do one on ones with 200 people?

Jack Bridger:

Yeah. And you've I think you've talked about this like writing. Is that the main mechanism that you

Paul Copplestone:

Yeah. I think it changes throughout the journey. So now, like this year, we'll probably we kinda have to double in size just even for, like, support tickets. If we wanna keep up our quality of support, we'll just need more people, which also means the engineers, you know, they need to make sure that we've got great uptime and just like the support burden for the engineers is is a lot. And so in these cases then, yeah, it's not enough just to to write their onboarding experience needs to be phenomenal because we can't just write ad hoc.

Paul Copplestone:

They kind of need to go essentially through a training program Yeah. To get all that history of what people implicitly soaked up over the past four years, the ones who have been with us and they kinda get it and they got it implicitly. Now we have to be very explicit about, you know, what is our culture and kind of try to design. We haven't done it yet and I think we need to spend some time, like, designing up what does a good onboarding experience mean in Supabase, in particular, as a remote com company with an open source culture and very flat, you know, designing that specifically around how we work is is, yeah, what we're spending time on or like what I'm spending time on.

Jack Bridger:

Yeah. Because I imagine some of it's quite like hard to communicate. For instance, I mean, the obvious one for Supabase is like the kind of humor. And I don't know, if that comes into culture or something. But I can imagine, like, it's very hard to explain, like

Paul Copplestone:

Yeah.

Jack Bridger:

Why is this funny? Like, why is this a good joke? And zip it out. And this is very Supabase, and this isn't all like.

Paul Copplestone:

Yeah. I think as well, like, it's a funny one with culture. The the best cultural onboarding happens before people join rather than after they join. So, like, ideally, what you've got is, like, people join Supabase because they know this is how we operate

Jack Bridger:

Mhmm.

Paul Copplestone:

Rather than they join because they've got a good skill set, and then we say, oh, by the way, can you act like this?

Jack Bridger:

Yeah.

Paul Copplestone:

So so, hopefully, they've, like, seen our Twitter, seen our memes, all these sort of things. But as well, like, Stripe do this very well. I think they've got a kind of principles or culture page and it's just like 20 bullet points that are publicly available. Or maybe famously the Netflix onboarding doc, you very much know, oh, operate like high performers, like a sports team, these sort of things. And so you kind of know the culture and you might gravitate towards it if that's what you like.

Jack Bridger:

Yeah. And I think you've I think you also spoke about like almost like telling you making it like filtering out people because I think you've like it's very async culture and like I mean like one meeting per week Per week. For teams and stuff and like some people wouldn't like that. Yeah. And but some people would love it.

Jack Bridger:

So

Paul Copplestone:

Yeah. Especially at the start because when we were, you know, just, you know, 30 people, you might have almost no FaceTime with people. Now as we get bigger actually, you know, there's more and more Slack messages, there's more like interaction with people but definitely at the start if you were an extrovert, you wouldn't fit in like you just you'd be like, what's happening at Supabase? So we kinda just left people to work and then they'd check-in once a week and then they'll go away for a for a week. And, yeah, we had people leave literally because that was too too racing for them.

Jack Bridger:

Yeah. But that must be like quite hard to kinda maintain like as you're saying like doubling like to try to because I know you hired like a lot of ex founders and stuff. But it's like pretty quite hard to hire like, you know, as like double the team with like primarily ex founders and stuff like that.

Paul Copplestone:

Yeah. Yeah. And, you know, when it gets down to those, like, two two or three levels, you're kind of essentially it's it's a bit like a train the trainer, like, we essentially trust that we've trained the the early people enough that when they hire people, they will do a great job at training those people or, like, culturally onboarding them or, like, setting the culture within the company.

Jack Bridger:

Mhmm. So I guess it's like if you kind of messed that up at the beginning, it's like Yeah. You can't go back at this.

Paul Copplestone:

Yeah. Yeah. Which and I think that's really the thing Warren Buffett always says, like, tell me where I'm where I'm going to die so that I never go there, is kind of the thing. And we, I think, did this philosophy quite well at Supabase and this is one of them. We said no to people who are great kinda on paper, but they might not fit the culture.

Jack Bridger:

And Mhmm.

Paul Copplestone:

Ant is kind of our bar raiser. He's very good at it. We were yeah. I think set that kinda cultural bar as, like, the the number one priority. And luckily, yeah, when we hit years like this year, which we've been really lucky to get this really high growth, then then it makes a big difference.

Jack Bridger:

Mhmm. Yeah. I I can I I can completely imagine? And then kind of saying no, maybe using that as a segue. I know that like enterprise stuff is like very kind of top of mind.

Paul Copplestone:

Yeah. Yeah. So this year, we've kind of got actually two things happening. For a long time we you know, the way we designed the business is like, we took a spectrum of like developers and it could go from like, say a front end developer to all the way to a, like, hardcore database engineer. And the way we kind of thought about the developer experience was maybe like 25% along the spectrum of, you know, like, from front end developer, like, so you should start knowing what a database is and we can kinda educate people.

Paul Copplestone:

We wouldn't try and make it just a front end tool. Mhmm. We can actually teach people how to make use a database. But then what's happening, and especially this year, is, like, that spectrum of, like, developer has now turned into, like, VibeCoder Yeah. Builder or something like that.

Paul Copplestone:

So it's completely swung this way, and they actually are a completely different ICP, like, customer profile. And they're great, but they think differently and they use the product differently. And so we've got that one happening, which is kind of like almost like moving down market or or across market, and then simultaneously, like, we've got a lot of enterprise pool and they have competing needs. They might want it for this, like, vibe coding type thing if they're an innovation lab because they wanna get involved or they just need, you know, Postgres and they wanna scale up and they wanna use the Postgres service and they wanna use it more traditionally. And so what we're having is the only competing priorities that we need to to to build for.

Jack Bridger:

Mhmm. Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like audit trails, SSO, SCIM provisioning, role based access control. These things are hard to build, and you could get stuck spending all your time doing that instead of actually making a great dev tool.

Jack Bridger:

That's why WorkOS exists. They help you with all of those enterprise features, and they're trusted by OpenAI, and Perplexity. And for user management, the first million monthly active users are completely free. Let's hear from Utpal from digger.dev, a dev tool using WorkOS.

Utpal (Digger):

How it's designed is that you can start as early as day zero. But for us, it wasn't day zero. It was closer to when we first started monetizing because we didn't have a sign up at all. People could just anonymously use our tool. So it was a little later, coincided with when we wanted to start monetizing and, like, we needed a nice enterprise feature set.

Utpal (Digger):

If you're open source and you're doing enterprise first, the minute you think about monetization is when you should think about Work OS. To be honest, if we do that again, I think we'd think about that on day zero to be honest because like we should have done it on day zero ideally. Anonymous usage should be permitted, but you should know who's using your tool. It should be optional, 100%. It should be opt in, 100%.

Utpal (Digger):

But it'd be great to have auth from day zero. You don't necessarily think about these enterprise features, but they still lead revenue. And it kinda is a no brainer in that sense. So, yeah, I highly recommend.

Jack Bridger:

And and you kinda spoke about, like, there might be like, okay, we're gonna we wanna give you a million dollars, but we need to be able to log in this very specific esoteric way.

Paul Copplestone:

Yeah. Yeah. So this is like the more traditional developer cycle. Essentially, like, if you think about most developer tools that you like or have liked in the past, I'm old enough that I've seen the cycle very many times now. Basically, you start off, it might be an open source tool, you build and then you build a good community, probably founder led usually and really open source focused.

Paul Copplestone:

And then you start making money, maybe you raise some money from VCs. And then once you become a bit bigger and more successful, you've got your community of champions then a mid market or enterprise come in and specifically enterprise who have, like, very strong demands but also very deep wallets. Right? So they'll come in and they'll say something like, oh, you know, I'll give you a million dollars but, you know, how we wanna is this and can you also sign these terms and make it this and deliver this by that date? And they always want changes, it doesn't matter what the what the product is really, they've got some bespoke requirements.

Paul Copplestone:

And so the temptation, you know, is just to say yes because who says no to a million dollar contract, especially when you're getting started. And so the problem with that is then the next enterprise comes, then the next one. And instead of having kinda one product that you're building for your entire community, you end up with say 10 or 20 different products that are kind of bifurcated. You've got an enterprise product for this person and another one for this one. And over time, that kind of cadence slows down and, you know, at the same time, they've got really high demands and all of your focus, especially the founder, shifts towards the enterprise.

Paul Copplestone:

And slowly, like, you'll make a lot of money, but over time your money kinda or or your your growth kinda tails off and then you look back and you think, oh, what happened? And you see, oh, the community has kind of petered out. And then at that point, most of the time the DevTool has happened time and time again. I guess you could call it the in shitification of DevTools, it's quite a common term. But by that time, you kinda look back and you say, oh, well, let's get back to our community, get back to our roots.

Paul Copplestone:

Unfortunately, already by that point, it's kinda like the point of no return has already passed. And so you can't really go from top down to developers, you kind of have to always keep your focus on the developers. I think a really good example would be Stripe, they've done a great job here. And so so, yeah, that's kind of what I think about, like, the enterprise versus developer pool. You basically have to say no in those early stages to a lot of enterprise customers who might want you to make this kind of bespoke product.

Paul Copplestone:

It's not to say that you will never build for them, so that's kind of where we're at now. We've been laying the foundations of how to build for enterprises while simultaneously serving all of our developer pool.

Jack Bridger:

Yeah. And you referencing heavily on this great blog post that you have on your very your very hidden blog that's like no. It's not really hidden, I haven't seen it. I hadn't seen that until I was researching this. But you've written this blog post about like PLG versus enterprise sales.

Jack Bridger:

And one of the things that you mentioned was like, okay, on on how to build was like you were talking about like, you know, if it's like they wanna log in in a very specific way. Yep. You would maybe go like one abstraction level up or so that they can they could do that but also anyone could do any kind of customization that they want.

Paul Copplestone:

Yeah. So yeah. One really good technique here is essentially configuration over customization. So customization is what most of them want and they'll ask for things like, oh, tweak this or can you add this login and can you do it this way. And the way we think about it is more configuration.

Paul Copplestone:

So if they ask for the login, you think about more, oh, well, how can we add a 100 logins? And usually that means adding, say, the protocol for the login that they want. It's a really basic example. And so you add kind of all these knobs and things that you can turn on and off so that you can really have an almost infinitely adjustable product or platform. And then you make it really easy for them to turn things on and off as you kind of move through through the gates of from developer, you start, you know, adding access to more configuration as you as you build out.

Paul Copplestone:

Small example might be, yeah, like on the database side, most indie developers want something super cheap with a really cheap database or like really cheap disks or something like that. They don't care so much about speed. Their core thing is is price. And then as they move up and they start saying, oh, my my website is getting traffic. I need actually need read replicas and then I need faster disks.

Paul Copplestone:

And so these things you kinda gradually expose to to the the developer. And so their journey should be essentially kind of our tagline, build in a weekend, which is, like, small, easy, cheap, and then scale to millions, which is, you know, enterprise ready. And you kind of can hopefully get them to insert at any point. And so we get to this point where we've built for enterprises, and they can insert at this like, a much later part of the journey if they want to. But the platform should still feel seamless all the way from developer all the way up to into enterprise.

Jack Bridger:

And that's primarily from kind of, I guess, some set configurations, but then they can tweak it and probably yeah. Like, got I know you have, like, the tiers and probably those tiers come with sent sensible defaults themselves.

Paul Copplestone:

Yeah. Exactly. So the way we do it at Supabase is, yeah, we set some defaults knowing that the like, on the free plan, knowing that, you know, that ICP, the way they think is more like I want something quite cheap. And we have a lot of developers, you know, 3,000,000 developers or something like that today. And so we kind of know roughly what what they want, it's kind of something cheap and they don't care so much about performance.

Paul Copplestone:

Well, they care about performance, but the the thing that they really care about is, like, how cheap is my database? Yeah. Yeah. And then, like, quite soon they get into, like, oh, I've actually got traffic and you move up to a $25 tier and you can start playing with those parameters. And you have different things that you care about at that stage.

Paul Copplestone:

And so each one of these segments that we've got from free customer to pro customer to team to enterprise kind of fits a different ICP and the things that they value most. The configuration we try to make it, that's more of a developer experience type thing. So in theory, can do everything and it's really about trying to make sure that it feels quite seamless. So this is more product design, but, like, at the start, we focused really on like, not many people know databases. And so to expose a lot of database features, we would have a lot of kinda UI and panels and then SQL.

Paul Copplestone:

And we actually leaned into SQL. A lot of people said, oh, you know, we should abstract away the SQL, but I've got a kind of opinion that it's good for people to learn a bit of SQL as well. Yeah. It's a kind of industry skill. Then we were really fortunate because AI came along.

Paul Copplestone:

And actually, we ended up stripping out a lot of the UI features, like the kind of niche UI features because the discovery mechanism now is just the chat, like, we're gonna AI assistant. So it's actually simplifying the dashboard and increasing discovery just through this sort of interface. So so, yeah, it's really a product design decision around those configuration items as you grow.

Jack Bridger:

Yeah. I think I should probably be a bit, yeah, remiss not to dive into the AI stuff as well. Like, I know that I think Lovable use Supabase by

Paul Copplestone:

Yeah. Bolt and Lovable. We've got quite a few of the platforms there. And this whole wave of the kind of vibe coding wave has been a big big one for us. So that's where that spectrum has shifted.

Paul Copplestone:

And, yeah, it's kind of like a new way of building, I guess, where you kind of, yeah, just prompt your way through through everything. Yeah. And we've had to make, yeah, a lot of changes just to cater to this audience. But, you know, I don't see it going away. I think it's really important that we can kind of cater for both.

Paul Copplestone:

I think both modes of operating are good. It's probably more around that journey, you know, that I said all the way from, like, build in a weekend. It's kind of a lot more like a prompt, but you should be able to escape that into into the code, into the configuration, into GitHub as you grow and you start layering in kind of a maturity model. We've got this inside our docs where, you know, as your product becomes more mature, you adopt more mature workflows as well.

Jack Bridger:

Yeah. Because I imagine that challenge is like so hard because it's like that it's like kind of this chasm of like, I'm in lovable and just like talking, saying I want describing what I want. To to go from there to like looking at like rows in the database and like seeing this panel that says like, oh, here's like SQL that I can write. Like here's like a query. What's a query?

Jack Bridger:

Yeah. Must be like quite challenging like developer experience to

Paul Copplestone:

Yeah. Yeah. It's kind of a I see it almost like a bit of a duty. Like, I I I'm not sure yet whether you can especially not today. You cannot just prompt your way through to a, like, a enterprise application.

Paul Copplestone:

So it's almost a duty. It's not a question of, like, should we kind of allow it? It's like, how can we make sure that, you know, we give gradual exposure? So a really good way to do it from our point of view, and it's one of the first things we built is the table editor. It kind of looks like Airtable inside Supabase.

Paul Copplestone:

Yep. And that's one of the first things that you interact with. Yeah. And it's a bit like, you know, as Excel spreadsheet. So people are kind of familiar with the pattern, but then right below it is a SQL editor.

Paul Copplestone:

And for a long time, we've kind of thought about even collapsing these two. And so, like, you can kind of get a bit exposed, but I I kind of like the separation and how to think at this stage where, you know, you'll think in tables and maybe the sequel editor might feel scary to a lot of people, but, you know, they can see it and then dip away and then eventually they get exposed usually because the community suggests, here's how to solve a thing. They might see it on Reddit or Stack Overflow or Git ChatGPT, something like that. And so, yeah, it's kind of, yeah, as I say, bit of a duty where where then we just keep exposing additional workflows. I know a lot of people find our UI really simple to use.

Paul Copplestone:

Yeah. And they do that even in production, but, like, we try to strongly suggest, like, that they don't do that, for example, that they move to code, that they start using GitHub, start using branching. You don't code just directly on your production. So a lot of it is actually just for that segment of developers. It's not not all of them, but for that segment, teaching them the kind of standard patterns that a developer would use.

Jack Bridger:

Mhmm. Yeah. That that makes sense. And I definitely have been guilty when I've used Supabase of just like creating all my tables and stuff in the inside the browser.

Paul Copplestone:

It's easy. Yeah. And just like yeah. I understand it. And and also we try to make sure that, you know, if you are going to do that, we'll try to make sure that The guardrails.

Paul Copplestone:

The things yeah. We can put some guardrails around it. And if anything goes wrong, we can, yeah, make sure that you can recover any damage that you do.

Jack Bridger:

Yeah. I think you have, like, some kind of, like you're about to do it destructive.

Paul Copplestone:

Destructive. Yeah. Rollbacks. Yeah. Yeah.

Paul Copplestone:

Yeah. Lots of things really.

Jack Bridger:

That's so funny. And then something that you've written about is friction logs. And I thought it was like quite interesting that you felt this was like an important enough topic to to write about. Because you haven't written that many blog posts actually. So it was like very interested on like why it was such a

Paul Copplestone:

Why Friction Months? Thing. They're not actually as big as yeah. As

Jack Bridger:

Okay. Made it big.

Paul Copplestone:

I think we do them we do them quite a lot. I and I think they're one of the best ways, especially for people to give feedback because it's a little bit hard. I think actually we did friction logs because sometimes we I wrote about it because sometimes we get, like, our community to come and test features. Mhmm. And we'll say, I'll give feedback, but actually, it's quite hard for people to know, oh, they'll just say, oh, it's great.

Paul Copplestone:

Yeah. But a friction log, for those who don't know, is basically you're you try out a feature and as you're trying it out, you just log every step that you're doing and especially the parts where you felt stuck. And so, yeah, whenever I'm saying to someone in the community, oh, can you test out a feature? Ideally, it's it's a feature a friction log that you can give to the team and then the team can kinda step through and see their thinking. And everyone who joins Supabase does a dogfooding project and they give a friction log as well.

Jack Bridger:

Yeah. That's some I think people should definitely check out because I think you've got like very quite detailed ways that people should give feedback and like examples and stuff. Yep. So it's very good resource. Another thing that going back to the article that Yeah.

Jack Bridger:

Guess this episode is about that article.

Paul Copplestone:

Cool.

Jack Bridger:

You also talked about, like, not killing your channels Yeah. Which I hadn't really heard before.

Paul Copplestone:

Yeah. Well, neither had I. So I kinda stole it from from well, I think I stole it from Duolingo who stole it from Groupon. So at this point, it's just a meme. But

Jack Bridger:

One of your cofounders previously was like a Groupon Yeah.

Paul Copplestone:

One of my yeah. In my first company, he worked at in Groupon Groupon China, actually. Yeah. And so I I heard it though through Duolingo. I I found the founder talking about it, I think, or or actually, yeah, the reason I found it was because, you know, to to to instill the culture in Supabase, we come up with a lot of principles.

Paul Copplestone:

And I wanted to figure out how to kind of give this idea that, especially to marketing, there's kind of this pull between, especially for a developer community, there's this pull between, like, let's market a lot and developers who hate being marketed to. And so, like, how do you, like, solve this tension? Like, I'm and I'm very much a developer, I don't like being marketed to at all. And so, yeah, what I found was the Duolingo talking about this, not from a developer point of view, but they shared the Groupon story. And the Groupon story was I don't know if anyone remembers Groupon now, but basically, you would sign up and you'd get a deal a day into your inbox.

Paul Copplestone:

And it was like the super cheap deal and you purchase it and then you'd check back the next day and it was kinda cool because you could either get the deal or not get the deal and then, you know, very easy decision. What started happening was, you know, the Groupon team said to the founder, oh, you know, like, this is going really well. If we do two emails a day, then surely, like, we'll get more business. And he was like, no. No.

Paul Copplestone:

No. No. No. We've gotta just keep it to one email a day. And they kept pestering him, and eventually he caved.

Paul Copplestone:

And they did two emails a day and you know what happened, it increased. And so they were like, oh, this is phenomenal. This is exactly what we said if we just, you know, we've kind of doubled our business. What if we do three emails a day? And they kept doing this until eventually they hit like six emails a day and at that point people got really fucked off and they they unsubscribed.

Paul Copplestone:

And that was their whole channel. Their channel was email. And once you kinda unsubscribe, you're not gonna get a person to come back and try the product. And so this became like rule number one for Groupon from the CEO is like, don't kill the channel. Mhmm.

Paul Copplestone:

And that tension that I talked about between developer and marketing is kind of the the the what I see as our channel. Our channel is our community and anything we do to, you know, build friction amongst the community is going to eventually kill Supabase essentially. So we've always gotta keep a focus on on the community and

Paul Copplestone:

make sure that they know that that's our priority. There's a few ways to do it, but, of course, like, marketing is just one of those ones where it's, you know, or dark patterns in the product, all of these things to make sure that you you avoid doing those things around the community so that they know you're building for them, not for your bank account.

Jack Bridger:

Yeah. So and I guess it'll be like, if it was like concrete example, like on social media, be like, I mean, you have a lot of followers, think. I feel like DevTools, I think it's over a 100,000.

Paul Copplestone:

Yeah.

Jack Bridger:

Right? If I guess if you were just like, you weren't posting like fun content, you would only ever posting like, I don't know, started to be like, it's Black Friday, Superbase day.

Paul Copplestone:

Yeah. Exactly.

Jack Bridger:

I don't know, just like constant like.

Paul Copplestone:

Yeah. I don't even know if we we kind of do a little bit of promotional Superbase on there, I guess. But actually, like, with our with our Superbase account, it's like a bunch of memes, and we generally promote build a culture, like develop a culture, that's kind of the thing that we care about and and really this is Ant that does a great job there. And, you know, he's instilled that within the within the team to make sure that, you know, they focus on that. Yeah.

Paul Copplestone:

It can be as little as like, you know, that that journey from from community all the way into enterprise as well. We know that as we grow, one of the founders has to focus on the developer community and we have to be the voice of the the, like, the developer because, you know, what ends up happening is you'll start like looking at features or feature requests and attaching maybe like a revenue, like how much will this one earn us? And you prioritize based on these type of things. And so what you need is someone to say, well, I don't care that this will cost, like, make us no revenue or cost us nothing or there's only one person asking for it. What I care about is generally the community and that has to come, think, from a founder much like the founder of Groupon, you know, probably should have put his foot down and say, well, I care about my users.

Paul Copplestone:

I don't want to to, you know, inundate their inbox, you know, so you need a someone with a kind of strong voice in the company to say this is what matters to us.

Jack Bridger:

Yeah. And I I think that's something that you guys have been good at in terms of like, you talked about like principles and I think like when you're asked about open source, I think like and people are talking about like strategy and business. I think like your first response that I've heard you say is usually just like we are like very principled in this and it's like, I I feel like maybe that's the only thing that could withstand like

Paul Copplestone:

Exactly. Yeah. Like open source, of course, everyone asked the question, you know, will you relicense? But, yeah, it's just that, like, our philosophy around DevTools is that they should be open sourced. That's just what we see should be the way of the world and more things should be open sourced ideally.

Paul Copplestone:

So, yeah, I get the question all the time from everyone from investors to community members, like, would we ever relicense? And it's just it's not even a question of, like, is it a good business practice? Are we worried? It's just that that's what we prefer. I would only wanna work in an open source company with open source developers.

Paul Copplestone:

Yeah.

Jack Bridger:

Yeah. Yeah. That yeah. It makes total sense. And I think it's very good to just, like you've just been, like, so clear and vocal on that and, like, had such a strong opinion because, like, someone's, like, burning the burning the boats a little bit.

Jack Bridger:

Like, you're just like, that's that's the direction.

Paul Copplestone:

Yeah. Yeah. And we kind of, like, lose a ton of business to people who wanna self host. That's the thing that people point out. But I actually like, those people, I'm happy that they're using Superbase, you know?

Paul Copplestone:

Like, I don't wanna tap into them. I I wanna make their developer experience great. If they wanna choose our hosted platform, great. That's good. Everyone's worried that, you know, AWS will, like, steal our product and, like, do Elastic or something like that, but I'm not so concerned about that because our whole thing is, like, a nice experience, the end to end integrated solution, and it'd feel completely different, you know.

Paul Copplestone:

So, yeah, it's one of these ones like you can't fork taste sort of thing. It's like the idea that, you know, we'll just build a great experience and if you wanna self host it, go for it. But ideally, the experience that we give you is so seamless that you choose us because it's just not worth your your time to self host it.

Jack Bridger:

Yeah. Yeah. Yeah. That that makes a lot of sense, I think. And kind of I want like kind of concrete question was like, I was doing contracting like a year or two ago.

Jack Bridger:

They use SuperVase. Actually before, it was funny like because I I was like using SuperVase on my own projects a lot at that time. But I it was already they already were using it. But the funny thing was it was like it was a really small team and like there was like quite start up y. But they were part of this like public.

Jack Bridger:

It was a it was a public company basically.

Paul Copplestone:

Mhmm.

Jack Bridger:

And how do you think about like this kind of like adoption and kind of how you go from like this kind of, you know, there's like use cases in like this team to then go like, okay, how do we get like everyone in the organization using Superbase?

Paul Copplestone:

Like an enterprise? Yeah. Yeah. Yeah. Everyone within an enterprise.

Paul Copplestone:

Yeah. The way we're thinking about it at the moment is more, like, the good thing about having kind of 3,000,000 developers using your platform is that you've got champions in every company. Yeah. Yeah. They're a little bit like your community, as well.

Paul Copplestone:

And generally they want to bring in the product to the org and a lot of it's just kind of enabling them and like helping them to show that super bases is great. So it can be things like we could run a hackathon internally, you know, brown bag sessions, things like this within

Jack Bridger:

What's a brown bag session?

Paul Copplestone:

Just where, like, they come in, like, with their lunch bag and they listen as you do a presentation.

Jack Bridger:

Yeah. Yeah. Yeah.

Paul Copplestone:

Don't know why it's called, but, like, I guess you put your lunch in a brown bag and then

Jack Bridger:

The UK, they call it, like, lunch and learn.

Paul Copplestone:

Ah, okay. Yeah.

Jack Bridger:

I think it's, sounds like it's basically the same thing.

Paul Copplestone:

Yeah. Yeah. Exactly. Yeah. Yeah.

Paul Copplestone:

Like, low friction stuff to to make sure people know about it within the enterprise. And then, of course, like, with it, if it's like really an enterprise, you need a bit more of a, like, pincer motion, which is like bottom up and top down because probably the these are all kind of sales things, but like the decision maker, the economic buyer, all of these type of profiles are different. And so, you know, when you're dealing with SMBs, they're all on the same call. Whereas when it's like a much bigger enterprise, then you kind of need to know all of those people and they should know about super base before Mhmm. Before they even get to a point of deciding that whether it's good or not.

Jack Bridger:

Yeah. Yeah. Yeah. Yeah. That makes sense.

Jack Bridger:

I think, like, sort of coming towards the end. Last thing I wanted to ask you is, like, what stuff you're excited about at the moment?

Paul Copplestone:

Yeah. We've got a I don't know when this when's this podcast going.

Jack Bridger:

We could try and get it out. Do you wanna come out, bring it out sooner or

Paul Copplestone:

all that? Well, yeah. If it comes out in the next week Okay. Then then we have a launch week from July 14, which will will drop five major features and they're pretty cool, some of the features. I'm also super excited about a new one that we announced, which is Multigress.

Paul Copplestone:

So

Jack Bridger:

Very cool name.

Paul Copplestone:

Yes. It's cool. Right? I talked to a customer actually, a big customer, and they were like, oh, that's such a shit name. Like, you should, like, think about renaming that.

Jack Bridger:

And I was like, oh, no. Not a Marvel fan, I guess.

Paul Copplestone:

Yeah. Well, exactly. That's the idea that it gets across. Also, funnily enough, on the.com and everything was available. So I was like, yeah.

Paul Copplestone:

Yeah. So there's no way we're changing the name. No. But Multigress is cool. It's basically the creator of Vitesse, which is a tool that was developed in YouTube.

Paul Copplestone:

Yeah. He as they started scaling the it was MySQL in YouTube. Yeah. And so as they started scaling up, they had to build this tool that would help them to scale, and they added a lot of sharding and, you know, the high availability tooling. And so the creator of that eventually spun out and created a business around it, and then he wanted to do it for Postgres, and he came to us a couple of weeks ago and just said, oh, I'd love to do this at Superbase.

Paul Copplestone:

And so we'll essentially be building out the kind of the test for Postgres offering That's huge. Over the next year. And we'll add that to the platform, which would be pretty cool.

Jack Bridger:

Wow. And I guess that's gonna help a lot with the enterprise stuff as

Paul Copplestone:

well. Yeah. And our existing customers as well, not just, you know, enterprise, actually. We've got a lot of AI companies who are scaling up, and they might even be manually sharding themselves. Mhmm.

Paul Copplestone:

So this kinda makes it a bit more seamless and, yeah, makes it really easy. And, of course, it'll all be open source if people wanna self host it as well. So that's always how I was saying. Yeah.

Jack Bridger:

Yeah. Super cool. Do you think you would have I don't know why, like, I thought one of the interviews, you were talking about how, like, the name Superbase back in the day.

Paul Copplestone:

Oh, yeah.

Jack Bridger:

And you were like, oh, so cringe whatever it was like. Yeah. With the Nicki Minaj meme.

Paul Copplestone:

Yeah. Exactly. I actually yeah. I really dislike the the name Supabase. The one benefit of Supabase because it's like s u p a b e.

Paul Copplestone:

Yeah. But, you know, it's there's no other mentions on the Internet other than our company. So anytime I get a ping on Superbase, I can read it and I know it's about us.

Jack Bridger:

So is this really like an ant? Is this like an ant fig?

Paul Copplestone:

The Multicres or the

Jack Bridger:

The Superbase.

Paul Copplestone:

The Superbase? No. No. Like, we came up with it, like, as a bit of a joke. But Yeah.

Paul Copplestone:

You know, it went too far too fast. So we couldn't we couldn't rename it. To me,

Jack Bridger:

you would have named

Paul Copplestone:

it multigress if Well, no. Multigresses make sense because, like, the idea of this particular tool

Jack Bridger:

Yeah.

Paul Copplestone:

Is that you end up running, like, a limitless number of nodes at one time. So it's kind of like, that one makes sense. But, you know, I I didn't think at the start that we'd actually build out. I knew we'd have to build out a lot of the scalability options. And, actually, we kinda have many tongs in the fire for this one.

Paul Copplestone:

We have as well Oriole DB, which is kinda replaces the storage engine for for Postgres, and that's one way of solving the kind of scalability requirements for enterprise. And it also is much faster. It's about five times faster than the default storage engine. We also are working on, like, an iceberg initiative. So with the s three team actually at AWS, where we essentially can, like, seamlessly offload data between the database and s three and in this format called Iceberg.

Paul Copplestone:

And you can kinda put, well, an infinite amount of data inside Iceberg as well. It's a columnar storage. Mhmm. And then this third one is is Multigress, which allows you to run this limitless number of nodes. And so in many ways, we're just kind of being opinionated about being unopinionated about choosing your journey on how you want to operate your data.

Paul Copplestone:

And we'll try and make that whole experience seamless like we have it, you know, for for the first five years. And so now, like, my product focus is largely around these three areas of growth.

Jack Bridger:

Yeah. That's not very cool. It's like the building weekend scale to millions, like, or billions. Don't know if

Paul Copplestone:

you Yeah. Hopefully, it'll be billions soon. Like, we actually once put billions, but I don't know if we've got anyone in our, like, we've got an auth product. And so we know people who have, like, sign ups, but we don't yet have anyone running an app with a billion customers.

Jack Bridger:

There's probably not that many, are there?

Paul Copplestone:

Like don't know many.

Jack Bridger:

Less than a 100.

Paul Copplestone:

Yeah. So so we actually put billions and then we thought, no. That's too too much. Let's make it millions. And then on the day that we actually can scale to a billion users or we have an app that has a billion Yeah.

Paul Copplestone:

We'll change it to scale to billions.

Jack Bridger:

Like, you can some big Yeah.

Paul Copplestone:

Like video

Jack Bridger:

of you like changing

Paul Copplestone:

Yeah. From m to b.

Jack Bridger:

Yeah. Very cool. Okay. I think that's towards the end. So Paul, thank you so much.

Jack Bridger:

I've wanted to interview you for ages. I've kind of been like talking to you for years and following Superbase and using Superbase. So thank you so much for coming on.

Paul Copplestone:

Well, thanks for being in the community for so long and glad we could do this in person.

Jack Bridger:

Amazing.