Why Agents Love Supabase

Hello, it's me again. I hope, uh, you're enjoying these little episode intros that we're doing. Hopefully, it gives me little chance to talk to you guys about why we're doing some of these episodes and what you should look out for in the interviews so you get more out of the interviews. We're also adding overlays that you can see pop-up to keep it visually interesting to explain things that maybe if you're newer to the industry, you don't know, cause I don't have time to go over every single thing while we're having interviews.

Um, so I was at Supabase Selects recently, which is the Supabase company conference. Um, and there's a lot of stuff to cover. Uh, in particular, I think I should share that I have a very close relationship with this company. Um, I was an angel investor in their seed round six years ago, and they were my very, very first angel investment. They've done super well. They went from zero to 10 billion in in valuation in the last six years.

It's a fully remote, open source company, which is enormous. And and they're pretty much becoming the standard for hosting Postgres. So I wanna break down why what makes them tick. Um, I also wanna see why they did so well in my A U O ranking, uh, because it's not a it's not a given for sure, uh, and there's a lot of, uh, companies that are fighting for, uh, what it means to build databases for agents. They were also, I think, our very, very first sponsor for AI Engineer, the very first AI Engineer in 2023, um, and they're now gonna be our first sponsors for latent space, uh, which cause we're open for sponsorships.

And, uh, you know, who else to to do this with with companies that and people that I'm familiar with and trust and can explain very well to, uh, to our audience. And so the main things I wanted to cover, they have they have a whole recap here on their YouTube, which is very well executed and all that. But they have these these three themes of build, operate, and scale. And I think the announcements are very much what I kind of look for in a company conference keynote.

Um, so, build is basically how they want to improve post the Postgres experience for coding agents to set up. And the the two that that really stood out to me is, uh, one is it's very simple one is which is that starting Supabase without Docker, that that is, like, the the less weight I can I need in order to start up basic processes to interact with the, uh, the database, the better. Um, and obviously I can scale it up to to a full V M in the future.

But, um, the second thing is Supabase Compute, where, uh, you can run compute next to the database. I think co-locating that is super easy. I think this is, uh, honestly, super unreal. Um, I think this is, uh, maybe underselling what it potentially could be. Um, your app having an M C P server, uh, from a super database is really good. But declarative schemas is so important, right? But, like, you want declarative schemas rather than the standard SQL paradigm of, uh, set up a schema and then migrate, migrate, migrate, uh, which is something we cover in the the the podcast.

Like, um, if you you want everything to be in Git as source of truth so that your agent can crawl it, um, and figure and set up and fork and wh- whatever from there. Um, it seems so simple, but really when Postgres was not designed to do this, uh, it you have to kind of retrofit, uh, databases on top of, uh, on top of, you know, forty year old database. Um, and really, I I kinda see Supabase's momentum now as doing the last mile, like the the really like frontier of Postgres development for agents to really use them super well.

The beauty of it, though, is that it's not actually about agents. It's it like we just needed this the whole time. Um, so, but humans also benefit. And I I really like that. I don't like doing own doing things only for agents to be happy. So then the second part is operate operating. Um, so that is mostly just about giving more context, really, whether it's more logs, more checks, more connections, uh, markdown files for your SQL.

That's super cool, uh, knowledge and skills. They every year they ship, uh, some interesting pipeline, uh, work from, like, you know, Stripe to to other sort of integrations. Um, and I think the sort of general ETL problem, as you get further and further in your AI engineering career, becomes, uh, you know, more and more part of the data engineering stack. But now, Supabase has their own first-party solution. You can use a mix of both, like, whatever, but sometimes it's nice to have everything in one.

Uh, the last part is is perhaps the most, uh, complex, and, you know, at scale thing. Uh, this is why Supabase is changing their branding to prototype to Petabyte. Um, and really, they're going after more and more scale, obviously, because they're grow the customers are growing. Um, and so announcing a full V1 of Multigres, which is their, uh, their sort of ports, I guess, of Vitess for, uh, for Postgres with the Vitess guy, which is, uh, enormous in the database world.

If you don't know what Vitess is, you're losing out. Um, you you need to know. You're you're watching this on YouTube, uh, on the Vitess website. Um, Aureole DB and DB. So, like, there's a lot to go in there. And, honestly, uh, you can see my connection with the with the founders. I think this is the first interview ever that the two of them have done. And I make reference to that and try to, uh, view their chemistry and show show you what it's like to discuss and run 10 billion dollar database company.

Enjoy. Okay, this podcast has been six years in the making. We're excited to have, uh, Copplestone and ants in the studio. Welcome, guys.

Thanks. Thanks for having us.

Uh, we're recording this ahead of Supabase Selects, which, you know, it's your it's your big customer conference. And we'll release this after the the conference. But I just wanted 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 se like soft launched on Hacker News by, like, you know, some random user sometime?

Um, anyway, congrats on all the the the success. What are you announcing? The headlines at Select? Let's just get right into that.

Yeah, yeah, sure. Um, so there's quite a few headlines. We've got a lot to cover. The main ones would be starting off with, um, compute. So we offer a product called Edge Functions, and Edge Functions are powered by Deno, 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 wanna run much longer workloads. They wanna do things like chunking and me embedding.

So tomorrow we're announcing, and by the time this comes out, Supabase 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 Deno. You can use it with Rust or Python. You can run agents inside it.

It's basically just a a full compute instance.

Let's call it, uh, the comparable offerings in other clouds that others might be familiar with, uh, would this be

Yeah, so something like a a Lambda function, but, um, the container type Lambda function, um you can run a full container, basically.

And then there's the other stuff.

Yeah, and then we have, well, three dem uh, innovations on the database space. So the first one, which we talked about last year, which was Aureole DB. Aureole 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, uh, performance, scaling up, and scaling out. Uh, Postgres touches on, uh, sorry, Aureole DB touches on performance. It is a drop-in replacement for the the current Postgres storage engine, which is Heap, and it runs about, um, 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 paid 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, um, every operator drops data in some situation.

