Why Agents Love Supabase

“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.”

Claim: Supabase Edge Functions run on Deno and are limited to two seconds.

“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 embe-embedding.”

Claim: Supabase has heard sustained community demand for running workloads longer than the two-second Edge Functions limit, including embedding chunking.

“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.”

Claim: Supabase Compute provides long-running serverless execution co-located with a customer's database in the same private network, enabling direct Postgres connections.

“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.”

Claim: Supabase Compute supports arbitrary workloads beyond Deno, including Rust, Python, and agents, and functions as a full compute instance.

“AurionDB, we've basically put it through the ringer [chuckles] in the past year to make sure that it is rock solid and ready for the Postgres ecosystem.”

Claim: Supabase says it spent the past year rigorously testing AurionDB to ensure stability and readiness for the Postgres ecosystem.

“It is a drop-in replacement for the c- the current Postgres storage engine, which is Heap, and it runs about hun- 1.5 to two times faster, and you don't have to change anything else. It's just completely compatible.”

Claim: AurionDB is a fully compatible drop-in replacement for Postgres Heap storage that Supabase says runs approximately 1.5–2 times faster without requiring other changes.

“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.”

Claim: AurionDB eliminates the need for certain background tasks such as vacuum and bloat management, which Supabase says improves database efficiency.

“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 Jepson 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.”

Claim: Supabase says it tested AurionDB for Postgres compatibility and data-loss resistance using PG Regress, Antithesis, nightly TPCC benchmarks, and Jepson.

“We put it through TPCC nightly benchmarks and Jepson 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.”

Claim: Supabase announced AurionDB's full beta release under the Apache 2 license.

“It comes with a patent, and the Apache 2 license covers the patent. So we actually acquired the technology, continued to develop it, and then we paid for the patent and are now giving it away for free.”

Claim: Supabase says it acquired and developed AurionDB, paid for its patent, and is distributing the technology free under Apache 2, which covers the patent.

“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.”

Claim: Supabase found that each of the Postgres operators it examined could lose data under certain conditions.

“And so we decided with Multigress to do a ground up rewrite of the entire structure of a, of a operator.”

Claim: Supabase undertook a ground-up rewrite of the Postgres operator architecture for Multigress.

“And so Multigress is essentially, while our initial goal is to become or give sharding to the Postgres community, what has turned out to be is this entire operating system.”

Claim: Multigress was initially intended to provide Postgres sharding but has evolved into a broader operating system.

“And we actually ran it, uh, again through very rigorous testing, and we've done a thou- uh, 1,000 sequential failovers, and it didn't lose any data, and we've tested it in basically every way we can, clobbering it to see whether it will ever lose data.”

Claim: Supabase reports that Multigress passed 1,000 consecutive failovers without data loss and underwent extensive destructive testing for data-loss failures.

“So we're very confident now in its stability, and so we're releasing that one as well tomorrow. It's completely open source.”

Claim: Supabase says Multigress is stable enough to release and is completely open source.

“It will be on our platform for customers and, uh, invite only, so people who are running serious workloads can come to us, and we'll start helping them to scale up.”

Claim: Supabase plans to offer Multigress on its platform initially by invitation to customers with serious workloads and provide scaling assistance.

“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 Multigress will just be able to handle it, zero changes to your code.”

Claim: Supabase intends Multigress sharding to preserve compatibility so users can shard without changing their database queries or code.

“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.”

Claim: Multigress sharding has not yet been released, and Supabase expects some sharding functionality may arrive by early next year, contingent on platform developments.

“Third one is, uh, yeah, so this one's a big one, um, scale out. At the moment, we launch about five million databases on our platform every single month.”

Claim: Supabase says its platform launches approximately five million databases per month.

“And kinda 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.”

Claim: Supabase expects its monthly database launches will eventually need to reach billions.

“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've come out, where we have announced that we've acquired Turso to help us power agentic databases. Yeah. That's an incredible...”

Claim: Supabase acquired Turso to support its agentic database architecture and scale-out needs.

“So then they built this Turso architecture, which basically builds MVCC for SQLite so that you can have multiple writers. Yes. And then it's also- And because SQLite is, has a weird license, they had to fork it.”

