Latent Space: The AI Engineer Podcast - Supabase’s Plan for a Billion AI-Built Apps

Episode Date: October 26, 2026

AI agents are creating more software—and that changes what a backend needs to do. Supabase co-founders Paul Copplestone and Ant Wilson join swyx to discuss running long-lived workloads alongside the database, making schemas easier for agents to underst...

Okay, this podcast has been six years in the making. We're excited to have a couple and ants in the studio. Welcome, guys. Thanks. Thanks for having us. We're recording this ahead of Superbray Select, which, you know, it's your big customer conference, and we'll release this after the conference.

But I just want to sort of celebrate the journey that you guys have been on. I've seen you guys since you guys finished YC, and you were like in that place in Singapore where you were sort of celebrating. things. And I, you know, I met you guys for the first time. And I was like, what is this, like, hot database company that, like, got soft launch on Hacker News by, like, you know, some random user or sometime? Anyway, congrats on all the success. What are you announcing the headlines at Select? Let's just get right into that. Yeah, yeah, sure. So there's quite a few headlines. We've got a lot to cover. The main ones would be starting off with compute. So we offer

a product called edge functions, and edge functions are powered by Dino, and they have basically a two-second limit. What we're finding is that, well, what we've heard from our community for a long time is that they want to run much longer workloads. They want to do things like chunking embedding. So tomorrow we're announcing, and by the time this comes out, super-based compute, which is you can run anything. It's long-running.

It's serverless. It is running in the same private network as your database, so it's co-located, has very good latency, so you can run Postgres connections directly from compute. And you can run anything inside it, so it's no longer constrained to just Dino. You can use it with Rust or Python. You can

run agents inside it. It's basically just a full compute instance. Let's call it the comparable offerings in other clouds that others might be familiar with. Would this be... Yeah, something like a Lambda function, but the container type lambda function.

Okay. You can run a full container, basically. And then there's the other stuff. Yeah. And then we have, well, three innovations on the database space. So the first one, which we talked about last year, which was OriolDB. Orion DB, we've basically put it through the ringer in the past year to make sure that it is rock solid and ready for the Postgres ecosystem. The three innovations are basically performance, scaling up, and scaling out. Postgres touches on, sorry, OrionDB touches on performance. It is a drop-in, replacement for the current Postgres storage engine, which is heap, and it runs about 1.5 to two times faster, and you don't have to change anything else. It's just completely compatible.

It completely removes the need for some of these background tasks, like vacuum and bloat. So it's actually very efficient for your database as well. And basically the innovation that all the work that we had to do this year was put it through PG regress, full compatibility with Postgres, antithesis, we put it through TPCC nightly benchmarks and Jepsen to make sure that it basically can never lose data. So we're releasing it tomorrow in full beta, and we also made it Apache 2 license. It comes with a patent and the Apache 2 license covers the patent. So we actually acquired the technology, continue to develop it, and then we pay for the patent and are now giving it away for free. One thing that you mentioned in passing, which I still don't, I can't

get over is that you tested every operator and you said every operator drops data in some situation. Well, so this is for the second one. So scaling up. That's multi-grass. Yes. So multi-grass is the second big announcement. Basically, we looked at the Postgres ecosystem and we looked at all the operators. An operator, for those who aren't familiar, when you run Postgres, you start with a single node, but then with almost any database, you want to run multiple nodes and you want things like failover, you want it to manage backups. So usually you have this thing called an operator, which can run the entire cluster for you. So there's quite a few operators in the Postgres ecosystem,

and what we had found was that under certain conditions, every single one of them could lose data. And so we decided with Multigrass to do a ground-up rewrite of the entire structure of an operator. And so Multigrass is essentially, while our initial goal is to give sharding to the Postgrass community, what has turned out to be is this entire operating system. And we actually ran it again through very rigorous testing,

and we've done 1,000 sequential failovers, and it didn't lose any data, and we've tested it in basically every way we can clobbering it to see whether it will ever lose data. So we're very confident now in its stability, and so we're releasing that one as well. Tomorrow is completely open source. It will be on our platform for customers and invite only,

so people who are running serious workloads can come to us, and we'll start helping them to see. scale up. Is this the full completion of multi-grass being fully sort of parallel to Vitesse, or is there still something left to go? No, actually, yeah, it was quite interesting. So Suku originally created Vitesse in, for the MySQL ecosystem, but specifically for sharding. And actually when he came along, he said, well, the number one goal that we want to do for this time, because we're always catching up on compatibility when we use Vitesse, you always had to change things as you move to shard it.

So change some queries. So he said, I want to focus only on compatibility first. And so the way we've designed it is in such a way, this ground up rewrite, is specifically so that we know when we release sharding, you actually won't have to change anything. For your database, you'll continue to run the same queries, and multirass will just be able to handle it, zero changes to your code. I mean, that's incredible vision and the fact that you've been able to do it in two years? That's one year.

So we haven't really sharding yet. I've seen the early prototypes and the designs for how we're doing it, and some of it should land by probably early next year, depending on some of the things that are happening on our platform. We've got a lot going on, but we're very confident, and we're happy with the progress. It's been pretty good. Yeah.

I mean, I think this is the last piece for the total domination of Postgres. Yeah. Right? Yeah, that's it. And for those who don't know, look up the tests, powers YouTube, powers what else, GitHub, everything. Yeah. If workloads were ever to shift away from MySQL, you need this to Postgres. And that's then for Superbase to win.

And hopefully it's not just for Superbase customers, right? Like it's fully open source. Community things. It's anyone who's running Postgres at scale should be able to use Multigrass. Yeah, I'm sure like every coalition, every company that's involved in Postgres in some way is contributing to this thing, right? Because we all want this. Yeah. Yeah, we've got a whole design partner program, so we're working with the likes of Booz Allen, we're working with Postman, we're working with perplexity.

So, yeah, lots of customers coming on board that a lot of people need it. They're running Postgres at scale, and they need something to help them scale up. Yeah, third. Third one is, yeah, so this one's a big one, scale out. At the moment, we launch about 5 million databases on our platform every single month, and kind of the future where we need. know we're going, we think that we're going to have to launch billions per month. And so scaling out is a whole different beast. So we decided that we would have to look at some new architectures and people within the space, the agenic database space. And there's no other

leading database provider who does agendic well than TIRSO. And so actually tomorrow and when this is announced, it would have come out where we have announced that we've acquired to us power agenic databases. Yeah. That's an incredible... It's also... There's primarily SQLite base, but it doesn't really matter, right?

Like, it's more about the architecture of, like, I guess... I don't have the word to describe how, basically, like, broadcasts. Is that the word? For... For scale out, right? Like, there's... The idea for them scaling SQLite was that they would have, like, a single writer and, like, multiple readers.

Yeah, so... So SQLite itself, it's only a single writer. It's a file format. So generally it's not... Like sort of an MVCC for SQLLIT. Exactly, exactly. So then they built this terso architecture, which basically builds MVCC for SQLite

so that you can have multiple writers. Yes. And because SQLite has a weird license, they had to fork it? They had to fork it. They originally started with LiveSQL, and then they came along and they did this other really cool architecture. And actually now the architecture, Actually, it was very commonly discussed a few weeks ago, Wallon S3.