Well, so this is for the second the second one, so scaling,

I see. So that's that's that's Multigress.

yes. So Multigress 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 wanna 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, um, certain conditions, every single one of them could lose data.

And so we decided, with Multigress, to do a ground-up rewrite of the entire structure of a of a operator. And so Multigress is essentially, while our initial goal is to become, uh, give sharding to the Postgres community, what has turned out to be is this entire operating system. And we actually ran it, uh, again, through very rigorous testing, and we've done a thou- uh, one thousand 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, it's completely open source. It will be on our platform for customers in, uh, invite-only. So people who are running serious workloads can come to us, and we'll start helping them to scale up.

Is this the full completion of Multigress being fully sort of parallel to Vitess, or is there still something left to go?

No, actually, yeah, it was quite interesting. So Sugu, um, originally created, uh, Vitess in for the MySQL ecosystem, but specifically for sharding. And actually, when he came along, he said, well, the number one goal that we wanna do for this time, because we're always catching up on compatibility when we use Vitess, you always had to change things as you move to shard it. So change some queries. So he said, I wanna 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 Multigres will just be able to handle it. Zero changes to your code.

That I mean, that's, uh, incredible vision, and the the fact that you've been able to do it in two years.

That's one year, um, so we haven't released sharding yet. I've seen the early prototypes and the designs for how we're doing it, and it should should 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, um, but we're very confident. We're and we're we're happy with the progress. It's it's been pretty good.

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

Yeah. And hopefully, it it's not just for Supabase customers, right? Like, it's Any for the open source open source community it's anyone who's things, ooh, ooh, who's running Postgres

ooh, yeah.

at scale, um, should be able to use Multigress.

Yeah, I'm sure, like, every coalition, every company that's involved in Postgres in some way is contributing to this thing, right? Cause we all want this.

Yeah, yeah. We've got a whole design partner program, so, um, 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. They a lot of people need it. They're running Postgres at scale, and they need something to sc- help them scale up.

Yeah, third.

Third one is, uh, yeah, so this one's a big one, um, scale out. At the moment, we launch about 5 million databases on our platform every single month. And kind of the future where we 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 agentic database space.

And there's no other leading database provider who does agentic well than Turso. And so, actually, tomorrow, and when this is announced, it would have come out where we have announced that we've acquired Turso to help us power agentic databases.

Yeah, that's an incredible. It it's also like they're they're primarily SQLite based, but it doesn't really matter, right? Like, it's that it's it's more about the architecture of, like, I guess I don't have the word to describe how, basically, like, broadcast is that the word? For For scale out, right? Like, um, there's the idea for them scaling SQLite was that they will 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, um, so generally, it's not

Like, sort of an MVCC for

yeah, e- exactly, exactly. So then they built this Turso architecture, which basically builds MVCC for SQLite so that you can have multiple writers. Yes. And because And then, of course,

SQLite is has a weird license, they had to fork it.

they had to fork it. They originally started with libSQL, and then they 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 while on 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 a database.

And because object storage itself is, I think it's eleven nines of of data durability, Durability, yes, which then

is not reliability, but whatever.

yeah, non-reliability, but it it gives you what you need for for, um, 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, um, 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 a lot of reads and writes.

And so in this case, you probably don't wanna be doing something at massive scale on this. And that's why we have Multigres. 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 Glober, I said, uh, he released a blog post on how they've done their rewrite.

Basically, makes the we have a pathway to get Postgres compatibility with their file format. So we're a acquiring them, and we're actually gonna keep the Turso brand. So Turso's gonna focus on SQLite, and then we're going to introduce this new smaller instance type on Supabase called Supabase Spark, and it'll be compatible with all our libraries. And you can have one database for any idea, any prototype that that you want, and when it takes off, then you just upgrade to full Postgres databases all the way up to Multigres.

I know you've been working on this for a while. This is the dream, right?

Yeah, yeah, yeah. There's been both scaling up and scaling down has been one of the things that we've been trying to figure out how to do. And it's really when some of these innovations came along that we realized, oh, okay, we can do this.

You know, you you're going to 5 million a month, let's say you see on the the trajectory of b billions per month. One of the secrets is they're actually kind of small databases. Right? Like, these these things are tiny. They're Vico coded apps. Like, no, like, I I don't know if you have any insights on on the on, like, what it is under I mean, the hood.

until they get traction, right? And that's the thing is, like, once you hit the front page of Hacker News, you need to know that you can go far beyond that. Um, and so the whole idea with with all of this was we need to make sure we've got a really smooth pathway to migrate between the backends, like zero downtime migrations. It's like, we it's just like a 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 the a customer magic school, and the guy was like a teacher, right? And he saw all these, like, uh, inefficiencies in teaching, like teachers spending time that, uh, on 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. It's like a bit a builder now. Um, and that's why we see, like, the growth we've seen over the last eighteen months is crazy.

It's Yeah, but but it still feels like early, and I think, um, there's a much larger market of almost like consumer-like builders, right? I said people inside companies, people who wanna launch their own startups, which is gonna 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 in the world pretty fast.

Which is basically what's happening now. Yeah. I mean, like, we've faced it throughout this year. We just our growth has, uh, has been, uh, one of the things that we've had to deal with in terms of capacity of compute.

yeah. So congrats. Also, I will observe that I feel like Glauber is also a meme lord.

Yeah, well, that's one of the Right, like, I things why we mean, like, come on, like him. Yeah, he's like amazing.

so for those who don't know, the the person behind the Supabase memes is this guy, uh, the you know, um, low key low key a killer. I I would say, and Will Glober also.

Yeah, yeah, yeah, big time.

I don't I need I don't know if you guys ex exchange notes on, like, what's funny

Not yet. in in terms of No, but we're database weirdness we're gonna

that came up.

give them we're gonna give them access to the Supabase Twitter account for sure.

Oh my god.

Um, I I could do with some help.

Uh, yeah, yeah. Wait, is this still you?

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

