Supabase’s Plan for a Billion AI-Built Apps

Okay. This podcast has been 6 years in the making. We’re excited to have Paul and Ant in the studio. Welcome, guys.

Thanks. Thank you. Thanks for having us.

We’re recording this ahead of Supabase Select, your big customer conference, and we’ll release this after the conference. I just wanted to celebrate the journey you’ve been on. I’ve been following you since you finished YC, when you were in Singapore celebrating, and I met you for the first time. I remember thinking, “What is this hot database company that got a soft launch on Hacker News from some random user sometime?” Anyway, congratulations on all the success. What are the headline announcements at Select? Let’s get right into it.

Sure. There are quite a few headlines, and we’ve got a lot to cover. The main one is Supabase Compute. We offer a product called Edge Functions, powered by Deno, and they have a 2-second limit. What we’ve heard from our community for a long time is that they want to run much longer workloads, like chunking and embedding.

1. Compute and Postgres Performance

By the time this comes out, we’ll have announced Supabase Compute. You can run anything in it: it’s long-running and serverless, and it runs in the same private network as your database, so it’s co-located and has very good latency. You can run Postgres connections directly from Compute. It’s no longer constrained to Deno; you can use Rust or Python, or run agents inside it. It’s basically a full compute instance.

What would be the comparable offering in other clouds that people might be familiar with?

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.

We have 3 innovations in the database space. The first is OrioleDB, which we talked about last year. We’ve put it through the wringer over the past year to make sure it’s rock solid and ready for the Postgres ecosystem.

The 3 innovations are performance, scaling up, and scaling out. OrioleDB addresses performance. It’s a drop-in replacement for the current Postgres storage engine, heap, and it runs about 1.5 to 2 times faster without requiring you to change anything else. It’s completely compatible, and it removes the need for some of these background tasks, like vacuum and bloat, so it’s very efficient for your database.

The work we’ve done this year included testing it with pg_regress for full Postgres compatibility, Antithesis, nightly TPC-C benchmarks, and Jepsen, to make sure it can never lose data. We’re releasing it in full beta tomorrow, and we’ve also made it Apache 2.0 licensed. It comes with a patent, and the Apache 2.0 license covers the patent. We acquired the technology, continued to develop it, paid for the patent, and are now giving it away for free.

One thing you mentioned in passing that I still can’t get over is that you tested every operator and said every operator drops data in some situation.

Well, that’s the second one, scaling up.

I see. So that’s Multigres.

Yes. We looked at the Postgres ecosystem and all the operators. For those who aren’t familiar, when you run Postgres, you start with a single node, but with almost any database you want to run multiple nodes and have things like failover and backup management. Usually, you have an operator that can run the entire cluster for you.

There are quite a few operators in the Postgres ecosystem, and we found that under certain conditions, every single one of them could lose data. So we decided to do a ground-up rewrite of the entire structure of an operator with Multigres. Our initial goal was to bring sharding to the Postgres community, but what this has turned into is an entire operating system.

We ran it through very rigorous testing. We’ve done 1,000 sequential failovers without losing any data, and we’ve tested it in basically every way we can, clobbering it to see whether it will ever lose data. We’re very confident in its stability, so we’re releasing it tomorrow as well. It’s completely open source. It’ll be on our platform for customers and invite-only, so people running serious workloads can come to us and we’ll start helping them scale up.

Is this the full completion of Multigres, so it’s fully parallel to Vitess? Or is there still something left to go?

No. It’s quite interesting: Sugu originally created Vitess for the MySQL ecosystem, specifically for sharding. When he came along, he said, “The number one goal this time, because we’re always catching up on compatibility when we use Vitess, is to focus only on compatibility first.” You always had to change things as you moved to sharded, including changing some queries.

He said, “I want to focus only on compatibility first.” We’ve designed this ground-up rewrite so that when we release sharding, you won’t have to change anything in your database. You’ll continue to run the same queries, and Multigres will handle it, with zero changes to your code.

That’s an incredible vision, and the fact that you’ve been able to do it in 2 years—

That’s 1 year.

One year.

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

I think this is the last piece for the total domination of Postgres.

Yeah.

Right? For those who don’t know, look up Vitess. It powers YouTube, GitHub, everything.

Yeah. If workloads were ever to shift away from MySQL, you need this for Postgres.

And that’s for Supabase to win. Hopefully it’s not just for Supabase customers, right? It’s fully open source, for the open-source community. Anyone running Postgres at scale should be able to use Multigres. I’m sure every company involved in Postgres in some way is contributing to this thing, right? Because we all want this.

Yeah. We’ve got a whole design partner program. We’re working with Booz Allen, Postman, and Perplexity. Lots of customers are coming on board because they need it. They’re running Postgres at scale and need something to help them scale up.

2. A Database for Every Idea

The third one is scale-out. At the moment, we launch about 5 million databases on our platform every month. We think the future will require us to launch billions per month, and scaling out is a whole different beast. So we decided we’d have to look at new architectures and people in the agentic database space. There’s no other leading database provider that does agentic well than Turso.

By the time this is announced, we’ll have announced that we’ve acquired Turso to help us power agentic databases.

That’s incredible. They’re primarily SQLite-based, but it doesn’t really matter, right? It’s more about the architecture. I guess I don’t have the word to describe it—is “broadcasts” the word? For scale-out, right? The idea behind scaling SQLite was that they’d have a single writer and multiple readers.

Yeah. SQLite itself is single-writer; it’s a file format, so generally it’s not thought of as—

Like sort of an MVCC for SQLite.

Exactly. They built this Turso architecture, which basically builds MVCC for SQLite so you can have multiple writers.

And then it’s also—

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

They had to fork it.

They originally started with libSQL, and then they came along and did this other really cool architecture. The architecture was discussed a lot a few weeks ago, around S3. Some of the innovations in the database space are coming out of what’s happening in object storage. Object storage has added a bunch of new features, which basically mean you can start using it a little bit like a database. And because object storage itself is, I think, 11 nines of data—

Durability.

Durability. Yes.

Which is not reliability, but whatever.

Yeah, not reliability. But it gives you what you need for what you’d typically have with a cluster of databases. It’s kind of like your cluster underneath.