So some of the innovations in the database space are actually coming out of what's happening in object storage. So object storage has added a bunch of new features, which basically mean that you can start using it a little bit like a database. And because object storage itself is, I think it's 11-9s of data durability. Yes, which is not reliability, but whatever. Yeah, not reliability. but it gives you what you need for basically what you would typically have for a cluster of databases. It's kind of like your cluster underneath. So you can start doing some cool things like, yeah, there's quite a few popular databases now

or data use cases that are building directly on top of object storage. It's got some limitations in our worldview. It's probably good for these smaller use cases in terms of transactions. Because when you've got a transactional database, you've got to do it. a lot of reads and writes. And so in this case, you probably don't want to be doing something at massive scale on this, and that's why we have multigress. But for these, what we're seeing, where we need to get to, these billions of databases, what we need them to be is a file format. And so that's where SQLite was super interesting. It's dominating. And actually, the thing that

really piqued our interest, and I reached out to Glover, I said, he released a blog post on how they're done their rewrite basically makes that we have a pathway to get Postgres compatibility with their file format. So we're acquiring them and we're actually going to keep the Terso brand. So Terso is going to focus on

SQLite and then we're going to introduce this new, smaller instance type on Superbase called SuperBase Spark and it will be compatible with all our libraries and you can have one database for any idea, any prototype that you want and when it takes off, then you just upgrade

to form Postgres databases all the way up to Multigress. I know you've been working on this for a while. This is the dream, right? Yeah, yeah. Both scaling up and scaling down has been one of the things that we've been trying to figure out how to do.

Yeah. And it's really when some of these innovations came along that we realized, oh, okay, we can do this. You know, you're going to $5 million a month. Let's say you see on the trajectory of billions per month. One of the secrets is they're actually kind of small databases.

Yeah. Right? Like these things are tiny. They're vibe-coded app. I don't know if you have any insights on the work. Yeah, I mean, until they get traction, right? And that's the thing is, like, once you hit the front page of hack and use, you need to know that you can go far beyond that.

And so the whole idea with all of this was we need to make sure we've got a really smooth pathway to migrate between the back ends, like zero downtime migrations. It's just like a need to have. Because, like, we see now that there's a lot of non-technical builders who are building, like, whole companies, right? We have a customer magic school, and the guy was, like, a teacher, right? And he saw all these, like, inefficiencies in teaching,

like, teachers spending time on tasks that could be automated. And so now you have these startups that start without a technical co-founder, without a CTO. And that's not, like, isolated incidents anymore. That's, like, becoming more. Everyone. Everyone's a builder now. And that's why we see, like, the,

growth we've seen over the last 18 months is crazy. Yeah, but it still feels like early. And I think there's a much larger market of almost like consumer-like builders, right? It's people inside companies, people who want to launch their own startups, which has gone to mean a lot more databases, which like we said, like if we give everyone a dedicated Postgres cluster, it's probably, you know, we'll probably run out of physical computers. in the world pretty fast. Which is basically what's happening.

Like we've faced it throughout this year. We're just, our growth has been one of the things that we've had to deal with in terms of capacity of computing. Yeah. So congrats. Also, I will observe that I feel like Glauber is also a meme lord. Yeah, well, that's one of the things. Right? I mean, like, come on.

Yeah, he's amazing. So for those who don't know, the person behind this Rube Base memes is this guy. Yeah. You know, low-key a killer, I would say. And we're Glober also. Yeah, yeah, yeah, big time.

I don't know if you guys exchange notes on like what's funny. Not yes. Really? That never came up? We're going to give them access to the Superbase Twitter account for sure. I could do with some help. Yeah, yeah. Wait, is it still you?

We've got a small team of teenagers now who help me out. You do workshops, right? Yeah, but we do a weekly workshop. I mean, basically weekly. meme workshop, but it's hard to hire for because you need to understand the tech and understand what developers find funny, basically, in order to do that type of marketing, right? Yeah. Actually, you are also low-key, like, meme lord.

I'm not as funny as you. You're really, really funny. There was one with like a seagull and you were standing on top of a turtle. Standing on top of Postgres, I think it was. Yeah, it's like a stigull. standing seagull riding a flying seagull and it's like god super i can't i can't find you right now and this is all like deep super base history but like you know there there was a time when like those things were just like it was so good people wanted to be like you and they couldn't and that was your moat memes yeah there was some big companies trying to run memes off their twitter

accounts i won't name any names but like very large organizations um but yeah it's it's it's Like I said, it's hard to hire for. The guy who did like a 40,000 word essay on breaking down our meme strategy. Someone studied our Twitter strategy actually really early on and posted it on Hacker News. Yeah, on Hacking News. And that was funny because they recorded the strategy in a way that we hadn't committed to paper yet. So then when we're on board a new marketing people, we were like, here's the strategy. They was written by someone else.

And of course, Hacken News hated it. And then they were commenting on it. it and I found it I found it I took the the first comment this guy

this guy yeah yeah learnings from four months of super base feed he just looked at your work

was it 2022 okay yeah yeah wait I mentioned it ooh there you are

so he just broke it down he broke it down and then hack and news hated it on it and so

and took a photo of them shedding on it and posted it on our Twitter again your hate just fuels me

what is this interesting article yeah okay so I commented yeah That was like a lot of our gross is thanks to Haken News. I mean, in the early days, I just live on there.

So we should talk about that. What deal with the devil do you have to do with Dang? Oh, man. We've been scolded by Danji, like, many times, for launching too many things in a week, basically. And he's, like, rightfully paranoid about the association of Hacken News and YC. So he kind of, like, if something happens, he kind of wants to throw us under the bus

so that people know we're not doing this for YC customers, we're an independent side. So he's been helpful to make sure that we don't smear the name of YC or hack and use. I mean, at this point you don't need them. But like for sure

I think Dang does a, Deng has super high credibility. No one really questions him. But I do think like, you know, you guys innovated the strategy of launch weeks and for a while, I think there was one of the launch weeks, I think four or five, where every single launch was like number one or page one on Hacker News. I got told off so badly for that because I tweeted that proudly.

I was like, oh, here we are. And then I got told off because we were like, it basically looks bad because, like, suddenly this YC company is like dominating the front page of HAC News. It looks like it's a biased thing. And like parading the fact that you're on the front. Yeah, yeah, yeah. Which is true. So like tip to anyone, never screenshot the fact that you're on the front page of hack news and put it on Twitter because it does look like, and to be honest, it was gloating.

So it's a fair call out. Yeah. Yeah. There's all that which like I would say, I was considered that somewhat ancient history now. You know, it's been a few years since this is a relevant thing. But for those who don't know super base history, these are the things that you must check off as like the tour of things. What else? I mean, I think the top poster is interesting.

because this is the launch post. Yeah, but it was someone else who launched those. We weren't ready. We weren't ready to be launched on Hacking He was. And you didn't consider yourself a Firebase alternative. Oh, yeah, so that was the day that we changed the tagline. We had the tagline. It was real-time Postgres because what had happened was I wanted, like, we were like,