Claim: Turso developed an MVCC architecture for SQLite that enables multiple writers.

“And actually, now the architecture, actually, it was very commonly discussed a few weeks ago, well, on S3. So some of the innovations in the database space are actually coming out of what's happening in object storage.”

Claim: The speaker observes that innovations in database technology are partly emerging from advances 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.”

Claim: Advances in object storage have added features that make it usable for some database-like purposes.

“And because object storage itself is, I think it's 11 nines of, of data- Durability... durability. Yes. Then- Which is not reliability, but whatever... yeah, not reliability.”

Claim: The speaker estimates object storage durability at 11 nines.

“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.”

Claim: The speaker says object storage can serve as an underlying cluster-like layer for functions commonly provided by a database cluster.

“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 Multigress.”

Claim: The speaker considers object storage probably suitable for smaller transactional workloads, but probably unsuitable for massive-scale transactions with heavy read and write demands.

“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. King. It's dominating.”

Claim: To support billions of databases, Supabase believes its database instances need to use a file-format architecture, making SQLite attractive.

“And actually, the thing that really piqued our interest, and I reached out to Glover, h- 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.”

Claim: Supabase saw a path to Postgres compatibility with Turso's file format after reading about Turso's rewrite.

“So we're ac- acquiring them, and we're actually gonna keep the Turso brand.”

Claim: Supabase plans to retain the Turso brand following the acquisition.

“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.”

Claim: Turso will focus on SQLite, and Supabase plans to offer Spark, a smaller database instance compatible with Supabase libraries for prototypes and new ideas.

“And when it takes off, then you just upgrade to full Postgres databases, all the way up to Multigress. I know you've been working on this for a while. This is the dream, right? Yeah, yeah.”

Claim: Supabase Spark users can move to full Postgres databases, including Multigress, as their projects grow.

“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. Yeah.”

Claim: Supabase has been working to support both upward and downward scaling of databases.

“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.”

Claim: Supabase considers a smooth, zero-downtime migration path between database backends essential.

“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?”

Claim: Supabase observes that nontechnical builders are increasingly creating whole companies.

“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, on, on tasks that could be automated.”

Claim: Supabase cites MagicSchool as a customer founded by a teacher who identified automatable inefficiencies in teaching work.

“And so now you have these startups that start without a technical co-founder, without a CTO, and that's not, like-... isolators incidents anymore. That's, like, becoming more- Everyone... everyone's- Yeah...”

Claim: The speaker says it is becoming more common for startups to begin without a technical co-founder or CTO.

“like, a bu- a builder now. Um, and that's why we see, like, the growth we've seen over the last 18 months is crazy. It is? Yeah.”

Claim: The speaker characterizes Supabase's growth over the preceding 18 months as exceptionally rapid.

“But, but it still feels, like, early, and I think, um, there's a much larger market of almost, like, consumer-like builders, right? So people- Mm... inside companies, people who wanna launch their own startups, which is gonna mean a lot more databases, which- [laughs]...”

Claim: The speaker believes the market for consumer-like builders—including employees building inside companies and aspiring founders—is still early and substantially larger.

“like we said, like, if we give everyone a dedicated Postgres cluster, it's probably n- you know, we'll probably run out of physical computers in the, in the world pretty fast. Which is basically what's happening.”

Claim: Supabase believes that dedicated Postgres clusters for every user would rapidly exceed global physical-computing capacity.

“[laughs] Yeah. [laughs] I mean, like, we've faced it throughout this year, and 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 computing. Yeah.”

Claim: Supabase says its rapid growth has created computing-capacity challenges during the year.

“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.”

Claim: Supabase chose to develop for both small-scale prototypes and large-scale workloads.

“And then you just need more people for that, so [laughs] That one's funny because, like, on the numbers side, b- basically for Supabase, there's been three chapters of AI. So the first chapter was, um, embeddings. this is the only talk you've ever done at AI. [laughs] Yeah. [laughs] 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.”

Claim: Supabase describes its first AI phase as embedding storage, during which it promoted Postgres as a vector database.

“Postgres can kinda 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, 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.”

Claim: Supabase promoted Postgres as sufficient for storing users' embeddings, arguing that a separate database was unnecessary; the effort drove growth.