I'm not as funny as you. You're really, really funny. Where's there was one with, like, a seagull, and you were s like, um, standing on top of a Supabase standing turtle.

on top of Postgres, I think it was. Yeah, it's like But I guess

a standing seagull riding a flying seagull, and it's like

My god. Yeah, I I

Supabase Postgres.

can't I can't find it right now, but and this is all, like, deep Supabase 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 it was your mo like, memes.

And 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 hard. The guy Like I said, it's hard who did, to hire for.

like, 40,000 word essay on breaking down, uh, meme strategy.

Someone studied our Twitter strategy actually really early on and posted it on on Hacker News.

Yeah, on Hacker News.

Uh, and and that was funny because they'd recorded the strategy in a way that we hadn't committed to paper yet. So then when we onboarded new marketing people, we were like, here's the strategy. It was written by someone else.

Yeah. And of course, Hacker News hated it, and then they they were commenting on it,

I found it, funny.

and and took the the first

This guy, this guy, this comment. guy. Learnings from four months of Supabase feed. He just looked at your work When was for four months.

this? 2022? Okay.

Wait, I'm I I mentioned it. Ooh, okay.

There you are.

So he just broke it down.

He broke it down. And then Hacker News hated it on it, and so Ant took a photo of them shitting on it and posted it on our Twitter account.

Your hate just fuels me.

Well, it was this, uh, interesting article. Yeah, okay, so I commented. Yeah. There was, like, a lot of our growth was thanks to Hacker News. I mean, in the early days, I just would live on there and

So we should talk about that. What deal with the devil do you have to do with Dang, uh, oh, man. to

We we've been scolded by Sangi, like, uh, many times, like, We've been for for launch for launching too many things in a week, basically.

And he's, like, rightfully paranoid about the association of Hacker News and YC. So he kind of, like, if something happens, he kind of wants to throw us under the bus so that he people know, Oh, we're not doing this for YC customers, we're an independent site. So he's been helpful to, uh, make sure that we we don't smear the name of of YC or I I mean, at Hacker News.

this point, you don't need them. But, like, for sure, I think, uh, Dang does a Dang has super high credibility, and no one no one really, like, you know, uh, questions him. But I 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 Well tweeted that proudly. I was like, Oh, yeah, that's here we are.

so what?

And then I got told off cause of we were like, it basically looks bad. Because because, like, suddenly this YC company is like dominating the front page of Hacker News. It looks like it's a bias thing.

I'm like parading the fact Parading that they're on the front page of Hacker yeah. Yeah. Which News.

is true, like, so, like, tip to anyone, never screenshot the fact that you're on the front page of Hacker News and put it on Twitter, because it's it does look like we're and and to be honest, it it was gloating, so so it's a fair fair call out, yeah.

Yeah, there's all that, which, like, I would say, I was cons considered that somewhat ancient history now, you know, it's been a few years since since this is a relevant thing. But for those who don't know Supabase's history, these are the things that you must check off as, like, the the tour of things. What else? I mean

I I think the the the top post there is interesting because

this is the launch post?

yeah, but but it was someone else who launched those, like, we weren't ready,

Biggie. Yeah, yeah, yeah.

we weren't ready to be launched on Hacker News.

And you didn't consider yourself a Firebase alternative?

Oh, yeah. So that was the day that we changed the tagline. We had the

What was your original tagline?

tagline. It was real-time Postgres. Because what had happened was I wanted like, we 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 kinda cool. So we were like, Oh, real-time Postgres.

No one cared. No one cared when we had a website. And so, like, we were 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 twelve hours later or something like that, that this article went up.

Yeah, still the top of all time.

And at the time, we were s running on top of DigitalOcean, and every new database was two droplets. So two five dollar a month droplets

Why?

um, one for the, uh, database, and one for the APIs. Right? Because we

Cause we wanted to upgrade the APIs

Independently?

and decouple them.

and we only had a handful of, like, test users at that point. And then all of a sudden, I think we went

we only had eight users. We went from eight to 800 on that that launch alone.

yeah, and then we burned through, I think we had, like, ten K of DigitalOcean credits, which we just burned through in basically forty eight hours. Um, and then we just got into YC. So AWS was like, Oh, we'll give you, you know, whatever it was, 150 K in 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 wanna spend your first week That's in YC.

crazy. Do you remember that we could have been on digital like, bas- basically, we should still be building on DigitalOcean, cause 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 dollar 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 Being of DigitalOcean

too strict, yeah.

ever, then I know our bills with AWS now. This is, like, probably Nothing. one of their biggest customers ever that they lost from being too strict about But because that.

it was COVID, it was a time when everyone was worried about, like, what's gonna happen? So I think they were like, we don't wanna overextend ourselves. Um,

Yeah, it's fair. Yeah.

yeah, so it was, like, totally fair at the time, just given the, um, the way the world was looking.

People made many irrational thing uh, decisions during COVID. But you never know. I was gonna say, uh, 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. They've Because compute is, uh tripled their they've tripled in the last year.

wow, that's cool. So what are they They're sixteen sixteen

billion now.

billion? Yeah. Okay.

Uh, and like and like, uh, 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? Or what do you do? Like, you you just have agreements with people Yeah, we to

've got to, like, plan

you just pay more? very closely. We we Yeah.

pay 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 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. Well, we need more compute, basically. So GCP is a very obvious choice. And of course, we wanna 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 wanna 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 is is the leader there. It's hard to be multi-cloud if you're gonna 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 the all the features, but I'm sure that, like, whatever S3 do, others follow. So

I I still remember, I think, like, three years ago, they introduced, like, strong consistency.

yeah, that's the innovation, basically, that that helps, yeah.

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. And what?

Yeah, yeah. And then S3 Express as well, that was a big game changer. Um, because

Why?

well, basically, now what you wanna 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, um, and so the write times to this are one to two milliseconds. And so before you can guarantee a write 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 eleven nines, but durable

Good enough?

enough that you can. Ah

It's ep- ephemeral durable.