oh, let's build a Postgres company. But in my previous company, I had to migrate from Firebase to Postgres, but I needed a real-time feature. And so I ended up building this real-time engine on. top of Postgres. And so we thought, oh, that's the killer thing. Like, it's getting some open source traction, this real-time engine, it's kind of cool. So we were like, oh, real-time Postgres. No one cared. No one cared when we had a website. And so, like, we're like, let's change it to open-source Firebase alternative, knowing that that was the reason why I switched. And it was,

I think, only 12 hours later or something like that. This article went up. Yeah. Still the top of all time. And at the time, we was running on top of DigitalOcean. And every news, you database was two droplets, so $2.5 a month droplets. Way two? One for the database and one for the APIs. Right. Because we wanted to upgrade the APIs and decouple. And we only had a handful of like test users at that point.

And then all of a sudden... I think we only had eight users. Yeah. We went from eight to 800 on that launch alone. And then we burned through, I think we had like 10K of digital ocean credits, which we just burned through in basically 48 hours. And then we just got into YC. So AWS was like, oh, we'll give you, you know,

whatever it was, 150,000 credits if you migrate to us. And so we spent the first week of being in YC migrating 800 databases to a different cloud, which, you know, if you've ever migrated one database, you know how painful it is. It's like migrating 800 is not how you want to spend your first week in YRC. Do you remember that we could have been on digital?

Like basically, We should still be building on DigitalOcean, because when you get into YC, they have this credits program, like huge number of credits on DigitalOcean at the time. And we're like, hey, can we have these credits because we're like, we're blowing up here? And they said, oh, no, you've already used the $10,000 credit program.

We can't give you this other one for $300,000. So we're like, well, we have to migrate to AWS. And so the biggest lost opportunity of DigitalOcean. Being too strict, yeah. I know our bills with AWS now. This is like probably one of their biggest, customers ever that they lost from being too strict about that. Because it was COVID, it was a time when everyone was worried about like what's going to happen. So I think they were like, we don't want to

overextend ourselves. It's fair. Yeah. So it was like totally fair at the time just given the way the world was looking. People made many irrational decisions during COVID. Yeah. But you never know. I was still going to say you might be worth more in a digital ocean now. But then somehow digital ocean has also like gone on a super tear. Look at this. Because computers. They tripled in the last year. Wow, that's cool. So what are they?

They're 16 billion now. Billion, yeah. Okay. And like, okay, well, I guess there's a shortage of CPUs. Yeah, there's a shortage. How are you guys experiencing it? We literally, I mean, we're up against runways all the time where, like, we meet AWS, like, multiple times.

Is there a way to spike when you have a spike? What do you do? Like, you just have agreements with people to... Yeah, we've got to, like, plan very closely. We pay more. more, we partner with them. And in fact, tomorrow as well, we're announcing that we're bringing on a new investment partner, which is capital G, capital G, capital G, basically has access to the alphabet ecosystem. Good for us on both sides. Like, we now have to consider a multi-cloud strategy.

We need GCP. We need GCP, or we need more compute, basically. So GCP is a very obvious choice. And of course, we want to partner with all the AI labs as much as possible. And so they have a suite of products. We work with them already on Gemini, and we want to make sure that we're embedded deeply into all of their products. And that's another thing where you're mentioning how so much of the database ecosystem is being shaped by block storage and all these innovations and all these things. Clearly, AWS is the leader there. It's hard to be multi-cloud if you're going to use GCS as like a swap for S3.

Yes, as long as they've got the features. Actually, I don't know if their object storage has all the features, but I'm sure that whatever S3 do, others follow. I still remember, I think like three years ago, they introduce strong consistency. Yeah, that's the innovation, basically, that helps. And they just, like, they did it for free, and they just rolled it out to everybody.

And it's like, it's live now. What? And then S3 Express as well, that was a big game genre. Why? Well, basically now, what you want to do is, like, you typically write to a local drive, and then you need to batch it to something more durable, and that batching process.

And so the right times to this are one to two milliseconds. And so before you can guarantee a right back to your client, you basically need to batch it to something that's durable. So this one's durable, not as durable as S3, not 11-9s, but durable enough that you can... It's ephemeral durable. Yes, exactly. And then in the background, you use this kind of as your cache,

and then you move into S3 in the background, which is cheaper. Do you need Redis anymore? Yes, yeah, you still need Redis. Like, this is nowhere near fast enough. You need, like, basically, your cash layers are either memory, MVME drive, local attached to S3, their equivalent, and then S3. Yeah, normal. Amazing. That was a little bit of data.

Like, we jumped around quite a lot. Clearbase and memory. A few more things that we're going to talk about. Your slogan was building a weekend, skill to millions. Now we're prototype to petabyte, which is excellent. And really, it is reflective of the evolution. in scale that you guys are doing, right? Yeah.

Do you have anecdotes on, like, let's say, early super base versus now? How fast are people scaling when they start a thing? Yeah, well, the big thing is, I think, how fast people are monetizing. Oh, yeah. At the start, it was like you choose your database, you build your product, at some point you add in billing now because you can add in stripe, like, at the agentic layer. It's like we see customers start on a project, and within the same week, like generating serious cash.

And in the early days of vibe coding, it wasn't obvious to us that this is something that's going to stick around, this is going to change the way software is built. But as soon as we saw someone earn and like, I think it was $10,000 within the first few days of launching their product, we were like, wow, this is real.

People are making real things that generate real money. So we knew we had to lean in. In a way where there was waves, we'd ridden successfully in the past. Like when NFTs were huge, we leaned in a bay and we added like signing with Ethereum and signing with Solana.

But we didn't dedicate like tons of dev time because everyone kind of knew it was going to go away at some point. And making that decision for vibe coding was like, you know, we discussed it a lot as a team of how much do we lean in. And it was a time when we knew we needed to go slightly more upmarkers.

It's like our biggest customers were like stretching the limits of what we had at the time. And so we knew we had to then just do both. It was like, you know, innovate on the small like prototype stuff and innovate on the much larger side as well. And then you just need more people for that. That one's funny because like on the number side, basically for Superbase there's been three chapters of AI. So the first chapter was embeddings. I think we're on. So Base vector.

Yeah. Which I have now transcribed, and it will always, we should probably update this because this is the only talk you've ever done it, yeah. Yeah. We did this talk. Basically, all these embedding databases were coming out, vector databases, great, the vector. And so we were pushing the fact, and you can use Postgres as a vector database. And Andrew Kane, a completely independent guy, has developed this awesome extension.

And we're like, okay, trying to educate the market, Postgres can kind of do anything. You don't need another database if you're going to store your embeddings. So this was Chapter 1, and it was really a good growth driver for us, and also good for the Postgres ecosystem, just letting people know. Now there's a lot of innovations in embeddings, what Turbo puffer, for example, are doing. They use a lot of the innovations that Tursa are doing, and I think it's a phenomenal use case for that type of stuff. So that was Chapter 1.