“Chapter two was, like, the vibe coding wave, whereas Lovable, Bold, all of these ones coming along. That was end of 2024, and that's where we 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.”

Claim: Supabase identifies the late-2024 vibe-coding wave as its second AI phase and says it debated whether to serve that market or build a vibe-coding platform.

“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.”

Claim: Supabase chose to support vibe-coding projects because it aligns with its mission to store the world's data and its strategy of serving users from their beginnings to encourage retention.

“And then the third one, which is the, like, crazy numbers, start of 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.”

Claim: Supabase says model improvements at the start of the year coincided with a rapid increase in its signup rate.

“But usually when this happens, you're pouring a lot of dollars into marketing. Mm. We actually barely spend any dollars on marketing, and, uh, most of it's just memes and things like that.”

Claim: Supabase says it spends very little on marketing and relies mainly on memes and related activities.

“the other crazy thing about this is, is often when you get, like, more consumer-like traffic in the top of funnel, your activation and conversion to pay goes down. Yeah. But both of those things went up. Started going up quite rapidly as well. Yeah. Yeah. Actually- Because of the model. How do you know activation and conversion to pay? Oh, oh, your, at Supabase's. Our, our metrics, yeah. Ah. Our funnel metrics. Okay.”

Claim: Supabase reports that its activation and paid-conversion rates increased even as its top-of-funnel traffic became more consumer-like.

“Um, and, and the reason is because the sign-up to activation, the agent does it for you- Yeah... like, in one step, so it, it's basically a hun- it's almost 100%- Yeah, friction's gone... for us. Yeah.”

Claim: Supabase attributes its nearly 100% signup-to-activation rate to agents completing activation for users in a single step.

“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, Frank.”

Claim: Supabase says agent-assisted users convert to paid plans at a higher rate than its traditional developer users.

“time zone before LLMs took off, and then present yourself as the leading competitor to the leading thing at the time. Yeah. And then so you can take over. Yeah. Yeah, yeah. [laughs] We're very lucky with our timing. [laughs] I mean, we couldn't have timed it better. Like, it's complete accident.”

Claim: Supabase's founders describe the company's market timing as exceptionally fortunate but accidental.

“We've also talked to them, like, why does my LLM keep recommending Resend? And it's because they have a, a lot of good AEO practices. Sure, yeah. And of course, we invest very heavily in that. But, you know, when w- we've been at that point since the start, and that was an accident, right? So now we just need to maintain that lead. And community as well, right?”

Claim: Supabase says it invests heavily in answer-engine optimization and aims to maintain its existing lead in AI-model recommendations.

“Like, our, one of our growth strategies early was just, was to spend to- so much time with the community.”

Claim: Supabase says devoting significant time to its community was one of its early growth strategies.

“Like, our, one of our growth strategies early was just, was to spend to- so much time with the community. And it resulted in they were writing blog posts, they were making YouTube videos, they were putting out podcasts all about how to use Supabase, in what situations. Like, "Here's how I built this thing."”

Claim: Supabase says investing time in its community led members to publish educational blogs, videos, and podcasts about using Supabase.

“I'm sure that all just got slurped up by the- Yeah... the models. And open source helps as well, of course. Yeah, yeah, yeah. Being, being open source.”

Claim: The speaker suggests that community content about Supabase and its open-source presence may have contributed to what AI models learned.

“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, and we should have done it much earlier on, but we just, you know, had so many other things going on.”

Claim: Supabase says it had long wanted to conduct a crowdfunding round and announced the plan at the prior year's Supabase Select.

“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.”

Claim: Supabase says legal advice initially indicated that its planned community investment round could not include the desired number of participants unless they were accredited investors.

“Until we asked them the question, "Well, what if they don't invest? What if we just give them the stock?" [laughing] And they were like, "Yeah, we'll, we'll look into it." And then they came back and they were like, "Actually, there is a mechanism where if you really just wanna give the stock away, you can."”

Claim: Supabase says its lawyers identified a legal mechanism for distributing stock as a gift rather than requiring recipients to invest.

“And so now we've earmarked, like, um, $1 million in Supabase stock that we're basically gonna give to a bunch of the community members.”