yes, exactly. And then then in the background, you take you take you use this kind of as your cache, and then you move into S3 in the background, which So do is cheaper.

we do we need Redis anymore?

Ah, yes, yeah, you still need Redis. Like, this is no nowhere near fast enough. You need, like, basically, your cache layers are either memory, NVMe drive, um, local

This thing?

attached S3, they're equivalent, and then S3. Yeah, normal.

Amazing, amazing. There was a little bit of data, like, we we jumped around quite a lot. Uh, if you have a business new re uh, a few more things that we were gonna talk about. You you your slogan was build in the weekend, scale to millions. Now we're prototype to petabyte, which is which is excellent. And really, it is reflective of the evolution in scale that you guys are doing, right? Do you have anecdotes on, like, let's say, early Supabase versus now, how fast are people scaling when they when they start a thing?

Yeah, well, the big thing is, um, I think how fast people are monetizing. At the start, it was like, you choose your database, you build your product. At some point, you, um, add in billing. Now, because you can add in Stripe, like, at the agentic layer, it's like we see customers starting a project and within the same week, like, generating serious cash. And and in the early days of vibe coding, it wasn't obvious to us that this is something that's gonna stick around.

This is gonna change the way software is built. But as soon as we saw someone earn, like, I think it was $10,000 within the first few days of launching their product, we were like, Wow, this is this is real. People are making real things that generate real money. Um, so we knew we had to lean in. In in a way where there was waves we'd ridden successfully in the past, like when NFTs were huge, we leaned in a bit, and we added, like, sign in with Ethereum and sign in with Solana, um, but we didn't dedicate, like, tons of dev time because everyone kinda knew it was gonna go away at some point.

And making that decision for for vibe coding was like, you know, we 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 up market. It's like our biggest customers were, like, stretching the limits of of what we had at the time. And so we knew we had to then just do both. It was like, you know, um, innovate on the on the small, like, prototype stuff, and innovate on the on the much larger side as well.

And then you just need more people for that side, right?

That one's funny because, like, on the number side, basically for Supabase, there's been three chapters of AI. So the first chapter was, um, embeddings. I think we were on Supabase Vector, Yeah.

which I have now transcribed, and it will always, uh, uh, we we we should probably update this cause, uh it's we're this is the only talk like, super you've ever done at AI.

Yeah. We did this talk. Uh, basically, all these embedding databases were coming out, vector databases, create the vector. And so we were pushing the fact and you can use Postgres as a vector database. And Andrew Kane, a 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 gonna store your own embeddings. So this was chapter one, and it was it was really a good growth driver for us.

A and also good for the Postgres ecosystem, just letting people know. Now there's a lot of innovations in in embeddings, what Turbopuff are, for example, are doing. They use a lot of the innovations that Turso are doing, and I think it's a phenomenal use case for that type of stuff. So that was chapter one. Chapter two was, like, the vibe coding wave, where it was Lovable, Bolt, all of these ones coming along. There was end of 2024, and that's where we debated a lot.

Hey, do we really wanna be there? Do we wanna be servicing these? Do we even wanna have our own vibe coding type platform on top of Supabase? But in the end, like, our mission is store the world's data, and to do that, we based on our tagline, it's like be there when you're getting started, make sure that they never wanna 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 numbers started this year, the models just got better, basically. And then we started seeing our top of funnel, our 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, uh, most of it's just memes and things like that.

So, um, Here I got I so

got one of your charts. There we go. I mean, all your all your charts look the same, but because they're just, like, exponentially

It's super weird.

increasing, you just keep you But just keep changing the the other crazy thing y-axis.

about this is is often when you get, like, more consumer-like traffic on 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 Like, how do marks.

you know activation and conversion to pay? Oh, your, at Supabase. our metrics, yeah, our Ah, okay.

funnel metrics, um, and and the reason is because the sign up to activation, the agent does it for you, like, in one step. So it it's basically a hun- it's almost 100% The friction's of that funnel.

gone. Yeah.

Um, and so those users then were converting to pay at a higher rate than our traditional developer user.

Okay. I mean, excellent.

It's great. Yeah, I mean, it Yeah. does. But but But I'm sure I, but but I'm sure well, I mean,

I'm sure, like like all developer tools are seeing the same thing, right?

Well, uh, at different rates, I think you guys are clearly one of the the leaders there. You know, I was gonna bring up this one of these these things. I have this A E O tracker, uh, where, you know, if you if you type in Supabase, and there's a there's a few categories where you're the leader. Uh, but basically, it has led to every single frontier model recommending you as your primary choice for an integrated backend.

What does integrated backend mean? It it is your original offerings, like your your auth, your, uh, functions, your, you know, um, and your database and and all the other stuff, uh, 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. And then to you can take over.

yeah. yeah, yeah. We were very lucky with our timing. I mean, we couldn't have timed it better, like, it was complete accident.

Well, I mean, I think, like, on first principles principles basis. So we have interviewed other founders who maybe started post LLMs, and Recend was kind of there. We've also talked to them, like, why does my LLM keep recommending Recend? And it's because they have, uh, a lot of good A E O practices.

Sure, yeah. And of course, we invest very heavily in that. But, you know, when we 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 community as well, right? Like, our one of our growth strategies early was just was spending so much time with the community. And it resulted in they were writing blog posts, they were making YouTube videos, they were putting on podcasts, all about how to use Supabase and what situations, like, here's how I built this thing. I'm sure that all just got slurped up by the the model.

And open source helps as well, of course. Yeah. And being

yeah, definitely.

being open source. Uh, 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 some in in more deeply.

Yeah. So so last year at Supabase Select, we announced that we were gonna do a crowdfunding round. It's something we've always wanted to do. Um, 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 wanna 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 you if you really just wanna give the stock away, you can. And so now we've earmarked, like, a $1 million in Supabase stock that we're basically gonna give to a bunch of the community members.