Chapter 2 was like the vibe coding wave, whereas lovable, bold, all of these ones coming along. That was end of 2024, and that's where we did. debated a lot. Hey, do we really want to be there? Do we want to be servicing these? Do we even want to have our own vibe coding type platform on top of Superbase? But in the end, our mission is store the world's data. And to do that, based on our tagline, it's like, be there when you're getting started, make sure that they never want to leave. And so we saw people were getting started. They were doing toy things, but still, it fit our mission. We just had to believe that over time these tools would become better. And then the third one, which is the like crazy news,

numbers, started this year, the models just got better, basically. And then we started seeing our top of funnel, our sign up rate, start rapidly increasing. But usually when this happens, you're pouring a lot of dollars into marketing. We actually barely spend any dollars on marketing. And most of it's just memes and things like that. So, um, so. Here, I got one of your charts. There we go. Yeah. I mean, all your trials look the same, but because they're just like, exponentially You just keep changing the YX. The other crazy thing about this is often when you get more consumer-like traffic and the top of funnel, your activation and conversion to pay goes down.

But both of those things went up. Started going up quite rapidly as well. Yeah. Because of the models. How do you know activation and conversion to pay? Oh, your super basis. Our metrics, yeah. Our metrics.

Okay. And the reason is because the sign up to activation, the agent does it for you, like in one step. So it's basically, it's almost 100% for that cohort. And so those users then were converting to pay that are higher rate than our traditional developer user. Okay. I mean, excellent. Great.

Yeah. Yeah. But I'm sure, I'm sure, like, all developer tools are seeing the same thing, right? Well, at different rates. I think you guys are clearly one of the leaders there. You know, I was going to bring out this one of these things. I have this AEO tracker where, you know, if you type in, super base and there's a there's a few categories where you're the leader but basically it has led to

every single frontier model recommending you as your primary choice for an integrated back end what does integrated backend mean it is your original offerings like you're off your functions your you know and your database and all the other stuff APIs and I think it is interesting like you had to be in the market for three to four years exactly your time zone before LLMs took off and then present yourself as the leading competitor to the leading thing at the time. Yeah. And then you can take over. Yeah.

Yeah. We're very lucky without timing. I mean, we couldn't have time to better, like this complete accident. Well, I mean, I think like on first principles basis, so we have interviewed other founders who maybe started post-LLLM's and Resend was kind of there. We've also talked to them. Like, why does my LLM keep recommending rescind? And it's because they have a lot of good AEO practices.

Sure, yeah. And of course, we invest very heavily on that. But, you know, when we've been at that point since the start, and there was an accident, right? So now we just need to maintain that lead. And the community as well, right? Like one of our growth strategies early was just spending so much time with the community. And it was also then they were writing blog posts. They were making YouTube videos.

They were putting our podcasts all about how to use Superbase. In what situations? Like, here's how I built this thing. I'm sure that all just got slurped up by the model. And open source helps as well, of course. Yeah, yeah, yeah, definitely. You actually had a fun announcement on the community side because you're raising so much

and you're trying to involve your community in more deeply. Yeah, so last year at Superbase Select, we announced that we were going to do a crowdfunding round. It's something we've always wanted to do. We should have done it much earlier on, but we just, you know, had so many other things going on. And basically then we spent the last year

fighting with the lawyers who are saying, you know, for the number of people we want to be involved, there is no mechanism to do it without people being accredited investors until we asked them the question, well, what if they don't invest? What if we just give them the stock?

And they were like, yeah, we'll look into it. And then they came back and they were like, actually there is a mechanism where if you really just want to give the stock away, you can. And so now we've earmarked like a million dollars in super-based stock that we're basically going to give to a bunch of the community members the first community member

were going to stand up on stage and sort of announcers is this guy, his name's Gary Austin in the Superbase Discord and this guy is like a legend of the Superbase community we looked into his stats

and Gary has answered 20,000 in the last six years 20,000 questions in the Super Base Discord and the crazy thing is 13,000 of them he answered within the first

hour of them being asked and he's not a grok boss like he's a real humor have you met him what is he's real we've met him he was basically like retired

yeah and just interested in Superbase Gary Austin Gary Abbott yeah Gary Abbott is his real name okay this guy yeah and he

loved Superbase because he basically built his own semilia app because he loves red wine and then was just getting a kickouts

of you know he's got Superbase logo on his Christmas tree. And he's also... By the way, this is my favorite Superbase memes. It's just like you're reminding me that like, yeah, I'm about to run out of my Superbase. That's the announcement is where basically like anyone who's a legend in the Superbase ecosystem we can now. Is Discord still a strong...

I mean, I got mixed experience with Discord. It is the best chat, you know, Slack sucks. But also it is not public, right? So all the work in there is not scalable. Have you found anything to solve that? There was some tools that we looked at in the early days. We decided not to do it because you still needed to police what things you wanted to be public and what things you didn't.

But the original debate that I remember we debated a lot was, okay, we want to host the community. Do we do a Discord? Do we do a Slack community? Do we do a Reddit? And we tried a few different options, but we landed on this thing of like, Discord users are going to use Discord.

Reddit users are going to use Reddit and we basically had to do all of the above. Just be where they are. That's the answer. There's a lot of work. Yeah. And it worked down, right? I mean, there was the right answer.

But then there's a lot of, like, great tools that started popping up, right? I don't think anyone has stood the test of time, let's call it. No. But yeah, there are tools that are Discord mirror to public Q&A site. That is a thing that people do. I don't know if it's been successful for anyone. Yeah. And like common room helped a lot.

Actually, the only thing that we did was for ourselves. So basically anyone who had asked a legitimate question on any one of these, we then would basically scrape the question and the response into our own website. No, actually, we scraped it kind of into GitHub discussions and mirrored that onto our website. And so the content that was getting slurbed up. Use GitHub as a CMS. Yeah, we used it as a CMS. Exactly.

It was a great strategy because everyone, And ultimately, everyone was asking the same questions over and over again. So we're just like, okay, well, we'll surface it each time. Yeah. It can be confusing because there's GitHub, there's superbased the open source, and then there's super based the cloud platform. And most people are probably going to come into support for super based the cloud platform. Yeah.

So it is. Yeah. Do you have any idea of your, this is very hard to tell, your open source market capture. So this is a thing that, like, if you're in the developer tools, circles, you know, you do? We quite deliberately do not. Don't know. So we don't put any tracking in our open source offering.

You can use it. And we've had enterprises. Large pharmaceutical companies, for example, come to us and say, hey, we're running 100 instances of your open source project. Can you offer us a product? So we've got this product called Control Tower, which allows enterprises to monitor a fleet of databases. You won't find it on our website.

Oh, come on. Why not? Because it launches... Oh, tomorrow. Tomorrow. I don't know if we're announcing it tomorrow. But, yeah, basically it's controlled out. All it does is this fleet view.

We've got this very popular product super base for platforms. So that's where all these AI companies are building on top of. We launch millions of databases for them. And so all we needed to do was repackage this for enterprises. And enterprises as well want to do the same thing, which is they want to spin up many... Internal super base for all of their users. They want to see and administer them.