So you can start doing some cool things. There are quite a few popular databases now, or data use cases, that are built directly on top of object storage. It has some limitations, in our worldview. It’s probably good for smaller use cases in terms of transactions, because with a transactional database, you’ve got to do a lot of reads and writes. In this case, you probably don’t want to be doing something at massive scale on it, and that’s why we have Multigres.

For what we’re seeing, and where we need to get to—these billions of databases—what we need them to be is a file format. That’s where SQLite was super interesting. SQLite is king. It’s dominating. The thing that really piqued our interest was that I reached out to Glauber. He released a blog post on how they’d done their rewrite, which basically gives us a pathway to Postgres compatibility with their file format.

We’re acquiring them, and we’re actually going to keep the Turso brand. Turso’s going to focus on SQLite, and then we’re going to introduce this new, smaller instance type on Supabase called Supabase Spark. It’ll be compatible with all our libraries, and you can have one database for any idea or prototype you want. When it takes off, 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. Scaling up and scaling down have both been things we’ve been trying to figure out how to do.

Yeah. It’s really when some of these innovations came along that we realized, “Oh, okay, we can do this.”

You’re going to 5 million a month, let’s say, and you see a trajectory toward billions per month. One of the secrets is that they’re actually kind of small databases. These things are tiny. They’re vibe-coded apps. I don’t know if you have any insights on what features come with that.

Yeah, I mean, until they get traction, right? Once you hit the front page of Hacker News, you need to know that you can go far beyond that. The whole idea with all of this was that we need to make sure we’ve got a really smooth pathway to migrate between the backends, with zero-downtime migrations. It’s a need to have.

We see a lot of non-technical builders building whole companies now. We have a customer, MagicSchool, and the guy was a teacher. He saw all these inefficiencies in teaching, with teachers spending time on tasks that could be automated. Now you have these startups that start without a technical co-founder, without a CTO, and that’s not an isolated incident anymore. It’s becoming more common.

Everyone’s a builder now.

And that’s why we’ve seen the growth we’ve seen over the last 18 months. It’s crazy.

It is. But it still feels early, and I think there’s a much larger market of almost consumer-like builders: people inside companies, people who want to launch their own startups. That’s going to mean a lot more databases. If we give everyone a dedicated Postgres cluster, we’ll probably run out of physical computers in the world pretty fast.

Which is basically what’s happening. We’ve faced it throughout this year, and our growth has been one of the things we’ve had to deal with in terms of compute capacity.

3. From Memes to Cloud Scale

So, congrats. Also, I feel like Glauber is a meme lord.

Yeah. That’s one of the things why we like him. I mean, come on.

For those who don’t know, the person behind the Supabase memes is this guy. Low-key a killer, I would say—and Glauber, too.

Yeah, yeah, yeah.

I don’t know if you guys exchange notes on what’s funny and things like that.

Not yet.

No? Really? That never came up?

We’re going to give him access to the Supabase Twitter account for sure.

Oh my God. I could do with some help. 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—a meme workshop, basically. It’s hard to hire for because you need to understand the tech and what developers find funny in order to do that type of marketing.

Actually, you’re also low-key a meme lord.

I’m not as funny as you. You’re really, really funny.

Where’s that one with the seagull? You were standing on top of a turtle, on top of Postgres, with the seagull.

Ah, yeah.

It was a standing seagull riding a flying seagull. Oh my God.

Yeah, yeah.

This is all deep Supabase history. There was a time when those things were so good, people wanted to be like you, and they couldn’t. That was your moat: memes.

There were some big companies trying to run memes off their Twitter accounts. I won’t name any names, but they were very large organizations. But yeah, it’s hard. Like I said, it’s hard to hire for.

The guy who did a 40,000-word essay breaking down your meme strategy—

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

Yeah, on Hacker News.

That was funny because they recorded the strategy in a way that we hadn’t committed to paper yet. So when we onboarded new marketing people, we were like, “Here’s the strategy.” It was written by someone else.

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

I found it. I found it. This guy. “Learnings from four months of Supabase’s feed.” He just looked at your work for four months. When was this?

2022.

Okay. Yeah, yeah, yeah. Wait, I mentioned it? Ooh, okay. There you are. He just broke it down.

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

Your hate just fuels me. What is this interesting article? Okay, so I commented.

A lot of our growth was thanks to Hacker News. In the early days, I just kind of lived on there.

So we should talk about that. What deal with the devil do you have to do with Dang?

We’ve been scolded by Dang many times for launching too many things in a week.

Yeah, we have been.

He’s rightfully paranoid about the association between Hacker News and YC. If something happens, he kind of wants to throw us under the bus so people know, “Oh, we’re not doing this for YC customers. We’re an independent site.” He’s been helpful in making sure we don’t smear the name of YC or Hacker News.

At this point, you don’t need them. But Dang has super-high credibility. No one really questions him. You guys innovated the strategy of launch weeks, and for a while, I think there was one launch week—four or five—where every single launch was number one or on page one of Hacker News.

I got told off so badly for that because I tweeted it proudly.

What?

I was like, “Oh, here we are.” Then I got told off because it basically looks bad when this YC company is suddenly dominating the front page of Hacker News. It looks like it’s biased. Parading the fact that you’re on the front page—

Which is true. A tip to anyone: never screenshot the fact that you’re on the front page of Hacker News and put it on Twitter. It does look like we’re—

And, to be honest, it was gloating, so it’s a fair call-out.

I’d consider that ancient history now. It’s been a few years since it was relevant. But for those who don’t know Supabase history, these are things you have to check off on the tour. What else?

I think the top post there is interesting because it was someone else who launched us. We weren’t ready to be launched on Hacker News.

Maybe. And you didn’t consider yourself a Firebase alternative?

Oh, yeah. That was the day we changed the tagline. We had the tagline—

What was the original tagline?

It was “Realtime Postgres.” What had happened was, we were like, “Let’s build a Postgres company.” But at my previous company, I had to migrate from Firebase to Postgres, and I needed a real-time feature, so I ended up building this real-time engine on top of Postgres.

And so we thought, “That’s the killer thing. It’s getting some open-source traction. This real-time engine is kind of cool.” So we were like, “Realtime Postgres.” No one cared. No one cared when we had a website, so we were like, “Let’s change it to ‘Open-source Firebase alternative,’” knowing that was the reason I switched.