Claim: Supabase has set aside $1 million worth of its stock to distribute to community members.

“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.”

Claim: Supabase says community member Gary Abbott answered 20,000 questions in its Discord over six years.

“And the crazy thing is 13,000 of them he answered within the first hour of them being asked. Mm. And he's not a grok bot. [laughing] Like, he's a real human. [laughing] Yeah. Have you met him?”

Claim: Of the 20,000 Supabase Discord questions Gary Abbott answered, 13,000 received his response within an hour of being asked.

“We, like, quite deliberately do not. Don't know. So- Yeah... we don't put any tracking in our open source offering. You can use it.”

Claim: Supabase intentionally includes no usage tracking in its open-source product.

“And we've had enterprises, large pharmaceutical companies, for example, come to us and say, "Hey, we're running 100 instances of your open source project. Can you offer us a product?"”

Claim: Supabase says some enterprise customers, including large pharmaceutical companies, run 100 instances of its open-source software and have requested a commercial 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 it- Oh, come on. Yeah, yeah. [laughing] Why not?”

Claim: Supabase Control Tower provides enterprises with a fleet-wide view for monitoring databases.

“It, all it does is, it's 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.”

Claim: Supabase says its platform product supports AI companies by launching 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 many- Internal Supabase... 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.”

Claim: Supabase says enterprises want to provision and manage internal Supabase instances for their users, and Control Tower adapts its platform-provider tooling for enterprise customers.

“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.”

Claim: Control Tower adapts Supabase's existing platform-provider database-management capabilities for individual enterprise customers.

“[laughing] Like, we give a shit about... We have 60% of every YC batch use Supabase. We focus on- Almost all of our attention on this, like becoming an index company. Basically, our role model here is Stripe.”

Claim: Supabase says 60% of each Y Combinator batch uses its product and that it is focused on becoming an index company, taking Stripe as a model.

“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.”

Claim: Supabase views Stripe as a model for moving upmarket over a decade while preserving developer affinity, a combination the speaker says few developer-tool companies have achieved.

“So to do that, what 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.”

Claim: Supabase's product-led sales approach identifies customer signals—including notable logos, growth, product limits, errors, and spending—to guide sales outreach.

“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 1,000 product triggers every single week. We send off 1,000 emails to people who are having problems, and say 500 of them respond. We take the cohort who don't respond, and we use them as a control group. Okay. And we measure how much they grow.”

Claim: Supabase says its product-led sales system generates roughly 1,000 customer triggers weekly and sends emails to customers identified as having problems.

“We send off 1,000 emails to people who are having problems, and say 500 of them respond. We take the cohort who don't respond, and we use them as a control group. Okay. And we measure how much they grow. Turns out they grow twenty-five percent 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."”

Claim: Supabase describes a sales experiment in which it compares growth among customers who respond to outreach with a control group of nonresponders.

“Turns out they grow twenty-five percent 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."”

Claim: Supabase reports that the control cohort of customers who do not respond to sales outreach grows 25% month over month.

“And because we've got all their traffic patterns, we can give them a script. We know what their problem is. AI has been great on this.”

Claim: Supabase uses customer traffic data and AI-assisted scripts to equip salespeople to help customers resolve product problems.

“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 a hundred and twenty-five percent.”

Claim: Supabase reports that customers who respond to outreach and receive a helpful sales call grow their accounts by 125%.

“So that 100% uplift, the incremental uplift, is what we compensate our salespeople. Traditionally, you would 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 twenty-five percent month over month on this cohort of users, then we know that our sales force are adding this 100% incremental uplift.”

Claim: Supabase bases sales compensation on the incremental growth attributed to sales assistance, rather than the cohort's baseline 25% monthly growth.

“So that's how we do our sales function. It's always focused on these logos or very specific, uh, product needs.”

Claim: Supabase says its sales function focuses on selected company accounts and specific product needs.

“So yeah, the likes of the enterprise is usually coming in because they're wanting to launch lots and lots of databases, or almost never it'll be a transfer of their production database.”

Claim: Supabase says enterprise customers generally adopt it for new deployments involving many databases, not to transfer an existing 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.”

Claim: Supabase's original thesis was that customers rarely migrate production databases between systems such as MySQL and Postgres or between scalable databases.