And so control tower is essentially a repackaging of what we've already been developing for these platform providers, except specifically for individual enterprises. Yeah, I do want to cover because I think a lot of people think of you as bottom sub, GTM, you know, what the work you've been doing on the enterprise side. So first of all, shout out to Wembo. Yeah. I think this is your most successful recent launch. Superbase for platforms?

This one launched in, yeah. Yeah, yeah, I mean, December 2025, so. Yeah, but. I saw some stats or like, you guys call this successful. I don't know. What is the enterprise side, right? Like, what are, what is that story apart from, like, give me a dashboard? Well, first of all, we should talk about sales strategies.

Okay. So, Superbase is a very famously, Pongi company. Like, we give a shit about, we have 60% of every YC batch use Superbase. We focus almost all of our attention on, this like becoming an index company. Basically our role model here is Stripe. We want to follow in their footsteps. They're one of the only developer tools that we've ever seen

that has withstood more than a decade of moving our market and still keeping that developer love. So that's the first thing. So to do that, all we started doing when we did sales was layer on what we call product led sales. So we look instead for like product triggers. It could be like a logo, someone who we think is really important. But more importantly, they could be scaling up,

They could be hitting some limits, having some errors, paying a certain amount. We've got a bunch of these triggers. And then AI came along and we're like, oh, we can do some interesting stuff from this. So let's say we have a thousand product triggers every single week. We send off 1,000 emails to people who are having problems and say 500 of them respond. We take the cohort who don't respond and we use them as a control group. Okay. And we measure how much they grow.

Turns out they grow 25%. month over month. Then we take all those who do respond and we say to our sales team, the only thing you need to do is get on a call with these people and help them. And because we've got all their traffic patterns, we can give them a script, we know what their problem is, AI has been great on this. And we give them a script just to help out. And it turns out just getting on a call and helping people out, their account then grows 125%. So that 100% uplift, the incremental uplift, is what we compensate our salespeople. Traditionally, you'd say,

get on a call with these people and just sell them shit, and then you get the full quota. But because we know our database grows, our platform grows at 25% month over month on this cohort of users, then we know that our sales force are adding this 100% incremental uplift.

So that's how we do our sales function. It's always focused on these logos or very specific product needs. So, yeah, the likes of the enterprise is usually coming in because they're wanting to launch lots and lots of databases, or almost never it'll be a transfer of their production database. So migrating databases from, say, MySQL to Postgres or from, say, one scalable database to another scalable database, almost never happens.

And that was the core thesis of Superbase at the start. We knew that every single Postgres company we had looked at, or database company, we had looked at in the past that had tried to do migrations had failed over time. You just can't convince people to migrate, even if you build a bigger, better, more scalable Postgres. What you have to do is land with them on day one and then make sure that they stick around to day 1,000, day 10,000. So all of our focus is winning these enterprise logos on day one.

Greenfield. Greenfield, yeah. They're still not migrating? I guarantee they'll almost never migrate. There's a cohort that will need multi-grass. We talk to some logos who are looking at using it open source. They're very interested on making sure that they can basically help us direct because they're running into problems of Postgres as scale.

But for the next, say, five years, almost all of our focus on the enterprise side is making sure that we can handle greenfield use cases, which now in the enterprise, it turns out to be a very prolific use case because they want all of their product people to be developing, innovating as much as they can. So again, it's kind of perfect timing for us because that's what we've been focused on for so long. This control tower is like one of our biggest things. Multigress, of course, gives us the opportunity to win these large workloads if and when they want to ever migrate.

But it won't ever be one of our core focuses, or at least not for the next, say, five years. We're going to have to focus really heavily on just landing inside these enterprises and then expanding up. The other thing that's changed is we obviously put in the past all of our focus into developers. So it was like selling to the developers, enable them as a champion, they help you sell internally. Interestingly now we have like CPOs who are like,

wow, I didn't code for the last 10 years. But now because of Loveable and Superbase, I'm building all these things internally that we now have like champions at the sea level without needing to put like a huge motion around that. Oh, that's great. mentioning lovable, mentioning BOLB, Lovable is going to have their own database stuff,

you know, and like everyone is going to basically try to intrude on each other's turf, which is normal in the grand scheme of things, which is more sticky? Which is more sticky? More sticky. Like, is the CPO more likely to be married to Lovable or married to Suburbase, you know? Is that a question that comes up? It's a great question.

I think ultimately running databases is very hard. Fair enough. As we just discussed, it's harder to migrate your database than it is your front-end tool. Not that I don't think Lovellable is sticky. I think it's amazing. And actually, they were the first people to do a really good job of making sure their agent didn't do stupid shit with the database. Because we had very early on the agents were trying to shove image data into Postgres. They were turning off RLS in order to get their projects to work.

by paperclip maxing, basically, is that lovable, wrote rarely good skills to stock their agents doing stupid stuff. They were the first. That's the secret sauce. Yeah, yeah. It's to solve all these. And now, like, the models themselves don't do that stupid stuff anymore. Yeah. So it's, the situation has improved a lot.

It's gone from, like, Will Smith eating spaghetti, circa, you know, 2022 to Will Smith eating spaghetti in 2026. Yeah, yeah. And that's a famous meme. talking about, I'll leave the migration point alone after I mentioned this. You know, one of the things that I got like a big aha moment was when I met Karen from Koto, was one of your board members. And she said, like, her thesis is whole, like, you know, you are not just replacing Firebase. You're also like, you know, coming off as like new RDS, right, for Amazon.

If there was a, you know, stage four of a fourth era post-AI of SuperBase that is like the other, you know, the one trillion X in your, in your growth, rip out Oracle. I don't know. Yeah. Is that the, is that the white wheel there? That's the one that the famous migrations are after. I heard some crazy stat like that. It might be different now because they're trying to, Oracle are trying to move everything to the cloud.

But I think it was like one year ago. Someone said that only 5% of Oracle workloads by revenue ran in the cloud. And so like almost everyone was saying, oh, let's rip out Oracle. Let's do migrations. people, that's what I mean though. Like when I look through the history of database providers who have tried to run this strategy, it sounds amazing. And it's something that we will, of course, try to do ourselves.

Why will we not try to do this? But it is incredibly difficult. And I think you will just want to focus, first and all, on landing inside the enterprise. Yeah, that makes sense. It's one of those things where, like, you know, when I see, we talk to coding agent people all day long, the great promise is that you can. finally migrate off of all this legacy software that you have. Yeah. Right? And like hopefully that means that you cut over everything.

That's true. Because one of the things that actually makes Orakung so sticky is like you end up writing these million line stored procedures, like you stuff everything into your database. And so actually probably rewriting that is these days a lot easier. Right, right. So like hopefully coding agents are the boom. Maybe they're not there yet. Maybe you guys have to become more on-prem. Most of the problem around migrations is actually not, not rewriting it and you can do migrations for example on the data analytics side quite easily from one from one warehouse to another the problem is that usually your oldtp database is powering your most revenue generating application so a minute of downtime means that you end up with basically

dollars lost and so then what you end up doing is having to run these two things in parallel and then the risk of this is that you get this split brain where you've got some data running on one side someone on another and if you try to reconcile split brain, anyone who try to do it, it's a very hard problem. So the risks are just so much higher when it comes to OLTP that a lot of the time people just start splitting the workloads off and they'll start new workloads. They'll do a lot of operations here and hopefully they'll migrate things over. Usually then you've got two problems though. Well, speaking of OLTP, I mean, this is just like down database indulgence.