I think it was only 12 hours later or something like that that this article went up.

Yeah, yeah. Still the top of all time.

At the time, we were running on DigitalOcean, and every new database was 2 droplets: 2 $5-a-month droplets.

Why 2?

One for the database and one for the APIs.

Right, because we—

Because we wanted to upgrade the APIs and decouple them.

Independently, yeah.

We only had a handful of test users at that point.

Yeah, yeah.

And then all of a sudden, we got—I think we only had 8 users.

Yeah, we went from 8 to 800 on that launch alone.

And then we burned through, I think, $10,000 in DigitalOcean credits, which we used up in basically 48 hours. We’d just gone to YC, so AWS was like, “We’ll give you $150,000 in credits if you migrate to us.” We spent the first week of YC migrating 800 databases to a different cloud. If you’ve ever migrated 1 database, you know how painful it is. Migrating 800 is not how you want to spend your first week in YC.

That’s crazy.

Do you remember that we could have been on DigitalOcean? Basically, we should still be building on DigitalOcean, because when you get into YC, they had this huge credits program at the time. We were like, “Hey, can we have these credits? We’re blowing up here.” And they said, “No, you’ve already used the $10,000 credit program. We can’t give you this other one for $300,000.” So we were like, “Well, we have to migrate to AWS.” The biggest lost opportunity for DigitalOcean ever.

Being too strict, yeah. I know our bills with AWS now—this is nothing. We’re probably one of the biggest customers they ever lost from being too strict about that.

But because it was COVID, it was a time when everyone was worried about what was going to happen.

Yeah, sure. So I think they were like, “We don’t want to overextend ourselves.”

It’s fair.

Yeah. It was totally fair at the time, just given the way the world was looking. People made many irrational decisions during COVID.

You never know. I was going to say, you might be worth more than DigitalOcean now, but then somehow DigitalOcean has also gone on a super tear.

Ah, cool. Look at this.

They tripled in the last year.

Wow, that’s cool.

So what are they, 16?

They’re $16 billion now.

Billion, yeah. Okay. And I guess there’s a shortage of CPUs.

Yeah, there’s a shortage.

How are you guys experiencing it? Is there a way to scale up when you have a spike? What do you do? Do you just have agreements with people to—

Yeah, we’ve got to plan very closely.

You just pay more?

Yeah, we pay more. We partner with them. In fact, tomorrow we’re announcing that we’re bringing on a new investment partner, CapitalG. CapitalG basically has access to the Alphabet ecosystem, which is good for us on both sides. We now have to consider a multi-cloud strategy. We need GCP, or we need more compute, basically, so GCP is a very obvious choice. Of course, we want to partner with all the AI labs as much as possible. They have a suite of products. We already work with them on Gemini, and we want to make sure we’re embedded deeply into all of their products.

And that’s another thing you mentioned: so much of the database ecosystem is being shaped by block storage and all these innovations. Clearly, AWS is the leader there. It’s hard to be multi-cloud if you’re going to use GCS as 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 whatever S3 does, others follow.

I still remember, I think it was 3 years ago, they introduced strong consistency.

Yeah, that’s the innovation that helps.

Right. They did it for free and just rolled it out to everybody. It was like, “It’s live now.”

Yeah, yeah. And S3 Express was a big game changer.

Why?

Basically, you typically write to a local drive, then batch it to something more durable. That batching process takes time. The write times to this are 1–2 milliseconds, so before you can guarantee a write back to your client, you basically need to batch it to something that’s durable. This one’s durable—not as durable as S3, not 11 nines, but durable enough.

Got it.

It’s ephemeral durable.

Yes, exactly. Then, in the background, you use this kind of as your cache and move into S3, which is cheaper.

Do we need Redis anymore?

Yes, you still need Redis. This is nowhere near fast enough. Your cache layers are basically memory, an NVMe drive, locally attached storage, S3’s equivalent, and then regular S3.

Amazing. That was a little bit of database. We jumped around quite a lot. A few more things: your slogan was “Build in a weekend, scale to millions.” Now it’s “Prototype to petabyte,” which is excellent. It really reflects the evolution in scale that you guys are doing. Do you have anecdotes about early Supabase versus now? How fast are people scaling when they start something?

The big thing is how fast people are monetizing. At the start, it was like: you choose your database, you build your product, and at some point you add billing. Now, because you can add Stripe at the agentic layer, we see customers starting a project and, within the same week, generating serious cash.

Yeah.

In the early days of vibe coding, it wasn’t obvious to us that this was something that was going to stick around or change the way software is built. But as soon as we saw someone earning—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.

There were waves we’d ridden successfully in the past. When NFTs were huge, we leaned in a bit and added sign-in with Ethereum and sign-in with Solana. But we didn’t dedicate tons of dev time, because everyone kind of knew it was going to go away at some point. With vibe coding, we discussed a lot as a team how much to lean in. It was a time when we knew we needed to go slightly more upmarket. Our biggest customers were stretching the limits of what we had at the time, so we knew we had to do both: innovate on the small, prototype side and on the much larger side as well. You just need more people for that.

That one’s funny because, on the numbers side, basically, for Supabase, there have been 3 chapters of AI. The first chapter was embeddings. I think we were on—

Supabase Vector.

Yeah, which I’ve now transcribed, and it will always—

We should probably update this, because—

Yeah, yeah. It’s probably super—

We did this talk. Basically, all these embedding databases and vector databases were coming out. We were pushing the fact that you can use Postgres as a vector database, and Andrew Kane, a completely independent guy, developed this awesome extension. We were trying to educate the market: Postgres can kind of do anything. You don’t need another database if you’re going to store your own embeddings. That was chapter 1, and it was a really good growth driver for us. It was also good for the Postgres ecosystem, just letting people know. Now there are a lot of innovations in embeddings. Turbopuffer, for example, uses a lot of the innovations that Turso is doing, and I think it’s a phenomenal use case for that type of stuff.