“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.”

Claim: The speaker says database companies that relied on migrations to win customers had historically failed because customers are difficult to convince 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 ten thousand.”

Claim: The speaker argues that a database company must win customers initially and retain them long term, even if it offers a larger, better, more scalable Postgres.

“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. Wow. There's a cohort that will need Multigress.”

Claim: Supabase prioritizes landing enterprise greenfield workloads rather than migrations, and the speaker expects those customers almost never to migrate.

“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- Hmm... 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.”

Claim: Supabase expects nearly all of its enterprise effort over the next five years to focus on greenfield workloads.

“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.”

Claim: Supabase says enterprise greenfield development is common because companies want product teams to build and innovate more.

“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.”

Claim: Multigress may help Supabase capture large workloads if customers migrate, although migrations are not expected to be a core focus for at least five years.

“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.”

Claim: Supabase's enterprise strategy prioritizes winning new workloads and expanding within enterprises instead of making migrations a core focus.

“The other thing that's changed is we obviously put, in the past, all of our focus into developers. So it was like selling to the developers, enable them as a champion, they help you sell internally.”

Claim: Supabase's earlier enterprise approach centered on winning developers as internal champions who would help sell the product within their organizations.

“Uh, interestingly now, we have like CPOs 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 and without needing to put like a huge motion around that.”

Claim: Supabase reports that some CPOs are using Lovable and Supabase to build internal products after years away from coding, creating C-level champions without extensive sales effort.

“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, uh, 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 [chuckles] their projects to work. Hmm. Um, by paperclip maxing basically, is that Lovable wrote really good skills to stop their agents doing stupid stuff.”

Claim: The speaker says Lovable was an early leader in using agent skills to prevent database mistakes such as storing image data in Postgres or turning off row-level security.

“They were, they were the first. That's the secret sauce. Yeah, yeah, yeah. It's the, it's to solve all these- And, and, and now, like the models themselves don't do that stupid stuff anymore. Yeah. 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. Yeah. Yeah.”

Claim: The speaker says AI models have improved substantially and no longer commonly make earlier database-use mistakes.

“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.”

Claim: The speaker recalls an estimate that roughly one year earlier only 5% of Oracle workload revenue came from cloud workloads, while allowing that the share may have changed.

“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 of all, on landing inside the enterprise. Yeah. Well, yeah. Yeah. That makes sense.”

Claim: Supabase intends to pursue migrations but considers the strategy extremely difficult and prioritizes establishing itself in enterprises first.

“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.”

Claim: The speaker says Oracle is difficult to replace partly because customers embed extensive application logic in very large stored procedures within the 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.”

Claim: The speaker suggests coding agents may make rewriting legacy database logic easier and could drive migrations, while acknowledging the technology may not yet be ready.

“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.”

Claim: The speaker says code rewriting is not usually the main migration obstacle and that analytics-warehouse migrations can be relatively straightforward.

“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.”

Claim: The speaker says OLTP migrations are risky because the database often supports a company's highest-revenue application, making even a minute of downtime costly.

“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 s- split brain, anyone who's tried to do it, it's a very hard problem.”

Claim: The speaker says parallel-running databases during migration can create split-brain data that is difficult to reconcile.

“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.”

Claim: The speaker says companies often avoid high-risk OLTP migrations by separating workloads and building new ones instead.

“Like, is, is there, is there a story there for Superbase some- someday? Yes, we are particularly interested in Duck Lake. I think Duck Lake is a very... and DuckDB is a very interesting- Is, is it-... technology...”

Claim: Supabase says it is particularly interested in Duck Lake and views DuckDB as an interesting technology.

“Mother Duck, but a, but a data lake? Like, what, what is, what is Duck Lake? Uh, Duck Lake. Okay, so, um- [laughs]... DuckDB- Yeah... which was recently... There's 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.”

Claim: The speaker describes DuckDB as an analytics-focused, SQLite-like database that can query object storage and Postgres.

“So open source, great technology, and actually there's also, uh, DuckDB Labs, which was recently acquired by AWS. Yeah, so they're a foundation- Mm. That's good technology. Yeah... that are developing.”

Claim: The speaker says DuckDB is open source and that AWS recently acquired DuckDB Labs.