The first community member we're we're gonna stand up on stage and sort of announce is is this guy. His name's Gary Austin in the Supabase Discord. And this guy is, like, a legend of the Supabase community. He we looked into his stats, and Gary has answered, uh, 20,000 in the last six years, 20,000, uh, questions in the Supabase 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 bot, like, he's a real human.

Have you met him? What what is his what yeah. He's is his deal?

real. We we've met him. He he was basically, like, retired and just interested in Supabase. Gary Austin? Oh, Gary Gary Austin. Abbott? Yes. Gary Yeah, Gary Abbott is his

Abbott. Yeah.

real name.

Okay, this guy. Yeah. And and Okay.

he loved Supabase because he basically built his own simi- Simile, um, app, cause he loves red wine. Um, and then was just getting a kick out of, you know, he's got Supabase logo on his Christmas tree. And he's also, like

By the way, this is my favorite Supabase meme. So it's just like you reminding me that, like, I I'm about to run out of my Supabase.

That's the announcement is we're basically like, um, anyone who's a a legend in the Supabase ecosystem, we can now, um,

Is Discord still a strong? I mean, I I got mixed feelings with Discord. It it is it is, uh, 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, uh, in the early days. We we decided not to do it because you still needed to police, like, what things you wanted to be public and and what things you didn't. But the original debate that I remember we debated a lot was, Okay, we wanna 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 gonna use Discord, Reddit users are gonna use Reddit, and we basically had to do all Just be of the above

where they are. Yeah.

and be where they are, yeah. That's the answer, It which there It was a lot of work.

yeah. And it worked out, right? I mean, that was the right answer.

But then there's a lot of, like, great tools that started popping up, right? Um, or

I don't think anyone has let has, uh, s stood the test of time, let's call it. Uh, but yeah, there there have there well, there, are there are tools there, that are a discord mirror to public Q and A site. That is a thing that people do. I don't know if it's been successful for anyone.

yeah. And and, like, common room, um, Actually, helped a lot.

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 Ah, you use scraped off

GitHub as a CMS?

Yeah, we use it as a CMS, exactly. Yeah. It was a great strategy because everyone, ultimately, everyone was asking the same questions over and over again. So we were just like, Okay, well, we'll surface it each time.

Yeah. It can be confusing because there's GitHub there's Supabase, the open source, and then there's Supas Supabase, the cloud platform, and some and most people are probably gonna come in to support for Supabase, the cloud platform. So, yeah, it is. Do you have any idea of your, uh, uh uh this is very hard to tell, your open source market capture. So, uh, this is a thing that, like, if you're in the developer tools circles, you you know, you do.

We like quite deliberately do not.

Don't know. So we Yeah.

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 a hundred 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 have monitor a fleet of databases. You won't find it on on our website, but, uh,

come on. yeah, yeah. We want Why not? to. Cause it launches Okay, cause Oh.

tomorrow tomorrow.

oh, I don't know if we're announcing it tomorrow, but, yeah, basically, as Control Tower, it all it does is is this fleet view. We've got this very popular product, Supabase for platforms, so that's what 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 wanna spin up

Internal Supabase.

many, many internal Supabase for all of their users. They wanna see and administer them. And so Control Tower is essentially a repackaging of what we've already been developing for these platform pro providers, except specifically for for individual enterprises.

Yeah, I do wanna cover because I think a lot of people think of you as bottoms up GTM. Uh, you know, what the work you've been doing on on the enterprise side. Uh, so first of all, shout out to Embo. Uh, I I think this is your most successful recent launch, which is,

Uh, Supabase for platforms. This one launched in, yeah.

yeah, yeah. I mean, December 2025, so Uh, yeah, but I saw some stats or, like, you you guys call this successful, I don't know. Um, what is the enterprise side, right? Like, what what are what is that story apart from, like, give me a dashboard?

Well, first of all, we should talk about sales strategies. So, Supabase is a very famously, PionG company. Like, we give a shit about we have 60% of every YC batch use Supabase. We focus almost all of our attention on this, like becoming an index company. Basically, our role model here is Stripe. We wanna 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 up 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 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 a thousand 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. And we measure how much they grow. Turns out they grow 25% m 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's been great on this. And, uh, 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 these people and just sell them shit, and s 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, uh, 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 Supabase 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 one thousand, day 10,000. So all of our focus is winning these enterprise logos on 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 multigress. We talk to some logos who are looking at using it open source. They're very interested on making sure that, um, they can basically help us direct because they're running into problems of Postgres at 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 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 gonna 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, sell into the developers, enable them as a champion, they help you sell internally. Uh, interestingly, now we have, like, C P O s who are like, Wow, I didn't code for the last ten years, but now because of Lovable and Supabase, I'm building all these things internally that we now have, like, champions at the at the C level, um, without needing to put, like, a huge motion around that.

Oh, that's great. Mentioning Lovable, mentioning Bolt. Lovable is gonna have their own database stuff, you know, and and like everyone is gonna basically try to intrude on on the each other's turf, uh, which is normal in in the in the grand scheme of things, which is more sticky.

Which is more sticky?

More, more sticky. Like, is the C P O more likely to be married to Lovable or married to Supabase, you know, like, is is that a question that comes Ah, that's a great up? Or

that's a great question. I think ultimately running databases is very hard.

fair enough?

Well, and and as we just discussed, it's harder to migrate your database than it is your front-end tool. Um, not that I don't think Lovable 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, um, the database. Because we had, very early on, the agents were, like, trying to shove image data into Postgres. You know, they were turning off RLS in order to get their projects to work, um, by paperclip maxing, basically, is that Lovable wrote really good skills to stop their agents doing stupid stuff.

They were they were the first.

That's the secret sauce. Yes, it's to solve all these.

And and and now, like, the models themselves don't do that stupid stuff anymore. So it's it's the situation has improved a lot. It's gone from, like, um, Will Smith eating spaghetti circa, you know, 2022 to Will Smith eating spaghetti in 2026. Yeah.