Chapter 2 was the vibe-coding wave, with Lovable, Bolt, and all of these ones coming along. That was the end of 2024, and that’s where we debated a lot: “Do we really want to be there? Do we want to be servicing these? Do we even want to have our own vibe-coding platform on top of Supabase?” In the end, our mission is to store the world’s data. To do that, based on our tagline, we want to be there when you’re getting started and make sure you never want to leave. We saw people getting started and doing toy things, but it still fit our mission. We just had to believe that, over time, these tools would get better.

Then the third one, which is driving the crazy numbers at the start of this year, is that the models just got better. We started seeing our top of funnel, our sign-up rate, rapidly increase.

But usually when this happens, you’re pouring a lot of dollars into marketing.

Mm. We actually barely spend any dollars on marketing. Most of it is just memes and things like that.

Here, I got one of your charts.

There we go.

Yeah. All your charts look the same because they just keep scaling exponentially.

Super weird.

You just keep—

But—

—changing the Y-axis. The other crazy thing about this is that often, when you get more consumer-like traffic at the top of the funnel, your activation and conversion to paid go down.

Yeah.

But both of those things went up. They started going up quite rapidly as well.

Yeah. Yeah. Actually—

Because of the model.

How do you know activation and conversion to paid?

Oh, at Supabase?

Our metrics, yeah.

Ah, your funnel metrics. Okay.

The reason is that the agent does the sign-up-to-activation step for you in one step, so it’s almost 100%.

Yeah, the friction’s gone.

Yeah, for us. Those users were then converting to paid at a higher rate than our traditional developer user.

Okay. Excellent. It’s great. Yeah, frankly. But I’m sure all developer tools are seeing the same thing, right?

Yeah.

Well, at different rates. I think you guys are clearly one of the leaders there. I was going to bring up one of these things. I have this AEO tracker, where if you type in Supabase, there are a few categories where you’re the leader. Basically, it’s led to every single frontier model recommending you as its primary choice for an integrated backend.

What does “integrated backend” mean?

Your original offerings: auth, functions, your database, and all the other stuff, like APIs. I think it’s interesting that you had to be in the market for 3 to 4 years—exactly the right amount of time—before LLMs took off, and then present yourself as the leading competitor to the leading thing at the time. Then you can take over.

Yeah, yeah. We’re very lucky with our timing. We couldn’t have timed it better. It was a complete accident.

On first-principles grounds, we’ve interviewed other founders who maybe started post-LLMs, and Resend was kind of there. We’ve also talked to them about why their LLM keeps recommending Resend, and it’s because they have a lot of good AEO practices.

Sure, yeah.

And of course, we invest very heavily in that.

When we’ve been at that point since the start, that was an accident. Now we just need to maintain that lead. And community as well, right? One of our early growth strategies was to spend so much time with the community. It resulted in people writing blog posts, making YouTube videos, and putting out podcasts about how to use Supabase and in what situations. They’d say, “Here’s how I built this thing.” I’m sure all of that just got slurped up by the models.

Yeah.

And open source helps as well, of course.

Yeah, yeah, yeah. Being open source. You had a fun announcement on the community side, because you’re raising so much and trying to involve your community more deeply.

Yeah. Last year at Supabase Select, we announced that we were going to do a crowdfunding round. It’s something we’ve always wanted to do, and we should have done it much earlier, but we had so many other things going on. We spent the last year fighting with the lawyers, who said that for the number of people we wanted to involve, there was no mechanism to do it without them being accredited investors.

Then we asked them, “What if they don’t invest? What if we just give them the stock?” They said, “Yeah, we’ll look into it.” Then they came back and said, “Actually, there is a mechanism where, if you really just want to give the stock away, you can.” So we’ve earmarked $1 million in Supabase stock that we’re basically going to give to a bunch of community members.

The first community member we’re going to bring onstage and announce is this guy in the Supabase Discord. His name’s Gary Austin, and he’s a legend in the Supabase community. We looked into his stats: Gary has answered 20,000 questions in the Supabase Discord in the last 6 years. The crazy thing is that he answered 13,000 of them within the first hour of being asked.

And he’s not a Grok bot.

He’s a real human.

Have you met him? What’s his—

Yeah, we’ve met him. He was basically retired and just interested in Supabase.

Gary Austin? Or Gary Abbott?

Yeah, Gary Abbott is his real name. He loved Supabase because he basically built his own sommelier app—he loves red wine—and he was getting a kick out of it. He’s got the Supabase logo on his Christmas tree.

By the way, this is my favorite Supabase meme. You reminding me that I’m about to run out of my Supabase.

That’s the announcement. Anyone who’s a legend in the Supabase ecosystem, we can now—

Is Discord still a strong community platform? I have mixed feelings about Discord. It’s the best chat; Slack sucks. But it isn’t public, so all the work in there isn’t scalable. Have you found anything to solve that?

There were some tools we looked at in the early days. We decided not to do it because you still needed to police what you wanted to be public and what you didn’t. The original debate I remember having was: “We want to host the community. Do we use Discord? Do we do a Slack community? Do we do a Reddit?” We tried a few different options, but landed on this: 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.

And be where they are, yeah. That’s the answer.

There was a lot of work.

Yeah, and it worked out. That was the right answer. There are a lot of great tools that started popping up, like Orbit. I don’t think any of them has stood the test of time, though.

No.

There are tools that mirror Discord to a public Q&A site. I don’t know if that’s been successful for anyone.

Yeah.

Common Room helped a lot. The only thing we did was build something for ourselves. If someone asked a legitimate question on any of these platforms, we scraped the question and response into our own website. Actually, we scraped it into GitHub Discussions and mirrored that on our website, so the content was getting slurped up.

Ah, you used GitHub as a CMS.

Yeah, we used it as a CMS. It was a great strategy because everyone was asking the same questions over and over again, so we could surface them each time.

That’s true. It can be confusing because there’s Supabase the open-source project, and then there’s Supabase the cloud platform. Most people are probably coming to support for Supabase the cloud platform.

Yep.

Do you have any idea of your open-source market capture? This is something people in developer tools circles know about.

We quite deliberately don’t know.

Don’t know?

Yeah, we don’t put any tracking in our open-source offering. You can use it. 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?” 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, though.

Oh, come on. Why not?

Because it launches tomorrow. I don’t know if we’re announcing it tomorrow, but it’s basically Control Tower. It’s a fleet view. We have this very popular product, Supabase for Platforms, which is what all these AI companies are building on top of. We launch millions of databases for them, so all we needed to do was repackage this for enterprises.