“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.”

Claim: The speaker views DuckDB as analogous to Postgres in analytics because its governance aims to keep it independent of any single owner.

“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...”

Claim: Supabase says it does not aim to make Postgres an analytics database and instead intends to use purpose-appropriate technologies for warehouse workloads.

“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.”

Claim: Supabase believes OLTP systems generally require sharding after reaching a sufficiently large scale.

“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.”

Claim: The speaker says limited NVMe capacity can force cross-server transactions to fetch from object storage, eventually slowing the database.

“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.”

Claim: Supabase considers sharding the best approach for scaling OLTP databases to petabyte sizes and recommends treating analytics separately.

“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- Hmm... doesn't necessarily make that much sense in my opinion. Yeah. I, I... I'm happy to leave it there 'cause we do have more, uh, to, uh, work on.”

Claim: The speaker allows for object-storage-based data access through a separate route but doubts that combining transactional and analytical systems is generally sensible.

“Okay, so what was missing for us to do durable workflows? Compute. Right. So you're, you're doing this now [chuckles] 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. Yeah. 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- Yeah...”

Claim: Supabase says durable workflows previously lacked suitable compute because of the two-second function timeout, and its new compute capability now provides the primitive for long-running workflows.

“I mean, our P1 strategy is to partner with as many of these frontier labs and models as we can, so we've gotta be prolific there. And then we basically, uh, we see our attach rates just going up as well. Yeah.”

Claim: Supabase says its product attach rates are rising.

“I mean, our P1 strategy is to partner with as many of these frontier labs and models as we can, so we've gotta be prolific there. And then we basically, uh, we see our attach rates just going up as well. Yeah.”

Claim: Supabase's stated P1 strategy is to form partnerships with as many frontier AI labs and models as possible.

“Yeah, mainly just 'cause, like, that's who's delivering the most traffic at the moment, right? So that could change. Yeah. But what does partnership look like?”

Claim: Supabase says US AI labs currently generate the most traffic for it, while acknowledging that this may change.

“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- Sure... when you launch an artifact. Yeah. So that one's super interesting for us to be able to hopefully be one of those providers. Mm. One of the reasons why we couldn't in the past was because we just couldn't handle their scale.”

Claim: Supabase wants to be a default backend provider for artifacts launched through AI labs, a role it previously could not support because of scale limitations.

“I mean, take ChatGPT, for example. What have they got now? A billion monthly active- 1.2... 1.2 billion monthly active users. Yeah. One of their users launching a database every single month. [laughs] Now we've got to launch 1.2 billion Postgres servers. It's just, as I said, we've got to get to the billions of databases per month.”

Claim: Supabase believes supporting AI platforms at ChatGPT's scale could require launching billions of databases monthly, potentially one per active user each month.

“Oh, P0s are basically win the strategic labs, win the models, and, uh, continue our PLG push, and then P4 is enterprise. I, I like how- 'Cause they're like- I like how P4 is enterprise, yeah... one, two, three, four. Yeah. [laughs] Those are, those are the four in terms of rankings. Yeah, I mean, that is the truth of it. Like, we, like, I mean, where we are focused on the enterprise is, is winning these- Yeah... new workloads.”

Claim: Supabase ranks winning strategic AI labs and models and continuing product-led growth as P0 priorities, with enterprise at P4.

“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.”

Claim: Supabase initially estimated that product-led growth could reach $100–200 million before needing a different go-to-market approach.

“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. [chuckles] Like, is it a billion? Is it two billion? Is it... You know, you could just-- we could just keep going.”

Claim: Supabase believes AI has raised the potential scale of product-led growth beyond its previous estimate, though the new ceiling is unknown.

“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- Okay... if you use the RCLI. So it's a virtual file system. Uh, like, it's a representation of... It's like infrastructure as code. Okay. Yeah.”

Claim: Supabase is moving toward a code-first, Git-native workflow in which a local project folder represents the database and its associated functions.

“And in fact, what we're announcing tomorrow is, like, we've 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.”

Claim: Supabase says its new declarative-schema capability represents a complete Postgres database schema as files in a project 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 it- 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... edit its weights. Yeah Or you have to launch the database, um, locally- Migrate, migrate, migrate, migrate... run the migrations up, and then you inspect-- introspect the database. But that's too slow.”