We also had two of the co-founders of Databricks here, Motei and Reynolds, where they are making a claim that they have solved H-TAP, which is the sort of the white will of database people. Yeah, yeah. If you know, like, well, traditionally you need an OLTP, you need OLAP database. Yeah. Never the two shall meet, except that sometimes you would like to never have to replicate anything. Yeah. Are you paying attention at all to that stuff? Like, is there a story there for SuperBases on Sunday?

Yes, we are. particularly interested in Duck Lake. I think Duck Lake is a very, and DuckDB is a very interesting technology. Is it Mother Duck, but a data lake? What is Duck Lake? Duck Lake. Okay, so DuckDB, which was recently, there's DuckDB, which is basically like a SQLite for analytics.

Column storage. Yes, exactly. It can read directly from object storage. That's typically how it's touted. And it can actually read from your Postgres database as well. So open source, great technology. And actually there's also DuckDB Labs, which was recently acquired by AWS. So they're a foundation that are developing.

So they're building a committee around the open source. I actually think of DuckDB a little bit like the Postgres of the analytics ecosystem in that they're trying to make it so that it's owned by no one. It does a lot of things. It's very versatile. It's like a professor in Netherlands. Yeah, exactly. They live in work.

the Netherlands, which is pretty cool. So our interest mostly on the warehouse side is not trying to make Postgres an analytical database, but mostly then focusing on using the right technology for the right job. I don't know if HTAB, many people have tried to slay the HTAB dragon. Object storage could be the solution to that, but generally, we think once you get to a certain size on the OLTP side, you need to have sharding. There's a limit to the amount of MVME disk space that you can have. So if you need to split transaction across two servers, you're basically then going to be fetching it from object storage.

Eventually, that will slow down your database. So we think that sharding is by far the best way to do scale up into the petabytes, and then you should treat your analytics differently. Now, that doesn't mean that you shouldn't store your data directly on object storage, for example, and then read from it from a different route, but trying to smash these two together doesn't necessarily, make that much sense, in my opinion. Yeah. I'm happy to leave it there because we do have more to work on.

I do think, you know, they have some innovations where they're basically using their spare compute on their database machines to power all this replication, is my read of what they're doing. And actually, to be honest, I haven't looked so much into how they're doing H-Tab, so I could be misquoting. Yeah, exactly. It's like you're in your lane. And, you know, it's not exactly like your customers are like banging the table asking you for this. Yeah. It is just like if you want to become the preeminent database company, someday you have to have an answer. Yeah.

Yeah. Exactly. Which like, yeah, it's interesting. The other mention I will check in on is durable workflows and, you know, that world. Yeah. Which, as you know, Temporal, I've been banging the drone for a while. You have made, like every year you made, you do a little thing. Yeah, yeah.

We're incrementing way towards. So like, don't you, like, how come it's not like more P0 for you? Because, like, you know Temporal is doing super well, right? Okay, so what was missing for us to do durable workflows? Compute. Right. So you're doing this now. Yeah. Super interesting space to be in, I think. Like, yeah, now we have had people in the community try to build workflow engines on top of super base functions,

and it just didn't work because of the two-second timeout. Yeah. Now we've got the primitive that would unlock the ability to do long, running durable workflows. I think my original pitch for Superbase is like you want the sort of the all-in-one, that there's sort of an interactive cloud that like is the backend, integrated back-end that people can use, right? Like you've got signing with ChatjipT now, which is a great part.

Like you just kind of have to sort of give the AI everything at once and then it will be your best friend. Yeah. Yeah, pretty much. Pretty much. And be prolific. I mean, our B1 strategy is to partner with as many of these frontier labs and models as we can, so we've got to be prolific there, and then we basically, we see our attach rates just

going up as well. Yeah. I mean, obviously there's the US labs. You're here in the US. Do the other labs have significant partnerships? What are they like? Mistral, Cohere, the Chinese labs. I don't know if... Not so much. Well, they might do. Okay, you primarily care about the US. Yeah, yeah, yeah. Yeah, okay, that's fair enough. Yeah. Mainly just because that's who's delivering the most traffic. At the moment, right, stock could change. But what does partnership look like? Like, basically, it's one thing to be on their app store.

It's the other thing to be their default thing when they launch an artifact. Yeah. So that one's super interesting for us to be able to hopefully be one of those providers. One of the reasons why we couldn't in the past was because we just couldn't handle their scale. I mean, take chat GPT, for example. What are they got now a billion monthly active? 1.2 billion monthly active users. One of their users launching a database.

every single month. Now we've got to launch 1.2 billion Postgres servers. It's just, as I said, we've got to get to the billions of databases per month.

We just haven't been able to do it until today where we acquire a company that means we've got the technology which can drive it up. Scale up, scale up. Okay. Other than that,

what are other, I guess, P0 objectives for the company? Like, you know, over the next year, how are you sort of guiding the direction? Oh, P zeros are basically win the strategic labs, win the models, and continue our PLG push, and then P4 is Enterprise. I like how P4 is in terms of rankings.

I mean, that is the truth of it. Like we, like, I mean, where we are focused on the enterprise is winning these new workloads. It's more that like the ceiling of PLG, when we started the company, we were like, we can get to 100 million on PLG. We can probably get to 200 million, but then we're going to need to do something different to terms of motion. But because of AI, like that ceiling just lifted, and we don't know where it got lifted to. Like, is it a billion?

Is it two billion? Is it, you know, you could just, we could just keep going. But we still want to do the other stuff as well. So we basically, like, last year, we were like, well, we have to do both. The bottom small stuff and the big stuff. And, you know, maybe we're a bit greedy. No, I think it's what people want, right? The same sort of mental model that, and, you know, they'll pay you to handle the fine-grained details of moving up in terms of orders of magnitude.

And I don't know how many orders of magnitude that is, but quite a lot. It's just crazy because if you would have asked us 18 months ago, we were growing fast. If you would have said, what can you do to 10x your top of funnel? I would have said, there's nothing. Like, it's crazy, right? And then just this whole market just exploded. So let's see what happens. Yeah, I remember at our own company.

offsite at the start of the year where we put this crazy ambitious revenue number out and so one came up to me and said, oh, you shouldn't have set that number. Like the team are going to be so we're going to miss it. We're going to miss it. The team are going to be so disappointed. And it took us like four months to hit the number. It's just like a ridiculous growth curve from the start of this year. Amazing. What are the open questions that you have? Like, you know, if you have a crystal ball, they would change the way that you bet on things. How development will be done? done and what people will develop. These are the two things that I think a lot about.

Okay. You know, what are the possible answers? It's just more agents. Yeah, so, like, this year we're focusing a lot. Like, and I'll talk about it in my keynote, basically, that we're moving from, like, we started as a dashboard company. That was the best DX. Then, like, you know, a lot of people are like, oh, Headless mode. Headless was what we kind of started, Headless 360, Salesforce, all these sort of things.