Enterprises want to do the same thing: spin up many internal Supabase instances for all their users, and then see and administer them. Control Tower is essentially a repackaging of what we’ve already been developing for these platform providers, but specifically for individual enterprises.

Oh, okay. I want to cover the work you’ve been doing on the enterprise side, because I think a lot of people think of you as bottoms-up GTM. First of all, shout-out to Wenmo [?]. I think this is your most successful recent launch, which is—

Supabase for Platforms.

Yeah. This one launched in—

Yeah, yeah. I mean, December 2025, so.

Yeah, but I saw some stats. You guys call this successful; I don’t know. What is the enterprise story apart from, “Give me a dashboard”?

4. The Greenfield Enterprise Play

Well, first of all, we should talk about sales strategies.

Okay.

Supabase is famously a PLG company. We have 60% of every YC batch using Supabase. We focus almost all of our attention on becoming an index company. Basically, our role model is Stripe. We want to follow in their footsteps. They’re one of the only developer tools we’ve ever seen that has withstood more than a decade of moving upmarket while still keeping that developer love.

To do that, when we started doing sales, we layered on what we call product-led sales. We look for product triggers. It could be a logo—someone we think is really important—but more often, they could be scaling up, hitting some limits, having errors, or paying a certain amount. We’ve got a bunch of these triggers, and then AI came along, and we thought, “Oh, we can do some interesting stuff with this.”

Let’s say we have 1,000 product triggers every single week. We send 1,000 emails to people who are having problems, and say 500 of them respond. We take the cohort that doesn’t respond and use them as a control group. We measure how much they grow. It 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.” Because we’ve got all their traffic patterns, we can give them a script. We know what their problem is. AI has been great for this. We give them a script just to help out, and it turns out that just getting on a call and helping people means their account then grows 125%.

That 100% uplift—the incremental uplift—is what we compensate our salespeople for. Traditionally, you’d say, “Get on a call with these people and just sell them stuff,” and then they’d get the full quota. But because we know our database grows, our platform grows at 25% month over month for this cohort of users, we know that our sales force is 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.

The likes of the enterprise are usually coming in because they want to launch lots and lots of databases. Almost never is it a transfer of their production database. Migrating databases from, say, MySQL to Postgres, or from one scalable database to another, almost never happens. That was the core thesis of Supabase at the start. We knew that every Postgres company, or database company, we’d 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 1 and then make sure they stick around to day 1,000, day 10,000. So all of our focus is on winning these enterprise logos on day 1.

Greenfield.

Greenfield, yeah.

They’re still not migrating?

I guarantee they’ll almost never migrate. There’s a cohort that will need Multigres. We’ve talked to some logos who are looking at using it open source. They’re very interested in making sure they can help direct us, because they’re running into problems with Postgres at scale.

But for the next 5 years, almost all of our focus on the enterprise side is making sure that we can handle greenfield use cases. In the enterprise, it turns out to be a very prolific use case because they want all of their product people developing and 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 one of our biggest things. Multigres, of course, gives us the opportunity to win these large workloads if and when they ever want to migrate. But it won’t ever be one of our core focuses, or at least not for the next 5 years. We’re going to have to focus really heavily on landing inside these enterprises and then expanding up.

The other thing that’s changed is that, obviously, in the past, we put all of our focus into developers. It was about selling to the developers and enabling them as a champion, so they could help you sell internally. Interestingly, now we have CPOs who are like, “Wow, I didn’t code for the last 10 years, but now, because of Lovable and Supabase, I’m building all these things internally.” So now we have champions at the C level without needing to put a huge motion around that.

Oh, that’s great.

Yeah.

Mentioning Lovable, mentioning Bolt: Lovable is going to have their own database stuff, and everyone is going to try to intrude on each other’s turf, which is normal in the grand scheme of things. Which is more sticky? Is the CPO more likely to be married to Lovable or to Supabase? Is that a question that comes up?

That’s a great question. I think ultimately, running databases is very hard.

Fair enough. And, as we just discussed, it’s harder to migrate your database than it is your—

Yeah, yeah.

—front-end tool. Not that I don’t think Lovable is sticky. I think it’s amazing.

Actually, they were the first people to do a really good job of making sure their agent didn’t do stupid stuff with the database. Very early on, the agents were trying to shove image data into Postgres. They were turning off RLS to get their projects to work.

Hmm. By paperclip maxing, basically? Lovable wrote really good skills to stop their agents doing stupid stuff?

They were the first.

That’s the secret sauce.

Yeah, yeah, yeah.

It’s to solve all these—

And now the models themselves don’t do that stupid stuff anymore.

Yeah. The situation has improved a lot. It’s gone from Will Smith eating spaghetti circa 2022 to Will Smith eating spaghetti in 2026.

Yeah.

And that’s a famous meme. I’ll leave the migration point alone after I mention this. One of the things that gave me a big aha moment was when I met Karen from Coatue, one of your board members. Her thesis is that you’re not just replacing Firebase; you’re also coming up as a new RDS for Amazon.

If there was a stage 4, a fourth era post-AI for Supabase, what would it be? The 10x in your growth: rip out Oracle. I don’t know. Is that the white whale there?

That’s the one that the famous migrations are after. I heard some crazy stat like that. It might be different now, because Oracle is trying to move everything to the cloud, but I think 1 year ago someone said that only 5% of Oracle workloads by revenue ran in the cloud.

So almost everyone was saying, “Oh, let’s rip out Oracle. Let’s do migrations.”

That’s what I mean, though.

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 wouldn’t we try to do this? But it is incredibly difficult, and I think you’ll want to focus, first of all, on landing inside the enterprise.

Yeah.

That makes sense. When I talk to coding agent people all day long, the great promise is that you can finally migrate off all this legacy software that you have. Hopefully, that means you can cut over everything.

That’s true. One of the things that actually makes Oracle so sticky is that you end up writing these million-line stored procedures. You stuff everything into your database, so rewriting that is probably a lot easier these days.

Right. So hopefully coding agents are the boon. Maybe they’re not there yet. Maybe you guys have to become more on-prem.