and that's a that's a famous meme. Uh, talking about I I'll I'll leave the migration point alone after I mention this. You know, one of the things that I got, like, a big aha moment was when I met Karen from Coto, who's one of your board members. And she said, like, her thesis is whole, like, you know, you are not just, uh, replacing Firebase, you're also, like, you know, coming off as, like, new new RDS, right, for for Amazon.

Um, if there was a, you know, stage four of, or fourth era, post AI of Supabase, that is, like, the other, you know, the 1 trillion x in your in your growth. Rip out Oracle. I I don't know. Like, what is is is that Well, that's the the is that what that's the that's the whiteboard the one that said?

the famous migrations are after. I heard some crazy stat like that. It might be different now cause 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'll, of course, try to do ourselves. Why would we not try to do this? But it is incredibly difficult, and I think you will just wanna focus, first and foremost, on landing inside the enterprise.

Yeah. But yeah, that makes sense. It's it's one of those things where, like, you know, when when I see, I 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, right? And, like, hopefully, that

That's true.

that means that you cut over everything.

That's true because one of the things that actually makes Oracle 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. It's so, like, hopefully, coding agents are the boom. Uh, 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 OL OLTP 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, some on another. And if you try to reconcile split brain and anyone who's tried 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 doing 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, uh, uh, this is just, like, down database indulgence. We also had two of the co-founders of Databricks here, Matei and Reynold, where they are making a claim that they have solved HTAP. Uh which is the sort of the white whale o of database people, right? If you if you know, like, uh, well, traditionally, you need an OLTP, you need OLAP database, um, never the two shall meet, except that, uh, sometimes you you would like to never have to replicate anything.

Are you are you paying attention at all to that stuff? Like, is is there is there a story there for Supabase at some someday?

Yes, we are. Particularly interested in Duck Lake. I think Duck Lake is a very and DuckDB is a very It's is it interesting technology.

not a duck, but a but a data lake? Like, what what is what is Duck Lake?

Uh, Duck Lake, okay. So, um, DuckDB, which was uh recently is DuckDB, which is basically like a SQLite for analytics.

Columnar storage.

Yes, exactly, 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, uh, DuckDB Labs, which was recently acquired by AWS. Yeah, so they're a I love the foundation that are developing.

company. Yeah.

So they're building a committee, um, 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 they live and work out of 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 HTAP many people have tried to slay the HTAP 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 NVMe 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 I'm happy to leave it there cause we do have more, uh, to, uh, work on. I do think, you know, they they have some innovations where they're they're basically using their s their spare compute on their, uh, database, uh, machines to power all this, uh, replication is is, my read of of what they're doing.

And actually, to be honest, I haven't looked so much into how they're doing HTAP, so I could be misquoting.

Yeah, e- exactly. It's it's like you're you're in your lane, you know, it's not exactly like your customers are, like, banging the table asking you for this. It is just like, if you want to become the preeminent database company, someday you have to have an answer. Which, like, yeah, it's it's interesting. Uh, the other mention I will check in on is durable workflows and and, you know, that world, which which, as you know, Temporal, uh, I I've been I've been, uh, banging the drum for a while.

You have made, uh, like, every year you make you do a little thing.

Yeah, yeah, yeah. We're incrementing Yeah, but, towards yeah.

like, don't you like, how come it's not, like, more P zero 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 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 Supabase functions, and it just didn't work because of the two second timeout. Now we've got the primitive that would unlock the ability to do long running durable workflows.

I think my original pitch for Supabase is, like, you want the sort of the all-in-one, the the the sort of Engineered cloud that, like, is the backend, integrated backend that the people can can use, right? Like, you've got signing with ChatGPT now, which is, uh, a great part. Like, you you just kinda 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, ah, we see our attach rates just going up as well.

Yeah. I mean, obviously, there's the US labs, and you're you're you're here in the US. Do the other labs have significant partnerships? What what are they like? Mistral, Cohere, the Chinese labs? I I don't know if Not so much. We're, What's in here?

Oh, well, they might, they Might do. Uh, and

Yeah, okay, you probably only care about the US. Yeah, okay, yeah, that's fair enough.

Yeah, mainly just cause, like, that's who's delivering the most traffic at the Moment, right? So that could change.

But what does partnership look like? Like, basically, it's one thing to be on the their app store. It's the other thing to be their default thing when they when You 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 ChatGPT, for example. What do they got now? A billion

1.2.

Monthly active 1.2 billion Monthly active users. One of their users launching a database every single month. Now we've gotta 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 out. Okay, um, o- other than that, what are the other, I guess, P0 objectives for the company? Like, you know, over the over the next year, how are you sort of guiding the the direction?

Our P0s are basically win the strategic labs, win the models, and, uh, continue our PLG push where we are focused on the enterprise is is winning these New workloads.

And 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 gonna need to do something different in 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 2 billion? Is it, you know, you could just we could just keep going, but we still wanna do the other stuff as well.

So we basically, like, last year, we were like, well, we have to do both, and the both the small stuff and the big stuff, and, you know, uh, maybe we're a bit greedy.

No, I I think it's it's what people want, right? The the same sort of mental model that, uh, and, you know, they'll they'll pay you to handle the fine-grained details of, uh, moving up in terms of orders of magnitude, And I don't know how many orders of magnitude that is, but quite a lot, 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 it's crazy, right? And then just this whole market just exploded, so let's see what happens. Yeah, I remember at our company offsite at the start of the year, we we put this crazy ambitious revenue number out, and someone came up to me and said, Oh, you shouldn't have said that number.

Like, the team are We're gonna Gonna be so

Miss it. Yeah.

We're gonna miss it. The team are gonna be so disappointed. And it took us, like, 4 months to hit the number. It was just, like, a ridiculous growth curve from the start of this year.

Amazing, um, what are the open questions that you have? Like, you know, if you had a crystal ball, it it would change the way that you bet on things.

How development will be done and what people Will develop. These are the 2 things that I think a lot about.

Okay. Well, you know, what are the possible answers? It's just more more agents, like,

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 Supabase directly, API-driven. That's one of the reasons why we succeeded.

