¶ - Intro
Who says no to a million dollar contract, especially when you're getting started?
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.
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.
How did Supabase earn the trust of over 3,000,000 developers?
This became like rule number one, don't kill the channel. You trade cash for culture, basically.
Enjoy the episode.
¶ - Scaling company culture
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?
So and I guess you're choosing external people.
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.
Yeah. That makes sense.
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.
Yeah. You're not getting that drift around, like, people that are, like, very far from, like
Yeah.
Devs and open source and stuff as well.
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?
Yeah. And you've I think you've talked about this like writing. Is that the main mechanism that you
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.
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.
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
Yeah.
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.
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
Mhmm.
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?
Yeah.
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.
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. So
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.
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.
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.
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.
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.
And Mhmm.
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.
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.
¶ - The enterprise dilemma
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.
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.
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.
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.
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.
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.
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%.
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.
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.
¶ - The "enshittification" of DevTools
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.
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.
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.
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.
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.
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.
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.
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.
¶ - Configuration over customization
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
¶ - Guiding new developers
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? Yeah. Must be like quite challenging like developer experience to
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.
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.
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.
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.
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.
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.
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. 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.
Yeah. I think you have, like, some kind of, like you're about to do it destructive.
Destructive. Yeah. Rollbacks. Yeah. Yeah. Yeah. Lots of things really.
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
Why Friction Months? Thing. They're not actually as big as yeah. As
Okay. Made it big.
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.
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.
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. Guess this episode is about that article.
Cool.
¶ - Don't kill the channel!
You also talked about, like, not killing your channels Yeah. Which I hadn't really heard before.
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
One of your cofounders previously was like a Groupon Yeah.
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.
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.
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.
No. No. No. We've gotta just keep it to one email a day. And they kept pestering him, and eventually he caved. 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.
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.
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
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.
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.
Yeah.
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.
Yeah. Exactly.
I don't know, just like constant like.
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.
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.
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.
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
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.
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. Yeah.
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. Like, you're just like, that's that's the direction.
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?
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.
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.
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.
¶ - Enterprise Adoption
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. It was a it was a public company basically.
Mhmm.
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?
Like an enterprise? Yeah. Yeah. Yeah. Everyone within an enterprise. 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.
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
What's a brown bag session?
Just where, like, they come in, like, with their lunch bag and they listen as you do a presentation.
Yeah. Yeah. Yeah.
Don't know why it's called, but, like, I guess you put your lunch in a brown bag and then
The UK, they call it, like, lunch and learn.
Ah, okay. Yeah.
I think it's, sounds like it's basically the same thing.
Yeah. Yeah. Exactly. Yeah. Yeah.
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.
Yeah. Yeah. Yeah. Yeah. That makes sense. 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?
¶ - What's next for Supabase
Yeah. We've got a I don't know when this when's this podcast going.
We could try and get it out. Do you wanna come out, bring it out sooner or
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. So
Very cool name.
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.
And I was like, oh, no. Not a Marvel fan, I guess.
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. 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.
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.
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.
Wow. And I guess that's gonna help a lot with the enterprise stuff as
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. 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.
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.
Oh, yeah.
And you were like, oh, so cringe whatever it was like. Yeah. With the Nicki Minaj meme.
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. 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.
So is this really like an ant? Is this like an ant fig?
The Multicres or the
The Superbase.
The Superbase? No. No. Like, we came up with it, like, as a bit of a joke. But Yeah. You know, it went too far too fast. So we couldn't we couldn't rename it. To me,
you would have named
it multigress if Well, no. Multigresses make sense because, like, the idea of this particular tool
Yeah.
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.
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.
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.
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.
Yeah. That's not very cool. It's like the building weekend scale to millions, like, or billions. Don't know if
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.
There's probably not that many, are there?
Like don't know many.
Less than a 100.
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. We'll change it to scale to billions.
Like, you can some big Yeah.
Like video
of you like changing
Yeah. From m to b.
Yeah. Very cool. Okay. I think that's towards the end. So Paul, thank you so much. 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.
Well, thanks for being in the community for so long and glad we could do this in person.
Amazing.