Most of the problem around migrations is actually not rewriting it. You can do migrations, for example, on the data analytics side quite easily, from one warehouse to another. The problem is that usually your OLTP database is powering your most revenue-generating application. A minute of downtime means that you end up with dollars lost.

So then what you end up doing is having to run these 2 things in parallel. The risk is that you get this split brain, where you’ve got some data running on one side and some on another. If you try to reconcile split brain, anyone who’s tried to do it knows it’s a very hard problem.

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. They’ll start new workloads, do a lot of operations there, and hopefully migrate things over.

Yeah. Usually then you’ve got 2 problems, though. Speaking of OLTP, this is just my own database indulgence: we also had 2 of the co-founders of Databricks here, Matei and Reynold, who are making the claim that they’ve solved HTAP.

Okay.

Yeah. It’s sort of the white whale of database people.

Yeah, yeah, yeah.

Traditionally, you need an OLTP database and an OLAP database. Never the two shall meet—except sometimes you’d like to never have to replicate anything. Are you paying attention to that stuff at all? Is there a story there for Supabase someday?

5. Where Analytics Fits

Yes, we’re particularly interested in DuckLake. I think DuckLake is very interesting, and DuckDB is a very interesting technology.

Is it MotherDuck, but a data lake? What is DuckLake?

DuckLake. Okay, so—

DuckDB—

Yeah.

There’s DuckDB, which is basically like SQLite for analytics.

Columnar storage.

Yes, exactly. It can read directly from object storage. That’s typically how it’s touted, and it can read from your Postgres database as well. It’s open-source, great technology. There’s also DuckDB Labs, which was recently acquired by AWS.

Yeah, so they’re a foundation—

Mm. That’s good technology.

—that’s developing it. They’re building a committee around the open-source project. I 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 the Netherlands?

Yeah, exactly. They live and work in the Netherlands, which is pretty cool. Our interest, mostly on the warehouse side, isn’t trying to make Postgres an analytical database. It’s about using the right technology for the right job.

I don’t know about HTAP. Many people have tried to slay the HTAP dragon. Object storage could be the solution, but generally, we think that once you get to a certain size on the OLTP side, you need sharding. There’s a limit to how much NVMe disk space you can have, so if you need to split a transaction across 2 servers, you’re basically fetching it from object storage. Eventually, that will slow down your database.

We think sharding is by far the best way to scale up into the petabytes, and then you should treat your analytics differently. That doesn’t mean you shouldn’t store your data directly on object storage, for example, and read from it through a different route. But trying to smash the two together doesn’t necessarily make that much sense, in my opinion.

I’m happy to leave it there, because we have more to work on. I do think they have some innovations where they’re basically using their spare compute on their database machines to power all this replication. That’s my read of what they’re doing.

Yeah.

To be honest, I haven’t looked so much into how they’re doing HTAP, so I could be misquoting.

Yeah, exactly.

You’re in your lane. It’s not exactly like your customers are banging the table asking you for this. It’s just that if you want to become the preeminent database company, someday you have to have an answer.

Yeah. Exactly.

The other thing I’ll check in on is durable workflows, and that world. As you know, Temporal—

Yeah, yeah.

I’ve been banging the drum for a while.

You’ve made—every year you do a little thing.

Yeah, yeah. We’re incrementing our way towards it. But how come it’s not more P0 for you? 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.

It’s a super interesting space to be in. We’ve had people in the community try to build workflow engines on top of Supabase Functions, and it just didn’t work because of the 2-second timeout. Now we’ve got the primitive that would unlock the ability to do long-running, durable workflows.

Yeah. I think my original pitch for Supabase is that you want the all-in-one, agentic cloud: the integrated backend that people can use. You’ve got Sign in with ChatGPT now, which is a great part of it. You just have to give the AI everything at once, and then it will be your best friend.

Yeah, pretty much. And be prolific. Our P1 strategy is to partner with as many of these frontier labs and models as we can, so we’ve got to be prolific there. We also see our attach rates going up.

Obviously, there are the U.S. labs, and you’re here in the U.S. Do the other labs have significant partnerships? What are they like? Mistral, Cohere, the Chinese labs—I don’t know if—

Not so much.

I don’t know what’s in your—

Well, they might.

Okay, you primarily care about the U.S. labs.

Yeah, yeah, yeah.

Okay, that’s fair enough.

Mainly because that’s who’s delivering the most traffic at the moment. That could change.

What does partnership look like? It’s one thing to be on their app store; it’s another thing to be the default when you launch an artifact.

That’s super interesting for us. Hopefully, we can be one of those providers. One of the reasons we couldn’t in the past was that we just couldn’t handle their scale.

Take ChatGPT, for example. What have they got now? 1.2 billion monthly active users. If one of their users launches a database every single month, we’ve got to launch 1.2 billion Postgres servers. As I said, we’ve got to get to billions of databases per month. We just haven’t been able to do it until today, when we acquired a company with technology that can drive it up. Scale up, scale out.

Other than that, what are the other P0 objectives for the company? Over the next year, how are you guiding the direction?

P0s are basically: win the strategic labs, win the models, and continue our PLG push. Then P4 is enterprise.

I like how P4 is enterprise.

They’re one, two, three, four. Those are the four in terms of rankings.

That is the truth of it. Where we’re focused on enterprise is winning these new workloads. It’s more that the ceiling of PLG has lifted. When we started the company, we thought, “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 in terms of motion.” But because of AI, that ceiling just lifted, and we don’t know where it got lifted to. Is it $1 billion? Is it $2 billion? We could just keep going.

But we still want to do the other stuff as well. Last year, we were like, “Well, we have to do both.”

The small stuff and the big stuff.

Maybe we’re a bit greedy.

No, I think it’s what people want, right? They’ll pay you to handle the fine-grain details of moving up in terms of orders of magnitude. I don’t know how many orders of magnitude that is, but quite a lot.

It’s just crazy, because if you’d asked us 18 months ago, we were growing fast. If you’d said, “What can you do to 10x this top of funnel?” I would’ve said there’s nothing. It’s crazy. Then this whole market just exploded, so let’s see what happens.

I remember at our company offsite at the start of the year, we put out this crazy ambitious revenue number. Someone came up to me and said, “Oh, you shouldn’t have said that number. 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.”