This year, our big focus is moving from from, um, to code-first, Git-native. So, basically, when you launch a Supabase instance inside, um, your local machine, you get this Supabase folder, and it represents your database. It has all your functions, everything.

Does this exist today?

This exists today if you use the LCLI.

So it's a virtual file system.

Uh, like, it's a representation of it's like infrastructure as code. Yeah, and in fact, what we're announcing tomorrow is, like, we have done our kind of final change for declarative schemas. This was a a really challenging one, actually, covering all of Postgres, and so now you can have a full file representation of Postgres, uh, the shape of your database declaratively in your folder. That's really important for agents, cause generally how you operate with Postgres is 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 a thousand files and telling asking it, Oh, what is the shape of this table? It has to guess through a thousand files, so

It has to recompile, basically,

It has to recompile.

It, it waits, yeah.

Or you have to launch the database, um, locally, Migrate, migrate, migrate, Run the migrations Migrate. Up, and then you inspect introspect the database, but that's too slow. So, basically, what we want to do is turn the schemas folder inside our our Supabase folder into a completely declarative state of your database, and so we've captured everything from tables, policies, uh, database comments, all inside these files. So we're releasing a new library, PG Dumpter, you can use it with any Postgres database, um, but we've got mechanisms for for Supabase, and so this is an important step for agents.

We know that agents are gonna operate mostly on code, they don't wanna reach out to anything. They gotta iterate very fast on the file system. So that's fine, and today, people are using CLIs, 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 you have an idea, you say to your phone, your DOT or whatever personal agent you have, I want to build X, and 1 second later, you kind of have this application live. You can iterate on 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 gonna 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 you're interested in, uh, I, is 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, uh, 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 wanna do it in this way? And but now, more and more, like, you don't need to, but my worry there is, are they all just gonna, like, converge on one way of building software?

Or Yeah, mold collapse, which You know, and

Is great. They're all gonna use Supabase, essentially.

Yeah, no, but but, like, the gr- the thing that's great about, like, the software development industry is, like, I e- uh, industry is, like, these are, like, famous flame wars, right? Of, like, What's the correct approach? Like, are we gonna lose that? Or,

Yeah, so you want diversity in ideas, So that the best idea can Win, and but then the models are just gonna make you so lazy that nobody even bothers to look at the details.

Yeah, and and they just all converge on one way of building software, and then that's, you know, is it gonna be, like, a local maxima in terms of

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

And which which will Which will then filter down eventually. Is is my idea.

But are these high skill people gonna continue to be trained by

Uh, I don't know, yeah, yeah, I Mean, I think I think people are p- passionate enough. Uh, I I it's one of those things where, like, you know, I do think, like, uh, you know, the average, uh, college is probably screwed, right? Like, they're you probably don't need to go to university anymore because you can probably self-teach and just, like, you know, g- uh, get get your own, uh, job. It's always been, like, this top tier of people that that are moving a lot of the the the needle, and you need to, uh, and and they will always find a way to have their own self-interests, uh, be satisfied, curiosity in terms of, like, what what is possibly better.

You know, the type of people that take a year off and go to the Recurse Center and just work on cool programming problems even though they could be making money in in industry and, like, yeah. Definitely. Definitely. What do you disagree on between the 2 of you? It's rare to have the 2 of you had, uh

Huh, yeah, that's a great

On on the pod, so, you know, I wanna 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, Yeah. The other person's like, Yeah, maybe you're right, let's let's try it. Yeah. Um, so we never end up in, like, big bust-ups, um, and it turns out, like, most of that stuff actually doesn't matter Yeah, it doesn't matter. Yeah, yeah, yeah. Yeah, Like, as long as the general direction is is correct, then then it's going okay, but, uh Yeah, I can't think of

Oh, you guys are really struggling here. Oh, my God.

Oh, I don't know.

Which is why, like, because it's it's never an important enough thing, like, we've never had a bust-up because it's never been important enough to actually fight hard enough on it, like and also we're fucking busy, so, like, usually, like, You got your head It's handling, In the right thing, Yeah, we're trying to Handle different parts of the Yeah, maybe it's Business.

Just, like, things are growing, And obviously, you've got your domain, and and you just need to work together, Right? Yeah. Yeah, it's interesting, you know, uh, so Laura here, uh, all 3 of us were in entrepreneur- first In Singapore. We were all different and work working on different companies, and then you guys stayed back after the cohort, uh, you were housemates after the cohort.

So we were all we lived in a house with 7 people, and we were all doing different startups. And so, and was doing his startup, I was doing another one. This is before Supabase.

And so, like, I think somehow your energies, uh, you know, you you you found that you were suitable working together and and working on this, uh, this Yeah, because, This project.

Like, traditionally, especially in in an accelerator model, you're pushed as a technical person to work with some domain ex- domain expert, right? And but in the house we lived in, it was basically 7 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, cause you are the subject matter expert as a developer, is that we could could just get so much more done, and so then we ended up hiring most of the other people who lived in Yeah.

The the flat as well as our, our Rory Employees, Rory, who's

Was the 1st employee?

Um, not the 1st, but the 1st i to on go to market, like, now he runs all of go-to-market.

Yeah, uh, the Postgres guy was 1st.

No, uh, Angelico. Angelico, yeah, we had Yeah, yeah. An intern An intern from my previous startup, We just dragged him along.

Yeah, and and then the other, like, 1st, like, full-time hire was this guy, Steve Chavez, who, um, who was the Postgres, Postgres maintainer, and the funny thing is we were in the YC batch, and the advice they give you in YC is like, Okay, we're gonna give you a bunch of money, don't hire anyone. It is the big temptation is to hire a 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 Postgres, and he was like, Hire him immediately, you know?

He was like, Forget the advice, go and get him.

What of his reputation, or because it made sense for Supabase?