I mean, we had that at the start. Like, you could use super-based directly, API, drive. That's one of the reasons why we succeeded. This year, our big focus is moving to code-first get native. So basically, when you launch a super-base instance inside your local machine, you get this super-based folder, and it represents your database, it has all your functions, everything. Does this exist today?

This exists today, if you use the L-C-L-I. So it's a virtual file system? Like it's a representation of, it's like infrastructure as code. Okay. Yeah. And in fact, what we're announcing tomorrow is like we've done our kind of final change for declarative schemers. This was a really challenging one, actually, covering all of Postgres. And so now you can have a full file representation of Postgres, the shape of your database, declaratively in your folder.

That's really important for agents because generally how you operate with Postgreses, you have a migration file. Every time you make a change, you add a file to this migrations folder, and it's like a historical log. Okay, so that's great. It's industry standard. But imagine putting an agent across 1,000 files and telling, asking it, oh, what is the shape of this table? It has to guess through a thousand files. It has to recompile, basically. It's a recompile. Or you have to launch the database, locally run the migrations up, and then you introspect the database.

But that's too slow. So basically what we want to do is turn the schemers folder inside our superbase folder. into a completely declarative state of your database. And so we've captured everything from tables, policies, database comments, all inside these files. So we're releasing a new library, PG-Dolter. You can use it with any Postgres database, but we've got mechanisms for a super base.

And so this is an important step for agents. We know that agents are going to operate mostly on code. They don't want to reach out to anything. They've got to iterate very fast on the file system. So that's fine. and today people are using CRIs, they're happy with these harnesses. What I suspect we're moving more towards is like at the moment I'm trying to do some development just on my mobile phone, for example, and I'm quite comfortably able to do it.

Of course, I know what's going on behind the scenes, so I'm telling it things that I know it has to do from an infrastructure point of view, but we're getting to a state where I can imagine you don't need to be an engineer. You have an idea. You say to your phone, your daughter or whatever person, agent you have. I want to build X and one second later you kind of have this application live. You can iterate on it yourself. So these are the things that I'm thinking, okay, what are the use cases that people are going to want if this is the case? Is it personalized? What do we care

about? Are these things going to scale up? What are the mechanisms? How are we going to develop? And what tooling do we need to provide to make sure that we are the default provider in this new world. Any questions that you're interested in for crystal ball into the future? As someone who's been a software engineer now for like a few decades, you have strong opinions on like how the software should be built, right? Like in terms of like continuous integration or like continuous delivery or whatever. And I find myself like pushing my opinions on the on the agents of like, oh, you want to do it in this way. But now more and more like you don't need to. But my worry there is, are they all just going to like converge on one way of

building software? Yeah, mold collapse. Which is great. They're all going to use superbasis. But like the thing that's great about like the software development injury is like industry is like these are like famous flame wars, right? Of like what's the correct approach? Like are we going to lose that or? Yeah. So you want diversity and ideas. Yeah. So that the best idea can win. But then the models are just going to make you so lazy that nobody even bothers to look at the details. Yeah, and they just all converge on one way of building software. And then that's, you know, is it going to be like a local maxima in terms of? Yeah, I don't know.

I do think, yeah, so first of all, I think that's a valid fear. I do think it's out of your control. And yes, the low taste, let's call it the casual app builders will converge on whatever the mean is, the model is, which is you guys. but then the discerning high-scale people will always really care about the details as they should. Yeah. Right?

Which will then filter down eventually. Yeah. It's my idea. But are these high-skill people are going to continue to be trained by? I don't know. Yeah. Yeah.

I mean, I think people are passionate enough. It's one of those things where, like, you know, I do think like, you know, the average college is probably screwed, right? Like, you probably don't need to go to university anymore because you can probably self-teach. and just like, you know, get your own job. It's always been like this top tier of people that are moving a lot of the needle.

And you need to, and they will always find a way to have their own self-interest be satisfied curiosity in terms of like what is possibly better. You know, the type of people that take a year off and go to the Recurce Center and just work on cool programming problems, even though they could be making money in industry. Like, yeah. Yeah. What do you disagree on between the two of? It's rare to have the two of you had.

Wow. Yeah, that's a great... On the pod, so, you know, I want to capture this. I think one of the reasons we've been so effective, like, working together is because there are definitely situations when we'll disagree, but as soon as the other person like pushes a little bit, the other person's like, yeah, maybe you're right, let's try it. Yeah. So we never end up in like big bust-ups and it turns out like most of that stuff actually doesn't matter, right?

doesn't matter anyway. As long as the general direction is correct, then it's gone okay. But yeah, I can't think of... You guys are really struggling here. Oh my God. Yeah, yeah. Which is why, like, because it's never an important enough thing.

Like, we've never had a bust up because there's never been important enough to actually fight hard enough on it. And also, we're fucking busy. So, like, usually, like, ants handling. Yeah, we're trying to handle different parts of the business. Maybe it's just like things are growing and obviously you got your domain and you just need to work together. Yeah. Yeah.

Yeah. Yeah. It's interesting, you know, so Laura here, all three of us were in entrepreneur first in Singapore. You were all different working on different companies. And then you guys stayed back after the cohort, your housemates after the cohort. Yeah, yeah. So we were all, we lived in a house with seven people and we were all doing different startups. Yeah.

And so Am was doing his startup. I was doing another one. This is before SuperBee. And so, like, I think somehow your energies, you know, you found that you were suitable working together and working on this project. Yeah, because like traditionally, especially in an accelerator model, you're pushed as a technical person to work with some domain expert, right? But in the house we lived in, it was basically seven people who were all builders, all technical people. And we found that pairing to just be like so much more effective, especially on when you're building dev tools. because you are the subject matter expert as a developer,

is that we could just get so much more done. And so then we ended up hiring most of the other people who lived in the flat as well as our employee. Rory. Was the first employee? Not the first, but the first on go-to-market. Like now he runs all of go-to-market. The post-best guy was first.

No, Angelico. Angelico, yeah. We had an intern. An intern for my previous startup. We just dragged him along. Yeah. And then the other like first like full-time hire was this guy Steve Chavez, who, um, who is the post-grist maintainer. And the funny thing is we were in the YC batch and the advice to give you in YC is like, okay, we're going to give you a bunch of money.

Don't hire anyone. It's the big temptation is to hire big team. And we went to our partner and we said, oh, but we've got this guy, Steve. He's the lead maintainer of post-Grest. And he was like, hire him immediately. You know, he was like, forget the advice, go and get him. of his reputation or because it made sense for Superbase? Well, yeah, both.

It just made sense that, you know, this was a technology we were very reliant on and we were going to lean in. And it was like, and the funny thing is we hired Steve and we said, don't worry about Superbase, just keep building Postgres and just making it awesome. And then obviously if we have support requests or whatever we can ask them. And the model just worked really well. And then we ended up when Steve wanted to grow the Postgres team, just hiring more people dedicated to work on that project.