It took us about 4 months to hit the number. It’s a ridiculous growth curve from the start of this year.

Amazing. What are the open questions you have? If you had a crystal ball, what would change the way you bet on things?

How development will be done, and what people will develop. Those are the 2 things I think a lot about.

What are the possible answers?

More agents. This year, we’re focusing a lot on that, and I’ll talk about it in my keynote. We’re moving from being a dashboard company—that was the best DX—to code-first, Git-native. A lot of people talk about headless mode. Headless was what we started with: headless, 360, Salesforce, all these sorts of things. We had that at the start; you could use Supabase directly, API-driven. That’s one of the reasons we succeeded.

This year, our big focus is moving to code-first, Git-native. When you launch a Supabase instance on 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 Supabase CLI. It’s a virtual file system—a representation of your infrastructure as code.

Okay.

What we’re announcing tomorrow is our final change for declarative schemas.

This was a really challenging one, actually, covering all of Postgres. 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 Postgres is you have a migration file. Every time you make a change, you add a file to this migrations folder, and it's a historical log.

Okay, so that's great. It's industry standard. But imagine putting an agent across a thousand files and asking it, “What's the shape of this table?” It has to guess through a thousand files—

It has to recompile, basically—

It has to recompile, edit its weights. Yeah. Or you have to launch the database locally—

Migrate, migrate, migrate, migrate—

Run the migrations up, and then inspect—introspect the database. But that's too slow. So what we want to do is turn the schemas folder inside our Supabase folder into a completely declarative state of your database. We've captured everything from tables and policies to database comments, all inside these files.

We're releasing a new library, pg-delta. You can use it with any Postgres database, but we've got mechanisms for Supabase. 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.

That's fine, and today people are using CLIs. They're happy with these harnesses. What I suspect we're moving more towards is, at the moment, I'm trying to do some development just on my mobile phone, for example, and I'm quite comfortable doing 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 personal 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.

These are the things I'm thinking about: 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 you're interested in, as a crystal ball into the future?

As someone who's been a software engineer for a few decades, you have strong opinions on how software should be built, in terms of continuous integration or continuous delivery or whatever. I find myself pushing my opinions on the agents: “Oh, you want to do it this way.” But more and more, you don't need to. My worry is, are they all just going to converge on one way of building software, or—

Yeah, mode collapse.

You know—

Which is great. They're all going to use Supabase. It's fantastic.

Yeah, but the thing that's great about the software development industry is the famous flame wars about what's the correct approach. Are we going to lose that?

Yeah. So you want diversity in ideas—

Yeah, exactly—

—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. Is it going to be a local maximum in terms of—

Yeah. I don't know. I do think, first of all, that's a valid fear. I do think it's out of your control. And yes, the low-taste, casual app builders will converge on whatever the mean is, whatever the model is, which is you guys. But the discerning, high-skill people will always really care about the details, as they should.

Yeah—

—which will then filter down eventually, is my idea.

But 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 I do think the average college is probably screwed, right? You probably don't need to go to university anymore, because you can probably self-teach and get your own job.

It's always been the top-tier people who are moving a lot of the needle, and they will always find a way to have their own self-interests satisfied. Curiosity about what is possibly better. You know the type of people who 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 industry—

Yeah, definitely.

Like, yeah.

Definitely.

What do you disagree on between the two of you? It's rare to have the two of you on the pod. I want to capture this.

I think one of the reasons we've been so effective working together is because there are definitely situations when we'll disagree, but as soon as the other person pushes a little bit, the other person's like, “Yeah, maybe you're right. Let's try it.” We never end up in big bust-ups.

And it turns out most of that stuff actually doesn't matter, right?

Yeah, it doesn't matter anyway. As long as the general direction is correct, then it's gone okay. But, yeah, I can't think of—

Oh, you guys are really struggling here.

Yeah, which is why it's never an important enough thing. We've never had a bust-up because it's never been important enough to actually fight hard enough on it.

And also, we're fucking busy, so usually—

You've got your thing, and I've got my thing—

Em's handling—

Yeah, we're trying to handle different parts of the business.

Maybe it's just that things are growing, and obviously you've got your domain, and you just need to work together, right?

Yeah.

Yeah, yeah.

It's interesting, you know. So all three of us were in Entrepreneur First in Singapore. We were all working on different companies, and then you guys stayed back after the cohort? You were housemates after the cohort?

Yeah, yeah. We lived in a house with seven people, and we were all doing different startups. Em was doing his startup. I was doing another one. This was before Supabase.

Somehow your energies—you found that you were suitable working together and working on this project.

Yeah. Traditionally, especially in an accelerator model, you're pushed as a technical person to work with some domain expert. But in the house we lived in, it was basically seven people who were all builders, all technical people. We found that pairing to be so much more effective, especially when you're building dev tools, because you are the subject matter expert as a developer. We could just get so much more done.

And so then you ended up hiring most of the other people who lived in the flat as your early employees as well?

Yeah. Rory—

Rory, who was the first employee?

Not the first, but the first one on go-to-market. Now he runs all of go-to-market.

Oh, the Postgres guy was first?

No, Angelico. We had an intern—an intern from my previous startup. We just dragged him along.

Yeah. And then the other first full-time hire was this guy, Steve Chavez, who—

Postgres, yeah.

—who is the Postgres maintainer. The funny thing is, we were in the YC batch, and the advice they give you in YC is, “Okay, we're going to give you a bunch of money. Don't hire anyone.” The big temptation is to hire a big team. We went to our partner and said, “We've got this guy Steve. He's the lead maintainer of Postgres,” and he was like, “Hire him immediately.” Then he was like, “Forget the advice. Go and get him.”

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

Well, yeah, both. It just made sense that this was a technology we were very reliant on, and we were going to lean in. The funny thing is, we hired Steve and said, “Don't worry about Supabase. Just keep building Postgres and making it awesome.” If we have support requests or whatever, we can ask him.

The model just worked really well. Then, when Steve wanted to grow the Postgres team, we ended up hiring more people dedicated to working on that project.

You guys are doing so much for the community and open source. One thing I do have in my mind is: 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, your dependencies are now becoming optional. You can just vibe-code whatever you want.

Anything, yeah.