Well, yeah, both. It it just made sense that, you know, this was a technology we were very reliant on, and We were gonna lean in, and it was like and the f- the funny thing is we hired Steve, and we said, Don't worry about Supabase, just keep building Postgres and just making it awesome. Um, and then, obviously, if we have support requests or whatever, we can we can ask them, But, um, 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? Um, one, obviously, there's a lot of slop, and and, Uh, I'm sure you guys are dealing with that. But two, also, your dependencies are now becoming, uh, optional. Like, you can just vibe code whatever you want.

Anything, yeah. Yeah, yeah. So I I Exactly.

I, whatever i i you, uh, is in your heads about the future of open source, I'd 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. Like, uh, and I was like, To what level are you gonna rewrite the database? Are you gonna rewrite Postgres? Postgres is not rewritten in, uh, 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 wanna be spending your actual innovation tokens or your actual tokens rewriting everything, so there's gonna be, like, a c- a collapse of almost every tool, probably into, let's say, it's Rust, if

that ends up being the the ultimate way of writing things cause 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 gonna 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 re written in Rust now? Yeah, probably, it could, and the mechanism, the 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 you're and you 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 The Language because of the BEAM, So and then you start thinking, when you're operating things, what is the right mechanism for operating, so

But now you can change paradigms eas- there pretty much easily as long as you fit all your tests, and, you know.

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. Uh, Malta fr- from Vercel is, uh, you know, one of his tweets that sticks in my mind, he's he's got lots of, uh, interesting thoughts. He set aside some amount of money and rewrite all of our dependencies, uh, at at the C level or C plus plus level into Rust, um, because we just know it is better, it's safer, more Correct, what whatever, and it is it is a one-time upgrade of open source, All the drivers, what whatever you you use.

Um, so, I I thought that was, like, a pretty interesting I like Call.

That as an idea, yeah. I don't

Call that.

Think it'll happen because people will love to do it themselves, But but as an idea, I I would like we as a company would 100% get behind that.

Awesome. And then, uh, I think closing question, which I I should have stuck in somewhere earlier, AI coding within Supabase, right? Uh, obviously, you guys are big beneficiaries of coding agents outside, uh, what is the policy internally? How much are you spending? Is there is there concern about spend? Anything of that sort.

Supabase has always felt like a bunch of different startups, like, glued together. So we have, like, the auth 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 kinda no different. Is, like, a lot of people ask them, What is the AI coding policy? And we were like, Well, just it's up to you as 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 wanna run things.

That's it. Very decentralized. I I I would say, um, 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, uh, what what are data points you can hang your hat on here? People say, uh, you know, the average, uh, person is spending, like, $20 a month, and then, uh, average employee is maybe $200 a month. OpenAI, uh, you know, uh, the the sort of 50th percentile is spending maybe $3,000 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, uh, a good metric is basically, what is your ratio of token spend to human spend? And it's rough like, for a lot of people, it may be 0.1, uh, tokens to to 1 human salary, and, uh, you know, you can probably go up to 1 pretty safely, and if you're over 1.5, you're probably in trouble, something like that.

So, I'll I just, I, say I luckily, as a remote company, basically everything that's Documented, Ever happened is documented, So I can ask our AI how much we're spending. So currently, we spend about 300 k per month.

Yeah, uh, for 600 people. No, for For, like, 400

450 people. People.

For 450 people. Okay. That like, it gives people an idea.

But but what you've said about, like, scaling the cost in terms of related to the number of employees makes sense, also for us, because we are hiring very quickly, so if we end up getting a lot of leverage out of just, like,

You should be, right? Actually, building something,

Then then fine.

You you need a whole bunch of serverless employees that can spin up and down as as you need, Right? Well, which is, like, Yeah, like, you know, I I just had a CTO of, uh, you know, a t another top startup say, like, he was worried about his company spend, and I'm like, Well, actually, you're that's your investment in everyone else, and probably it's very skewed, right? Like, there's there's, like, 2 or 3 people that are super insane at your company, and everyone else is, like, probably not using AI.

Yeah, 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 ashamed, so they kind of, Yeah, cause Like, they sort You're wasting Of, like

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 that 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.

Luckily, you know, as you saw, like, every single thing that's ever happened in Supabase is documented because we're an async company. So building a company harness, like, an agentic harness around Supabase, is basically just formalizing. You can point AI at it and say, What are our principles? And it will document document down all our decision-making principles for the whole history of Supabase. 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 are fully globally remote, so we don't care where you are, if you're a very Same same Good

Salary everywhere, right? Yeah.

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, uh, can you like one profile? Just pick one, whatever is top of mind as, uh, as your highlight for what you're looking for and why? SREs. Okay. Why?

Because we're just growing at a ridiculous rate, we need all the SR Es we can get.

What is a quality that is, like, you know, you you probably get a lot of SRE applications, and you don't look at them, like, what what stands out?

The thing that we really care about is that you you actually want to work remotely. Um, so it's it's this is a strange one, but, yeah, i it's true. We get a lot of quality people, but to fit in at Supabase, 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 graybeard that's, like, sitting in a dungeon somewhere and Doesn't wanna talk to humans That's the perfect Anyway. Great.

S that's the perfect person. All of those people, please apply at Supabase. Hopefully, they listen to this podcast.

Yeah, yeah, no, I mean, yeah, we we we probably do have a lot of, uh, graybeards, uh, in SREs. I I think one of I I have been on the record as saying AI SRE is one of the hardest categories for For agent startups. I think I might be wrong soon, but so far it's been correct. Like, so, AI Has not cracked SRE for for whatever reason.

No, no, no, not yet. I agree. Like, uh, building software is, you know, debatable. Solve problem, maintaining, like, keeping things running Is 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

Thanks, guys.

Friend, uh, and and an investor, and and it's just like, just see the progress. I cannot wait for the IPO, whenever that is. Uh, it looks like it's gonna take some more time, but it'll it'll be it'll be fine. I I really wanna see you guys, like, you know, do the whole ring the ring the bell and, you know, building the next great open source company, right? Excellent. Definitely, man. Thanks Yeah, Thanks for having It was a For having Great chat.

Us.

Us.