Claim: Supabase says agents struggle to infer the current database schema from long migration histories, and reconstructing it by running migrations locally is 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, pgDelta. You can use it with any Postgres database.”

Claim: Supabase plans to make its schemas folder a complete declarative representation of database state, including tables, policies, and comments.

“And so we've captured everything from tables, policies, uh, database comments, all inside these files. So we're releasing a new library, pgDelta. You can use it with any Postgres database.”

Claim: Supabase is releasing pgDelta, a library for declarative database schemas that works 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've gotta iterate very fast on the file system. So that's fine, and today people are using CLIs. They're happy with these harnesses.”

Claim: Supabase expects agents to work primarily through code and files rather than querying external systems.

“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. 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 daughter, or whatever personal agent you have- Yeah...”

Claim: The speaker suspects software creation may shift toward non-engineers using personal agents on phones to build applications.

“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 daughter, or whatever personal agent you have- Yeah... "I want to build X," and one second later you kind of have this application live. You can iterate on, on it yourself.”

Claim: The speaker imagines a future in which a personal agent can turn a spoken request into a live application almost immediately and let the user iterate on it.

“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?”

Claim: Supabase is evaluating future agent-built application needs and the tooling required to become the default infrastructure provider.

“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. [laughs] Um, I...”

Claim: The speaker agrees that AI could cause software-development practices to converge, considers that a legitimate concern, and believes individuals cannot control it.

“And, and yes, uh, the low taste, let's call it the 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. Yeah. Right? And which- Yeah... which will, which will then filter down eventually- Yeah... is the, is my idea.”

Claim: The speaker predicts that casual app builders will follow model-generated conventions, whereas discerning high-skill builders will continue to focus on implementation details.

“It's one of those things where like, you know, I do think like, uh, you know, the average, um, college is probably screwed, right? Like you probably don't need to go to university anymore because you can probably self-teach and just like, you know, uh, get, get your own, uh, job.”

Claim: The speaker predicts that traditional college may become less necessary because people can potentially teach themselves and obtain jobs without university.

“It's always been like this top-tier 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.”

Claim: The speaker believes high-performing individuals have driven a disproportionate share of progress and will continue pursuing their own interests.

“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, right?”

Claim: The founders say they resolve disagreements quickly by trying each other's suggestions and rarely have major conflicts.

“Yeah, it doesn't matter anyway. [laughs] Like as long as the general direction is, is correct, then, then it's gone okay. But, uh, yeah. I can't think of- Oh, you guys are really struggling here. Oh my God.”

Claim: The founders believe most internal disagreements are unimportant when the company's overall direction is sound.

“And also we're fucking busy, so like usually like- You got your thing and I've got my thing... Em's handling, yeah. Yeah, yeah. We're trying to handle different parts of the business. Yeah.”

Claim: The founders say they generally handle separate business areas, which helps explain why disagreements do not escalate.

“Yeah. Because like traditionally, especially in, in an accelerator model, you're pushed as a technical person to work with some domain ex- domain expert, right? Um- But in the house we lived in, it was basically seven people who were all builders, all technical people, and we found that pairing to just be, like, so much more effective, especially on when you're building dev tools, 'cause you are the subject matter expert as a developer, is that we could, could just get so much more done.”

Claim: The founders say a team of technical builders working together was more effective for developing developer tools than pairing a technical founder with a domain expert.

“who is the 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." [laughs] You know, then he was like, "Forget the advice. Go and get him." W- of his reputation or because it made sense for Supabase? Well, yeah, both.”

Claim: Supabase says it hired Postgres maintainer Steve Chavez after its Y Combinator partner urged the founders to hire him immediately.

“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 him. Yeah. But, um, and the model just worked really well.”

Claim: Supabase initially tasked Steve Chavez with improving Postgres rather than working on Supabase product support, and the founders say this arrangement worked 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.”

Claim: Supabase says it added dedicated staff to its Postgres team when Steve Chavez sought to expand the project.

“[laughs] So there's gonna be, like, a, 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.”