Exactly. Whatever is in your heads about the future of open source, I'd just love to hear it.

I think the rewrite in Rust is a valid mechanism. Someone came to me on our team, and they're like, “Oh, yeah, I'm rewriting everything in Rust that we're doing.” I was like, “To what level? Are you going to rewrite the database? Are you going to rewrite Postgres?” Postgres isn't rewritten and isn't in Rust, but I doubt you care about that level.

There are layers to what you want to rewrite. You don’t want to spend your actual innovation tokens—or your actual tokens—rewriting everything. Almost every tool will probably collapse into one language, let’s say Rust, if that ends up being the best way to write things because it’s faster and more correct. That will probably happen for most open-source tools.

But once you’ve done that iteration and everything’s running in this highly effective language, you’re not going to rewrite everything every single time. There’ll be a few winners. A really classic one could be, say, Postgres is written in Haskell, which is a very unusual language, and it’s very hard to maintain. Could it be rewritten in Rust now? Yeah, probably. The function is still valuable, and if that happens, there’ll probably be one Rust fork of Postgres that wins that category.

But you haven’t done it yet. And a lot of your stuff is Elixir as well.

Yeah, that’s the other thing. You have to think about the infrastructure side. Elixir is a really interesting language—

Because of the BEAM.

Yeah. And then you start thinking, when you’re operating things, what’s the right mechanism for operating?

But now you can change paradigms pretty easily, as long as you have all your tests.

Yeah, that’s a good one. I haven’t thought much about whether we’d switch Elixir to Rust. It’s just an option now.

Malte from Vercel has a tweet that sticks in my mind. He’s got a lot of interesting thoughts. He set aside some amount of money to rewrite all of their dependencies from C or C++ into Rust because they know it’s better, safer, and more correct. It’s a one-time upgrade of open source—all the drivers, whatever you use. I thought that was a pretty interesting call. I like it as an idea.

Cool. I don’t think it’ll happen because people love to do it themselves.

Yeah.

But as an idea, we as a company would 100% get behind that.

Awesome. And then, a closing question: AI coding within Supabase. Obviously, you’re big beneficiaries of coding agents outside the company. What’s the policy internally? How much are you spending? Is there any concern about the spend?

Supabase has always felt like a bunch of different startups glued together. We have the auth product, and we’ve always been very insistent that they should make their own decisions about what tools they use, how they behave as a team, and the reporting structure. The AI policy was no different. A lot of people asked, “What is the AI coding policy?” and we said, “It’s up to your team.” We’ve started to consolidate a few things, especially around cost, but as much as we can, we’d like to keep that model of letting the teams decide how they want to run things.

That’s it. Very decentralized.

Mm.

I’m trying to figure out a number for company leaders to take away as the market standard. What are some data points you can hang your hat on? People say the average person is spending about $20 a month, and the average employee maybe $200 a month. At OpenAI, the 50th percentile is spending maybe $3,000 to $5,000 a month, and the top percentile is in the hundreds of thousands. That’s the rough idea. I think a good metric is your ratio of token spend to human spend. For a lot of people, it’s maybe 0.1 tokens to one human salary. You can probably go up to one pretty safely, and if you’re over 1.5, you’re probably in trouble.

Luckily, as a remote company, basically everything that’s ever happened is documented, so I can ask our AI how much we’re spending. Currently, we spend about $300K per month.

Yeah. For 600 people?

No, for 450.

450 people. Okay.

Yeah. That maybe gives people an idea. What you’ve said about scaling the cost in relation to the number of employees makes sense for us, too, because we’re hiring very quickly. If we end up getting a lot of leverage out of the actual spend, then fine. You need a whole bunch of serverless employees that can spin up and down as you need, right?

Yeah, exactly. I just had a CTO of another top startup say he was worried about his company’s spend. I said, “Actually, that’s your investment in everyone else, and it’s probably very skewed. There are two or three people who are super effective at your company, and everyone else probably isn’t using AI enough.”

Yeah, that’s exactly what we see as well. We’ve got a leaderboard. We put it up, and usually people are a little bit ashamed, so they kind of—

Yeah, they sort of—

Because you’re wasting money, probably.

And that’s also the wrong focus.

The focus shouldn’t be how much you’re spending, but how many end-to-end processes you’re solving where you no longer need a human in the loop, or how you’re collapsing long-running human problems into problems that suddenly become very short. That’s where we’re spending most of our investment in AI. Luckily, as you saw, everything that’s ever happened at Supabase is documented because we’re an async company. Building a company harness, or an agent harness around Supabase, is basically just formalizing things. You can point AI at it and ask, “What are our principles?” It’ll document all our decision-making principles for the whole history of Supabase.

Before we move on from people, we have about 50 open roles now. We’re fully globally remote, so we don’t care where you are. If you’re very good—

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

Can you pick one profile, whatever’s top of mind, as a highlight of what you’re looking for and why?

SREs.

Why?

We’re growing at a ridiculous rate. We need all the SREs we can get.

What’s a quality that stands out? You probably get a lot of SRE applications, and you don’t look at them all. What stands out?

The thing we really care about is that you actually want to work remotely. This is a strange one, but it’s true. We get a lot of quality people, but to fit in at Supabase, you need to thrive in a remote-first, fully async environment. It’s not for everyone. We learned that pretty early on. People would come in and say, “I need to see humans.”

My typical model of an SRE is a graybeard sitting in a dungeon somewhere—

Yeah, yeah.

—and who doesn’t want to talk to humans anyway.

That’s the perfect person.

That’s the perfect person. All of those people, please apply at Supabase.

Hopefully they listen to the podcast.

Yeah. I think I’ve been on the record saying AI SRE is one of the hardest categories for agent startups. I might be wrong soon, but so far I’ve been right. AI hasn’t cracked SRE for whatever reason.

Not yet. I agree. Building software is debatable. Maintaining it and keeping things running is a whole different beast.

Well, thank you for keeping things running for everyone else. You guys, congrats on your journey. I’m so proud to be your friend and an investor, and to see the progress. I can’t wait for the IPO, whenever that is. It looks like it’ll take some more time, but it’ll be fine. I really want to see you ring the bell and build the next great open-source company.

Definitely, man. Thanks for having us.