Well, you guys are doing so much for community and open source. One thing I do have in my mind is like what is the future of large commercial open source? One, obviously there's a lot of slop and I'm sure you guys are dealing with that. But two, also your dependencies are now becoming optional. Like you can just vibe code whatever you want. Anything, yeah. Yeah, yeah. So whatever is in your heads about the future of open stores, I'd just love to hear it.

I think the rewrite in Rust is a valid mechanism. I mean, someone came to me on our team and they're like, oh, yeah, yeah, I'm rewriting everything in Rust that we're doing. And I was like, to what level are you going to rewrite the database? Are you going to rewrite Postgres? Postgres is not rewritten, is not in Rust, but I doubt down to that level, you care. So there's like layers upon which you want to get to where things will be rewritten. And then you don't want to be spending your actual innovation tokens or your actual tokens rewriting everything.

So there's going to be like a collapse of almost every tool probably into, let's say it's rust if that ends up being the ultimate way of writing things because it's faster and more correct. And that will happen probably for most open source tools. But then after you've done this iteration and everything's running, on this highly effective language, then you're not going to be rewriting it all of the things every single time. There'll be a few winners. A really classic one could be, say, Postgres, it's written in Haskell, which is a very unusual language, and it's very hard to maintain. Could it be written in Rust now? Yeah, probably it could. And the mechanism, the function is still

valuable, and probably there'll be, if that happens, there'll be one Rust fork of Postgres, and that will be the winner for that particular category. But you haven't done it yet. And a lot of your stuff is elixir as well. Yeah, so that's the other thing. Then you have to think on the infrastructure side, elixir is like a really interesting language because of the beam. So then you start thinking when you're operating things,

what is the right mechanism for operating? But now you can change paradigms pretty much easily as long as you fit all your tests. Yeah, yeah. Well, that's a good one. I haven't thought a lot about would we switch Elixir to Rust. It's just an option now. Malta from Versal is, you know, one of his tweets that sticks in my mind.

He's got lots of interesting thoughts. He set aside some amount of money and rewrite all of our dependencies at the C level or C++ level into Rust. Because we just know it is safer, more correct, whatever. And it is a one-time upgrade of open source. Yeah. All the drivers, whatever you use. So I thought that was a pretty interesting call. I like that as an idea.

I don't think it will happen because people will love to do it themselves. Yeah. But as an idea, I would, like, we as a company would 100% get behind that. Awesome. And then I think closing question, which I should have stuck in somewhere earlier, AI coding within Superbase, right? Obviously, you guys have big beneficiaries of coding agents outside. What is the policy internally? How much are you spending?

Is there a concern about spends anything of that sort? Superbase has always felt like a bunch of different startups glued together. So we have like the Orth product. And we've always been very insistent that they should make their own decisions, like on what tools they use, like how they behave as a team, like the reporting structure. And the AI policy was kind of no different. Is like a lot of people asking, what is the AI coding policy? And we were like, well, it's up to you as your team.

I think we have started to consolidate a few bits, especially, around cost, but as much as we can, we'd like to keep that model of, like, let the teams decide how they want to run things. That's it. Very decentralized. I would say I am trying to figure out a number for company leaders to take home with them as, like, what is the market standard? And so what are the data points you can hang ahead on here?

People say, you know, the average person is spending like $20 a month, and then average employee is maybe $200 a month. Open AI, the sort of 50th percentile is spending maybe 3 to 5,000 a month, and the top percentile is in the maybe hundreds of thousands, right? And so that is the rough idea. I think a good metric is basically what is your ratio of token spent to human spend? And it's, like, for a lot of people, it's maybe 0.1 tokens to one human salary. And, you know, you can probably go up to one pretty safely.

And if you're over 1.5, you're probably in trouble. Something like that. So I'll just say, luckily as a remote company, basically everything that ever happened is documented. So I can ask our AI how much we're spending. So currently we spend about 300K per month. Yeah, for 600 people. No, like 450 people. 450 people.

Yeah, okay. It gets people an idea. But what you've said about scaling the cost in terms of related to the number of employees makes sense. Also for us because we are hiring very good. quickly. So if we end up getting a lot of leverage out of just like actually you should be right. Yeah. Then fine. You need a whole bunch of serverless employees that can spin up and down as you need. Yeah, exactly. Which is like, yeah, like, you know, I just had a CTO of, you know, another top startup. Say like he was worried about his company spend. And I'm like, well, actually, that's your investment in

everyone else. And probably is very skewed. Right. There's like two or three people that are super insane in your company. And everyone else is like probably not using AI. Yeah. Yeah. That's exactly what we see as well. We've got a leaderboard and people, we put the leaderboard up and usually people are a little bit of shame, so they're kind of like... Yeah, because you're wasting money, probably. Yeah. And that's also the wrong focus. Like, the focus shouldn't be on how much you're spending, but like how much end-to-end, like in terms of systems thinking, you should be thinking, like, in terms of how many end-to-end processes are you actually solving where you no longer need a human in the loop or collapsing down long-running human problems that suddenly become very short problems.

So that's where we're spending most of our investment on, like, how we're using AI. Likely, you know, as you saw, like, every single thing that's ever happened in Superbase is documented because we're an async company. So building a company harness, like an agendic harness around Superbase is basically just formalizing. You can point AI at it and say, what are our principles? And it'll document down all our decision-making principles for the whole history of Superbase. So that's where we're spending a lot of our time. Before we move on from people, we do have, I think now like 50 open roles and we're fully globally remote. So we don't care where you are if you're very good.

Same salary regardless of where you live. If you're very good at what you do, please take a look at our job board. Yeah. Can you like one profile, just pick one, whatever is top of mind as your highlight for what you're looking for and why? It's salaries. Okay. Yeah. Why?

Because we're just growing at a ridiculous rate. we need all the SREs we can get. What is a quality that is, like, you know, you probably get a lot of SRI applications and you don't look at them. Like, what stands out? The thing that we really care about is that you actually want to work remotely. So it's, this is a strange one, but yeah, it's true. We get a lot of quality people.

But to fit in at SuperBase, you kind of need to thrive in a remote first environment, like a fully async environment. It's actually not for everyone. We learned that pretty early on. people would come in and they'd be like, oh, this is, like, I need to see humans. My typical model of an SRE is like this gray beard that's like sitting in a dungeon somewhere. Yeah, yeah. That's the perfect.

That's the perfect person. All of those people, please apply it. Hopefully they listen to the podcast. Yeah, yeah. No, we probably do have a lot of great spirits in SREs. I think one of the, I have been on the record as saying AISRE is one of the hardest categories for agent startups. I think I might be wrong. soon, but so far has been correct.

Like, AI has not cracked, sorry, for whatever reason. No, no, no, no. Not yet. I agree. Yeah. Like, building software is, you know, debatable, solve problem. Maintaining, like, keeping things running. Yeah. Is it a whole different beast? Well, okay. Well, thank you for keeping things running for everyone else.

You guys, congrats on your journey, man. Like, I'm so proud to be your friend. Thanks, guys. And an investor and just like, just see the progress. I cannot wait for the IPO, whenever that is. it looks like it's going to take some more time but it'll be it'll be fun I really want to see you guys like you know

do the whole ring that ring the bell and you know building the next great open source company right excellent definitely man thanks for having us