Claim: The speaker predicts that many open-source tools may be rewritten or consolidated in Rust if Rust proves to be the fastest and most correct implementation language.

“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 is 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.”

Claim: The speaker expects a small number of successful tools to persist after a wave of rewrites into more effective languages, rather than continual rewrites of every tool.

“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 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.”

Claim: The speaker thinks a Rust rewrite of Postgres is probably feasible and predicts that a single Rust fork could become the leading version if such a rewrite occurs.

“So- But now you can change paradigms eas- 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.”

Claim: The speaker says Supabase has not seriously considered rewriting its Elixir-based infrastructure in Rust.

“He set aside some amount of money and rewrite all of our dependencies, uh, at, at the C level or C++ level into Rust, um, because we just know it is better, it's safer, more correct- Yeah... what-whatever. And it is, it is a one-time upgrade of open source. Yeah. All the drivers, what-whatever you, you use. Um, so I, I thought that was, like, a pretty interesting call. I, I like that as an idea, yeah. Cool. I don't think it'll happen [chuckles] because people love to do it themselves. Yeah. But, but as an idea, I, I would, like, we as a company would 100% get behind that. Awesome.”

Claim: The speaker supports the idea of a one-time, company-funded Rust rewrite of C/C++ dependencies for safety and correctness, while doubting it will happen because developers prefer to do such rewrites themselves.

“[laughs] 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 asking, "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. Mm.”

Claim: Supabase's AI-coding policy is decentralized: teams choose their tools and practices, with some central coordination emerging around costs.

“I think, uh, a good metric is basically what is your ratio of token spend to human spend, and it's r- like, for a lot of people, it's maybe 0.1... tokens to, to one human salary. And, uh, you know, y-you can probably go up to one pretty safely, and if you're over 1.5, you're probably in trouble. [laughs] Something like that.”

Claim: The speaker proposes token spend divided by human salary spend as a useful AI-investment metric, estimating a typical ratio near 0.1, a potentially safe level up to 1, and possible trouble above 1.5.

“So currently we spend about 300K per month. Yeah. Uh, for 600 people. No, for 450. So 450 people. 4-450 people. Yeah. Okay. Yeah. That maybe gives people an idea.”

Claim: Supabase reports monthly AI spending of about $300,000 for a workforce of roughly 450 people.

“[laughs] 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- Yes... 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.”

Claim: The speaker argues that AI investment should be judged by end-to-end process automation and reductions in human effort or task duration, not simply by spend.

“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- Absolutely... company harness or, like, an agenda harness around Supabase is basically just formalizing. You can point AI at it and say, "What are our principles?" And it'll docu-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.”

Claim: Supabase is building internal AI tools that use its extensive asynchronous documentation to surface company principles and historical decisions.

“Before we move on from people, we do have, I think, now, like, 50 open roles. [laughs] And we are fully globally remote, so we don't care where you are. If you're very good- Same, same salary everywhere, right? Yeah. 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. [laughs] Yeah. Can you, uh, can you...”

Claim: Supabase says it is fully remote, has approximately 50 open positions, and uses location-independent salaries.

“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. Yeah. Why? Because we're just growing at a ridiculous rate. We need all the SREs we can get. What is a quality that is... Like, you know, you, you probably get a lot of SRE applications and you don't look at them. Like, what, what stands out?”

Claim: Supabase says it is seeking SREs to support its exceptionally rapid growth.

“The thing that we really care about is that you, you actually want to work remotely. Um, so it's- [laughs] This is a strange one, but yeah, it, 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.”

Claim: Supabase considers remote-first and asynchronous work essential for employee fit, while recognizing that this environment does not suit everyone.

“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- Oh, yeah... for agent startups. I think I might be wrong soon, but so far it's been correct. Like- Okay, yeah... AI has not cracked SRE for, for whatever reason. No, no, no, no. Not yet. I agree. Yeah.”

Claim: The speaker believes AI has not yet solved SRE work but allows that this assessment may soon become outdated.

“Like, building software is, you know, debatable. Solve problem. Maintaining, like, keeping things running- Yeah... is a whole different beast. Well, okay. Well, thank you for keeping things running for everyone else.”

Claim: The speaker distinguishes software maintenance and reliability work from software development, describing operations as a separate challenge.