Y Combinator Startup Podcast · 2026-10-30 · 49 min
Key moments - from our scoring
Substance score
61 / 100
Five dimensions, 20 points each
Supabase has experienced explosive growth in 2024-2025, tripling its user base to 13 million and growing from 8 million to 50 million databases under management. This acceleration stems from a fundamental shift in who can build software: traditional software engineers now represent a declining portion of Supabase's growth, while a new category of domain experts and builders with no engineering background are using AI-powered coding tools like Claude and ChatGPT to create sophisticated applications. Paul Copplestone explains how Supabase evolved through three eras - dashboard company, API-first, and now code-first - each shift driven by observing how builders actually want to work. The company deliberately chose open source, CLI-first development, and integration with LLM defaults to capture this new builder wave. Concrete examples include a 50-year-old Brazilian taxi driver building a local Uber-like app, fintech founders building personal finance dashboards with features matching Mint or Monarch, and internal engineers adopting AI coding agents to write 60% of their code (up from 10% six months prior). Supabase is now architecting toward massive scale - potentially 1.2 billion databases monthly if ChatGPT's 1.2 billion weekly active users each create something - requiring innovations like the Supabase Spark tier using SQLite for lightweight workloads alongside PostgreSQL for enterprise scale.
Hosted by Y Combinator. The show scores 78.2/100 on substance across its analysed episodes. See the full show profile.
The primary driver is AI enabling non-engineers to build software. Supabase evolved to be code-first and CLI-native (how AI agents prefer to build), gained adoption as a default database choice in LLMs, and benefited from being open source - all factors that appeal to both AI agents and new builder categories without traditional software engineering backgrounds.
Domain experts are building personalized solutions: a 50-year-old taxi driver built a local Uber-like app, fintech founders created personal finance dashboards with features matching commercial tools like Mint, and users are building personal CRMs and health trackers that consolidate and analyze their own data - applications too niche for existing software companies to address.
The company is building two product tiers: Supabase Spark (SQLite-compatible, for prototyping and lightweight workloads) and multi-PostgreSQL (scaling to petabytes for growing businesses), allowing 'prototype to petabytes' scalability without forcing builders to choose a database upfront.
A recent poll showed 60% of engineers' code is written by AI coding agents (up from 10% six months ago), but the company maintains no AI policy - engineers choose their own tools - and emphasizes testing infrastructure and code review to ensure quality at this adoption rate.
The company made strategic shifts from dashboard-first to API-first (enabling tools like Bolt and Lovable to build on top) to code-first and CLI-native, combined being open source, and explicitly avoided proprietary vendor lock-in - all factors that made it the natural default for AI agents and LLMs to recommend when building backends.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode has a moderate density of actionable insights - agent-optimised error messages with remediation instructions, the three-era evolution (dashboard → API → code-first), evals for different LLMs, and the personal-database-as-consumer-product thesis are all worth noting. However, large stretches of the conversation are personal anecdotes, casual banter, or general AI optimism that adds nothing a thoughtful B2B operator couldn't already infer.
inside the error messages, you are literally telling them how to fix this error or to go and read some docs to fix the error. So a lot of it is just picking your use case and just trying to do these loops on improving your own error messages so that you can one shot basically anything
there's like two stages to winning the agents. The first is being picked by the model, and then the second is if they get stuck, you don't want them to switch away
A few genuinely fresh frames emerge - redesigning error messages as an agent-retention mechanism, and the idea that the prosumer personal-database market is a credible growth vector. But the broader narrative (everyone becomes a builder, agents prefer open source, stripe/AWS model for day-one capture) is well-trodden YC discourse, and the contrarian muscle is rarely flexed.
I think a lot of the say enterprises are going to want to inspect the source code to know that it's secure. And if you've got closed source code then you probably won't want to adopt them as a vendor
databases essentially are like a retrieval mechanism for data... putting an agent on a loop to create a new type of index or find the best index
Paul Copplestone is a genuine practitioner running a real infrastructure company at meaningful scale, not a thought-leader doing the podcast circuit. His answers reflect operational reality - an actual acquisition (Terso), internal AI adoption stats, and specific product-architecture decisions. The YC partner hosts are also practitioners building on the stack themselves, which raises the conversation above the typical interviewer-as-generalist dynamic.
we made an acquisition recently, Terso. They've got an architecture that's compatible with Postgres and actually it's compatible with SQLite as well
we've got our own eval suite internally. We eval as well which ones are best just with Postgres
The episode is reasonably well-stocked with real numbers - 13M users vs ~3M a year ago, 50M vs 8M databases under management, 4x revenue growth, 1M databases per week, 60% of engineers using AI agents for 80% of code (up from 10% in six months), named companies (Bolt, Lovable, Terso), and named products (Supabase Spark). Some figures are explicitly hedged ('I might get it wrong, fact check me'), and the second half drifts into personal anecdotes without anchoring claims in data.
databases under management now are approaching 50 million and this time last year it was 8 million
10% of your engineers were writing 80% of their code with the coding agents and then that number recently got up to 60% in a matter of six months
The hosts bring domain knowledge that produces a handful of sharp questions - probing the enterprise vs. prosumer tension, the open-source moat, and the error-message insight - and some useful compare-and-contrast (Heroku, Parse, Firebase). However, there is no meaningful pushback on any claim, the conversation drifts into extended personal-app storytelling, and several questions are little more than narrative prompts rather than genuine probes.
How much do you think being open source played a role in it too? Because the agents love open source things
leaning into SQL Lite is sort of going the opposite direction. How do you think about it? Are you sort of looking both ways?
Computed from the transcript - who did the talking, and the words that came up most.
Supabase has become one of the default backends for the AI coding era. The open source Postgres platform now has 13 million users, spins up more than a million databases every week, and roughly 70% of its new activity is coming from agents.As coding shifts from developers writing software by hand to agents building on their behalf, Supabase has been rebuilding itself around that new user.Supabase co-founder and CEO Paul Copplestone joins Garry, Harj, and Jared on the Lightcone to talk about what happens when everyone can become a builder. They dive into why personal software may become as common as personal documents, how to design products that agents actually want to use, and why knowing what to build may matter more than knowing how to build it.
Transcribed and scored by The B2B Podcast Index.
Speaker A: I'm genuinely excited about what the future could be for a lot of people. The thing that I really love about Supabase is that like, I see a lot of entrepreneurship, um, because of the platform. I certainly think that it'll be the case that everyone in the world with access to AI will become a builder of some sort. Like you can build anything, you can customize it, you want to make tweaks to some app, some ui, then you don't have to be beholden to someone. I'm pretty pumped about 2027.
Speaker B: Welcome back to another episode of the Light Cone. Today we're joined by Paul Copplestone, co founder and CEO of Supabase, the open source postgres backend that's become the default database inside tools like cloud code and Codex. Supabase now has 13 million users and it's spinning up over a million databases a week. Paul, welcome to the Light Cone.
Speaker A: Thanks for having me.
Speaker B: So to start off, uh, you know famously YC gives you a T shirt on the first day of YC that says make something people want. But increasingly all of us are realizing it's make something agents want. And your company really exemplifies that, you know, something like 70% of the new activity is from agents. Isn't that crazy?
Speaker A: Yeah, it's wild. It's wild. I think like this year especially what we've seen is in terms of the numbers, the inflection is just a huge shift towards agents.
Speaker C: Just so we can understand just how much you guys have grown because it's kind of mind boggling. Um, yeah, like what are the numbers you care about and where were you like this time last year and where are you now?
Speaker A: I think this time last year. So yeah, we're 13 million signups now. Probably 12 months back we would have been around three. Perhaps, um, this year, uh, like revenue will grow forex. Um, we've got. Trying to think what. You've
Speaker C: got like a million databases being created per week at the moment.
Speaker A: Yeah, yeah, yeah.
Speaker C: What was it this time last year?
Speaker A: I think actually if um, databases under management now are Ah, approaching 50 million and this time last year it was 8 million. So it's just a huge, huge inflection.
Speaker C: What's been driving that?
Speaker A: The first, people are uh, building with abandoned software engineers. Second, I think that there are a lot more builders coming online. So what was traditionally, uh, someone with a software engineering background is now uh, it's now becoming possible for non engineers to actually build things on top of Supabase.
Speaker B: So this is a really Big shift. Uh, what have you guys actually done to facilitate or encourage this shift from. Obviously software engineers are going to keep choosing Supabase but, but how do you get the agents to come over in the first place?
Speaker A: Yeah, we largely have seen like three chapters in Supabase. We started as a dashboard company, then we went to an API company and now we're very much a code first company. So we try to have the modalities that the agents really want to build with, which is code first. They really want to use clis most of the time. The other thing is just being chosen as a default uh, in the LLMs, which I think we were a huge beneficiary of, um, the timing of which we started to become a default choice for databases.
Speaker D: How much do you think being open source played a role in it too? Because the agents love open source things.
Speaker A: You know, it's hard to know the counterfactual but I think it was critical. I mean everything that we do is open source and it seems to have been a huge benefit to us and we do it in a very open sourcey way. Like we tried to support existing tools. It's not just super based tools we support like postgres is a very um, famous tool for the postgres ecosystem and we help to maintain that. So we kind of got sprawl across many communities.
Speaker B: I would guess that the agents actually really like open source because when something goes wrong it can just look at the source.
Speaker A: Yeah,
Speaker B: yeah. I mean I noticed the agents really like feeling powerful and they love data and there's uh, nothing more frustrating than hitting a brick wall and then you don't know what's going on and you can't fix it.
Speaker A: I think it's going to be increasingly important as well because now with security being so important I think a lot of the say enterprises are going to want to inspect the source code to know that it's secure. And if you've got closed source code then you probably won't want to adopt them as a vendor.
Speaker B: Is developer even still sort of the, the core user that you're going after or how, you know, how do you think about it now in 2026?
Speaker A: Yeah, I think that the world where we're moving and at least what we're seeing this year is like um, kind of builders, builders are coming online and it's like a crazy amount of people coming online. The crazy thing about this year is usually when you're um, like our top of funnel, our signups ah, are accelerating and usually when this Happens you see a lot of the other numbers start to decline, activation, conversion. But actually this year all of them are kind of going up and to the right which is a bit insane just because the models are getting so good at building and we're starting to see people who traditionally wouldn't have a software engineering background able to come and build things.
Speaker B: That's the distinction is like builder as in they might not be actually software engineers, they might just be someone who needs to build a thing and they're just popping open cloud code and then it turns out files only get you so far.
Speaker A: Yeah. And in some ways this category of people have all these pent up ideas that they could never convince a software engineer to help them build and now they don't have to convince anyone. They've got all these ideas that they're churning out. Software engineers still make up a huge portion but the rate of the growth of the builder segment is pretty, pretty big Also like I don't know where the ceiling is on this one. Like I, I remember our early investors were saying ah, uh, PLG product like growth is going to tap out at this revenue and you'll have to start moving into this segment of the market and there just appears to be no ceiling so far and I, I can't see where it stops.
Speaker B: I mean that was basically true like two years ago or one year ago but definitely not true this year.
Speaker A: Yeah,
Speaker C: I was just talking to someone actually this last weekend who fits the builder category. It's like a uh, fintech founder just exited his company of over a billion dollars and um, he's always been sort of product adjacent studying math as an undergrad and sort of could pull together some Ruby scripts but always need an engineer to build the software. And now side projects he's just building his own stuff and he has all the knowledge from how to build a fintech company so he can actually build pretty sophisticated just like for his own personal finances like balance sheets and tracking software and knows how to integrate with banks and he's writing all the integrations from scratch and it's just like the kind of software that would never have been built um, even two years ago.
Speaker A: These are the perfect type of builder as well because developers like me, I have very developer uh, focused ideas and things that I want to build but then you've got all these domain experts and they know exactly the niches of oh, this is an unsolved problem in my niche. And so they're actually able now to dig right into those niches without having to Convince someone else to join them. I think you guys were talking about this, weren't you, in yc, like the profile shifting even from who you're bringing into the cohort.
Speaker B: I think that if you look at the sort of era of what, 2022, 2025, there's sort of this real shift thinking like, well, AI is coming and suddenly, um, having software engineering as uh, core, you need a technical co founder no matter what. That was like a mega idea that, you know, really came to the fore at YC during that time period. It was always sort of true, but like sort of doubled down on that. Uh, and then really in the last year we sort of said actually, yeah, builders, like we're starting to see people who are able to like, I mean the much harder thing to do is to know what to build. You know, being able to build is something that anyone can sort of have on tap now. And that's actually a really cool thing. Like, can you imagine all the things that never would have built exactly for what you said? It's like, oh, we know that people would buy this, we know that there's a problem here, but at the margins those people couldn't convince an engineer to come work on it.
Speaker D: Do you have some examples fall of like apps that people have built on Supabase, maybe just for themselves, that are the kinds of things that would have never been built before?
Speaker A: Well, one kind of cool example was at our conference. We had the conference here and afterwards this guy from Brazil came up to me and he's built an entire taxi app, um, from his phone and it's um, kind of like a little mini Uber for his local market. And I just thought he's a taxi driver himself. I don't actually know why he built it, but the fact that he could build it and he came up extremely grateful and that he could do this and also like with the type of energy. He was like 50 years old or something like that, but he had the energy of a uh, teenager building suddenly. Which I think is kind of cool because now it's kind of getting to that stage where I think it's a little bit. There's so much uncertainty around what is the future of work going to look like. But in this category of builders, there's that excitement of the future. And that's really what I love about Supabase. It's like something that people can come in and those who are uncertain now are discovering this skill set and these opportunities where previously they were just blue collar workers, these type of profile
Speaker D: harj you've been building some of your own personal software recently.
Speaker C: Yeah. Can
Speaker D: you talk about what you've been cooking on?
Speaker C: It's just grown. Yeah, it's sort of like the end of one stuff, but it's just grown out of um, getting really addicted to openclaw. Actually like maybe six months ago now. I'm embarrassed I said it, I said there was gonna be no UIs and it was all just gonna be like chat through my openclaw. But it turns out actually and I also was really determined not to use a database for a long time. I just wanted everything to be in Markdown. Um, but yeah, it turns out actually you hit a point where a database is useful and you do need ui. I've just been building that over the last couple of weeks in particular. And so it's like um, I mean I call it Control Tower, but it's just like sort of every section of my life I have a UI to triage all my email so I don't need to read my inbox. Um, finances, tracking spending, health both tracks my weight and my workouts and everything is all in one place. But the magic of it is sometimes it's a mind boggling thought actually is I think about the finance section of my one app for myself is better. I think is at least feature parity to Mint or Monarch or all of these things but in some ways actually better because you can start doing really personalized context. It can figure out what a transaction is by looking up the name in my gbrain to figure out who that person is. Oh, I know that's like. And categorize it correctly. And that was like a whole company, like several startups just doing personal finance. And I can just like build it for yourself and I don't need it to work for anyone else or like have anyone else's opinion on it. It's just like kind of like my thing is kind of awesome.
Speaker A: We see a lot of that one like where it's finance and health, uh, basically the two like ones where you want your own data. So we see a lot of people doing that and syncing all the devices to a single database is kind of uh, magic skill. Then you can prompt it to build these correlations across.
Speaker C: It's the correlations that are really bad. Again if you just take the health example it's like yeah, all of that data is in my two phase database but then it also has access to my calendar so it knows things. It's like oh, your weight went up recently but you were traveling. So that's okay, you can just get back on track, um, next week. And it just has this context that's really valuable.
Speaker A: I also found that as I started to use the personal agents, I'm getting a little bit paranoid that I'm putting all of the, um, routines and everything. And the CRM is becoming, um, boxed into one agent. And so now I'm slowly extracting it out into one so that if I want to attach different agents on top, then I know that I can use any agent. So the CRM is another really critical one.
Speaker C: Yeah, that's why you guys are so valuable is actually, it's the. It's sort of like the store of record. The database is actually the thing that's valuable. You want to own your own database and then build all the applications or agents on top of it versus having that all in someone else's database,
Speaker D: which is a totally wild idea if you just think about the history of databases. It used to be the case that the world had only a relatively small number of very large databases run by large companies. And I remember when Supabase got started, you kind of had this idea that it should be really easy for everyone to make a database. And it almost like didn't make sense at the time why so many people would want to do that. Because unless you can write code, what can you do with a database? And there's just not that many people who can actually like, write code and build a personal CRM like that. Like, it's just like too much work for most people. Pre AI.
Speaker C: Like another example actually, like where super is really valuable for me is like the other section I have is just like a file upload. Sounds very simple. But like any file I can sort of forward via email or just like dump it in this ui and then my agent figures out what that is and how it's relevant to my life and what to do with it. Um, but that's all being stored on Supabase. And so, yeah, in general, it's just like Supabase is actually going to end up having all of the data about my life in a single place. And, um, I would never have thought about wanting a personal database a year ago because it wouldn't have made any sense. But now that's actually the most valuable thing.
Speaker B: Yeah, you have an S3 compatible Supabase files thing and
Speaker A: all
Speaker B: my stuff is in that. Oh, really nice.
Speaker A: Yeah, yeah.
Speaker B: Default in gbrain.
Speaker C: Great,
Speaker A: thank you. Um,
Speaker D: do you think this is the future, Paul, where like, basically everyone in the world not every developer, every person will have a Supabase database that has stuff about their life in it, their health, their finances, their relationships.
Speaker A: Yeah, we'd love that. I mean, I certainly think that it'll be the case that everyone in the world with access to AI, uh, will become a builder of some sort. Like you can build anything, you can customize it, you want to make tweaks to some app, some ui, then you don't have to be beholden to someone. Of course, like, we think of ourselves as an index company. When we came into yc, we just focused on YC companies. We wanted to win all YC customers. And like now that was because we knew that, uh, we had to be there on day one when businesses were getting started. The mission didn't change, just the aperture has like increased significantly. Now as more builders come online, we know that we need to service them, which is actually a whole different problem to solve, but kind of an exciting one
Speaker D: significantly meaning like 10 million x.
Speaker A: Yeah. So what, we launch now a million databases every single week. But I mean, if you do some basic arithmetic, let's say with ChatGPT, I think they said they've got 1.2 billion weekly active users and let's say all of them want to launch something every month. That's 1.2 billion databases a month. And so that's like the scale that we're moving towards architectures that we need to have so that we can actually cater for that scale, which is something that has never had to happen before on the database realm.
Speaker D: Can you even do that with postgres, or are you going to have to build your own database engine to scale to 1 billion new databases per week?
Speaker A: I think. Yeah. Well, if we could negotiate better with aws, then maybe we could. But it turns out that, uh, everyone wants computers at the moment. And actually, I don't know if you need such a Ferrari for a lot of these workloads. We made an acquisition recently, Terso. They've got an architecture, uh, that's um, compatible with Postgres and actually it's uh, compatible with SQLite as well. I think SQLite's a phenomenal database and so we'll provide this tier which we call Supabase Spark, which is basically for these getting started workloads. The idea won't be the same. You get started with the same experience. You can scale up to petabytes. So our, um, taglines kind of prototype to, um, petabytes and we as a company need to make sure that we can provide for everyone and if they do scale up and their business keeps growing, then we make sure that they have a great time.
Speaker C: Yeah, that's something I was curious about how you think um, about. This actually is like the classic sort of software company. You start with maybe early stage startups like YC Batch and then you sort of have one eye towards the enterprise. And I feel like especially if you're a database company like pre AI, the conventional wisdom as well, you want to be Oracle, so you've got to get to the enterprise as quickly as you can because that's where all the money is. And so you start building out enterprise features, you sort of leaning into SQL Lite is sort of going the opposite direction. How do you think about it? Are you sort of looking both ways?
Speaker A: Yeah, yeah we're having to do both which is like incredibly difficult. Um, basically we've got two products that cater on the two ends so multigrasses scale up to petabytes, uh, and then terso scale down to like these prototyping and SQLite type workloads. So trying to do this uh, at the rate of growth with like having to employ more people, it's just even with AI is becoming or has been a real challenge but a fun one.
Speaker B: So you ran a poll recently ah where people went from 10% of your engineers were writing 80% of their code with uh, the coding agents and then that number recently got up to 60% in a matter of six months. Like how did that happen? What's happening? Like you know, where is this going from here?
Speaker A: So we don't have an AI policy internally. We just let people do whatever they want and we give them access to whatever tools they want to use. And I think now it's just that they're convinced that the models can do so much better work and so much more. So the adoption has been crazy. And yeah the things that they're building internally are not just vibe coded type stuff, they're pretty intense. Um, and as we're like shifting into this uh, AI coded realm, like just the amount of testing that we're doing and the tools that we're adopting for testing has been pretty useful to make sure that they actually know that the end result is going to be good.
Speaker B: Yeah we're seeing that across yc, the YC startups like uh, Blacksmith Depot, UBI Cloud, like they're all vertical because everyone's doing CI
Speaker A: and
Speaker B: the number of tests that you have for just like three
Speaker C: cryptile for make review.
Speaker B: So that's pretty wild honestly to see was it Like a pretty. Like, it's just the models are good enough now and, like, people spend enough time where they're like, oh, actually this is quite good.
Speaker A: And people need to be convinced, especially engineers. Uh, like, I mean, they might not. At the start of the year, I've thought that it was very good and the models have gotten better, but also they're starting to see, oh, actually, you can achieve some great things with, with these models and all the stuff with Navier Stokes and all these stuff, um, convincing the market that actually, yeah, we can break new ground here. So I think that's the world that we're moving towards. And now people are convinced that this is the way that it's going to be.
Speaker B: You've seen Supabase, like, through three eras. First, kind of like a dashboard company, um, built in 100 days during YC, then the API company, and then now it's, you know, sort of this agent, you know, make something agents want sort of moment. Uh, was there, like one or two things, like, in each era that really jump out at you? Like, oh, that was the thing that made us in that moment.
Speaker A: I think, like, those shifts happened. So the first one, actually. Yeah, I think you were saying, like, why would a database, um, company exist? When we came into yc,
Speaker D: it seemed like such a contrarian idea at the time, actually.
Speaker A: Yeah, yeah, yeah. Uh, I think we saw how hard it was to use a database, even for developers. And so that dashboard first was like, oh, let's build a UI that looks like airtable on top of postgres. Because I actually loved airtable as well. I was like, wouldn't it be cool if that was just a postgres database on the back end? So, um, that one was just seeing that even software engineers struggled. And then when we moved to AI, I think we talked about this on the other podcast. The, uh, API, um, shift was because we had someone integrating with us and they were like, oh, we want to launch lots of databases. We need an API to do all of this. And that was like, 2021 maybe. And it turns out that was exactly the right move for 2024, when the likes of Bolt and Lovable and all of these people started building on top of us. Then this year, I just saw that actually no one's coming to the dashboard. No one visits dashboards anymore. So, um, how are agents going to build in this one? I just kind of put out a product memo to the team that said it has to be code first. Get native. Supabase just has to shift to code First. So if it exists on the dashboard, it basically has to work in lockstep, in code, infrastructure, as code, uh, essentially. And we re architected a lot of the CLI and everything to work, uh, in sandboxes, in code.
Speaker C: Were you guys maybe too far back, but were you ever inspired by Parse, another wave company?
Speaker A: Yeah, yeah, yeah. Parse and Firebase. I liked both of those companies. And it's funny, these waves, right, because they did the backend and Firebase acquired by Google, Parse by Meta. But in some ways I think they like blazed the trail for us to come along and actually have a legitimate database business. Because in 2014 it would have been ridiculous not to use RDS for your, for your database. Then they came along, Mongo came along. Um, Mongo started moving to Atlas and a lot of these database companies kind of showed that you don't need to just use one of the three hyperscalers. You can actually have a legitimate database company. And um, so that, that timing was crucial for us.
Speaker C: Yeah, past has sort of forgotten that, but I was like actually a really well built product. They launched just when I was building iPhone apps for the first time and it was quite nice to switch to a nice restful API that I was trying to deal with.
Speaker A: These shifts always happen with inflection points. At that point there were two things that happened in the market. Somehow MongoDB convinced everyone that NoSQL was supposed to be an amazing, uh, way to store your data. And, um, the second was mobile. And so we're fortunate that we had a couple of these waves as well. And now we're right in the thick of it. Yeah,
Speaker C: I mean this is what I was asking about, sort of like how you think about the enterprise versus the early. Because I think even if you go even further back, this is like Heroku was the first where it's like, hey, just start with the best developer experience and then scale up. But it actually can be quite hard to scale up with people. And I think Heroku sort of, I don't think could quite bridge that gap, um, to how do you keep people on you, like, as the apps get bigger and need to be more performant, et cetera, et cetera. But like, historically every company's had to figure that out and like, I know you guys are looking that way, but you might not have to. Like, honestly, if the market for just owning, like, I know, call it zero to 10, whatever, like, keeps expanding, at this rate, it's going to be huge.
Speaker A: Yeah, well, we want it all. So, uh, we Might not have to, but uh, we'll definitely do it. And like, kudos to Heroku. I think they popularized Postgres, but at the time Postgres was pretty, uh, it was still pretty nascent and it's still got some scaling, um, limitations. And so yeah, we've had to wrap Postgres and some tooling that will allow it to scale indefinitely. But
Speaker C: I mean, I guess a better analogy for you guys is more like AWS was able to actually get people early and scale. What are the lessons? Maybe how do you think about making sure you can scale
Speaker A: the lesson? I think that I heard a stat and was telling me, um, I might get it wrong. So fact check me. But something like 40% of AWS's revenue comes from startups that started on them and then scaled up. And that's the category that we want. We know that to convince people to migrate from one database provider to another is near impossible. And so we just want to be there on day one, make sure that they have a great time and then make sure that they actually don't want to leave
Speaker C: the same business model as stripe. I mean it's like basically the best business model on earth. If you can get it, get them on day one and then scale with like the fastest growing companies in the world.
Speaker A: Ah,
Speaker C: definitely.
Speaker A: And you just do that for a generation and you become a generational business. That's pretty much it. Yeah, it's hard for us because what does day one look like that's rapidly shape, uh, changing? So in the past, day one for me was always like YC customers. And now day one is becoming like, okay, everyone's a builder. What are they going to use? What are the modalities? Uh, how are they going to choose their databases? These are uh, tricky questions.
Speaker B: YC's next batch is now taking applications. Got a startup in you. Apply@ycombinator.com apply. It's never too early and filling out the app will level up your idea. Okay, back to the video.
Speaker D: It's kind of a different customer segment. Initially when you started, there was not an individual market for databases. The idea of a database company being a direct consumer business would have just like, sounded like a syntax error.
Speaker A: Yes.
Speaker D: Um, but now you actually have two segments. You have the like early stage companies that, that, that has this powerful stripe business model. But you're also like selling directly to consumers or to their agents perhaps.
Speaker A: Yes, yes, yes.
Speaker D: And those use cases presumably will not scale the way startups will, but they might just like continue to use you for like, for the rest of their lives because you're powering the app that like, runs their personal finance or your taxi cab company or something like that.
Speaker A: And as their lives grow and they accumulate information that is basically an index of our own growth, so they just store more, people are collecting more data. This kind of prosumer market is essentially a good growth vector for us,
Speaker C: I guess. Do you think about the personal agent world through that perspective then? If sort of coding agents want Supabase, it's very clear. Do you think about the next phase as being. Assuming we all have personal databases, do you need to do anything to make sure that it's easy for personal agents to talk to you? Is that any different or is it basically the same thing?
Speaker A: Yeah, I'm very bullish now on, um, personal agents after a week of my EA being away and me learning exactly what they can do. And now I'm just kind of obsessed with the idea of building for personal agents. And it's true that I said to our company, like, we're code first. Um, like we're building for humans that are doing code first, but actually we're doing it for agents. Those humans pretty soon won't actually be interacting. So, like, the way I've been building is I'm using dots. Um, I just sit on a phone call with it all the time and I'm chatting to it and saying, oh, can you make these changes? And my kind of heuristic to make sure I'm building or dogfooding correctly is that I just don't look at the code and I don't allow myself ever to check the architecture except when I want to check that it's actually building things correctly. But when I'm making these changes, I just want to talk to it and see what it can change. So
Speaker C: one of us.
Speaker A: It's crazy as well. Like, it's doing some phenomenal stuff that I just. It feels like something out of a sci fi movie from like, uh, two years ago. But now, like, I'm having so many of these moments that I'm just mind blown. If you had shown someone this six months ago, they would have just thought it was impossible.
Speaker D: Yeah, I was at, um, your Supabase select conference a couple of weeks ago, which is awesome conference, by the way, and I had this, like, kind of crazy thought. I was sitting there and you're talking about all these awesome new features that Supabase was putting out, and I was like, you know, if I was building an app on Supabase, maybe I wouldn't Even care to understand all these awesome features myself, I want to, like, send my agent to Supabase, select to, like, listen to all the awesome new features and figure out how to integrate them into my code base.
Speaker A: Oh, that's wild. A, uh, truly virtual conference. We should do that. A conference just for agents.
Speaker D: For agents?
Speaker A: Yeah.
Speaker D: A conference for agents.
Speaker A: They all turn up live.
Speaker D: Live. They can, like, talk to each other, exchange tips on, like, you know,
Speaker B: live.
Speaker A: Wow.
Speaker C: You can bridge it. You can sort of airdrop, like, the markdown files for everyone, but you have to be there in, like, the. The audience to get it.
Speaker B: We'll call it the Artifactory.
Speaker A: Oh, uh, man, I quite like that
Speaker B: we talked about before this. Like, there's just a bunch of things that you've been doing that like, really make agents like you better. Like error messages, you know? You know, what was that key insight. And, like, are there a bunch of other things that you're doing that kind of obvious on the one hand, on the other hand, like, nobody's doing yet?
Speaker A: Yeah. So, like the error messages. Yeah. I was at a devtool center, uh, last night, and I was surprised that this wasn't so obvious. But we really dug into our error messages so that you can take a use case, like, oh, I want to build an application. And generally, like Developer Tung, error Messages are like, 500, um, something basic, and you just know there's a problem. But now you actually want the agents to, like, remedy themselves. So inside the error messages, you are, uh, literally telling them how to fix this error or to go and read some docs to fix the error. So a lot of it is just picking your use case and just trying to do these loops on improving your own error messages so that you can. One shot, basically anything that you want.
Speaker B: Yeah, that makes sense. Basically, you know, if you're being used by an agent, the agent will encounter error message. In the past, a human would have to go Google that and do a bunch of stuff, but here you can just say, oh, like, you're just, you know, out of Inode, so you should probably go do this.
Speaker A: Yeah. Because there's like, two stages to winning the agents. The first is being picked by the model, and then the second is, like, if they get stuck, you don't want them to switch away, so guaranteed they'll get stuck. Uh, at some point, you just want to give them the tools to remedy. So, uh, it's not actually that complicated. They're smart enough now that they can figure out a lot of stuff. But you do have to re Engineer a lot of what previously was just for humans and developers. For agents.
Speaker D: Do you test your product for agents? Do you have agents try to use Supabase and then report all the places where they had trouble?
Speaker A: Yeah, all the different models. We've got an evals, um, website where we see which models are uh, building the best. And we got our own eval, um, suite internally. We eval as well which ones are best just with Postgres. So that's interesting for the industry and build skills around it so that they can adopt them and actually develop with Postgres. So yeah, it's a lot of testing and in fact pretty much now a lot of um, our engineering effort is going into testing specific use cases rather than the building. We want to think through how people are building and build suites around that.
Speaker D: Gary, when you built gbrain, you built it on top of Supabase. Talk about how did you decide to build it on top of Supabase? Well, how is it like for you to be a user?
Speaker B: Yeah, I guess. I mean gbrain was like a distillation of a bunch of stuff I wrote. Like I first worked on Gary's list, which was like agentic. It was like an agentic newsroom. And I had to build up like basically a research system for rag and for like policy and papers. And it would like read every newspaper article about a given topic and then try to synthesize. Um, and then I took that and then distilled it into open, ah, source retrieval for OpenClaw. Because the idea was like, okay, I had it in Rails and that was kind of like a Foxconn factory for agents. It's like I treated every LLM call as very expensive and incredibly dangerous. And then when I saw openclaw, it was this, you know, it was kind of like Esalen. It was just like a very different way for uh, you know, you to work with AI because then it's like, oh, the AI is smart, uh, it's not trying to hurt you. And then you should just let it like do stuff and you should just give it data and capabilities. And so I recognized a million tokens is actually an incredible working memory. Like most human beings only have like seven plus or minus two things that they can keep in their head. Whereas like a million tokens is like basically uh, like three Harry Potter books. But then even that is like a little bit limiting for the agents. Like keeping the correct three Harry Potter books in your context at any given time is a real challenge. So it felt like there was this thing in between for a company brain or like my personal stuff, it's like I have half a million markdown files on like every communication I've ever had. And so this thing really does have context on me and everything that I care about. Uh, but then at any given moment like the agent, it might need like two pages or something. It's a retrieval problem. And so uh, at that point, you know, at many, I think it's like 30, 40 gigabytes, you need PGVector, you need Postgres. You know you can do graph databases very easily in SQL. And so that's what GBrain is. It's like you know, RAG retrieval, um, plus like a graph database that creates like structure out of unstructured data. And so it's like dynamic schemas like a little bit like what I remember, uh, Palantir was back in the day. Yeah. And then you know, the entire idea is that agents are much more powerful when um, there's sort of this intermediate thing where the agent can just say like this is what I'm looking for. And it'll traverse the graph, it'll do all of the uh, you know, uh, vector search and it'll come back and say like here, here's a report. And like load this into context. And so that's what GBRAIN is. And then Supabase was just like very straightforward. It's like I need, I need hosted postgres and I need it to be able to support like a 50 or 100 gig or 300 gigabyte, you know, database, uh, corpus really fast. And uh, it's been great. Like you know, the auto scaling works really, really well. And now the funniest thing is like with browser use, like I use a uh, side browser now for browser use. And it's like oh yeah, like openclock can go into Supabase and you know, use the database or the new APIs you made
Speaker A: and
Speaker B: it just like managed it itself. It can like self manage.
Speaker A: Were you having to prompt it to figure out the data structures like graphs or RAG or anything like that?
Speaker B: I mean what's funny is I remember going into claude code and just saying use exa and download and diarize, uh, every paper you can find in AI research. Um, today I could use alpha signal or something. But it's like go and find every piece of research about rag and graph databases and text retrieval and then summarize it for like my use case which is like how do I help an agent get access to this stuff? And then after it did that, it's like, oh, okay, well here's how we're going to do it.
Speaker A: Yeah. I was at a dinner the other night on like the future of databases. And one idea was like databases essentially are like a retrieval mechanism for data. And you know, you can put indexes so that they'll search across the data in certain formats. So a graph or rag. And then one of them, which was super interesting, was just like putting an agent on a loop to create the perfect data structure for the search. Like if you're searching this data set this many times and it's taking 10 seconds, then why don't you just put an agent on a loop to create a new type of index or find the best index for returning that in less than a second.
Speaker B: I mean dynamic retrieval is pretty clearly going to happen the second you have really, really smart codegen.
Speaker A: Yeah.
Speaker B: So I mean for now, I mean I use it for openclaw. So then uh, I use my production inst. Then the traces from that, um, I extracted out like a eval data set and then I have a separate repo, um, called gbrain evals. And it's got 40 different categories of like specific types of retrieval, uh, ah, retrieval efficiency, like cost efficiency, latency. And then the uh, cool thing about evals is then you can just tell the agent like loop, you know, just auto research and loop. And anything that uh, improves your stats on this eval, like ship it into master on by default.
Speaker A: Yeah.
Speaker B: And anything that you tried that didn't work, write a markdown file that you know, explains why you think it didn't work and then file it away. In gbrain evals, I use capi. There's a, you know, capi has this concept of captains, uh, which is kind of like similar to Grokbots bots. And so you can just give it a context. And so I have one that is always going, that's like come up with new categories and I have another captain that's uh, always going that's like go through all the categories in evals and auto research and every single day try to find a way to improve our scores on our own internal evals. And that's just going all the time. It's a very, very primitive uh, version of RSI for like a particular use case. But I guess if you like go up one level of abstraction, you know, you could do that. You're not for uh, my use case which is from, for openclaw or something like, it could just be for generically like anyone's retrieval use case like the Only thing that changes is, like, the use case and, uh, the traces and the data set.
Speaker A: You obviously know about evals and you can improve your software because you're, like, wrapping this framework around it. Do you think that in the future builders, we'll have to actually know about these type of things?
Speaker B: Maybe not. I mean, honestly, I feel like we're so early that, you know, I'm just messing around and, you know, I like doing it in open source and someone else, you know, I hope someone looks at that and says, like, oh, I can apply that. You know, like, we're. I think we're literally coming up with the primitives on how to use this stuff right now. Yeah, I mean, I remember earlier in the year, you know, reading about Steve Yegi's, uh, software factories and things like that, and then not being able to totally figure it out, and it's like, oh, no, no. I feel like now I've cobbled together something that works for me at least.
Speaker A: Yeah,
Speaker D: yeah. When we had Boris Turney here, um, his vision of the future of coding was more like, you just talk to Claude like a friend. You don't have to know about evals and all this stuff. And, like, Claude just, like, figures out how to build the thing that you have in your mind.
Speaker A: I've got domain name openusd.dev. and it's because there's actually a file format called openusd and I collect domain names. And then suddenly Stripe and Visa and everyone announced OpenUSD. And I was like, oh, I better put this domain to use now. But I never had time to use it. So I was chatting to the dot and it's like, developed this developer site with the ecosystem and everything. And I was just chatting to it on my computer. And then, um, like, as I was winding down my day, I called it on my phone, like, as I'm getting to bed. Which sounds sus, but, um, I promise I'm just
Speaker B: checking
Speaker A: in, just, just coding with it. And I was like, saying, uh, I don't like the information architecture of how, like, the ecosystem links to the use cases. Can you make some suggestions? And it did. And I said, okay, yeah, implement them. And then 20 seconds later it said, oh, uh, yeah, okay, I've done it. Do you want to refresh? And I refreshed the site and it was really well written and everything was linking together and it's hooked up the SEO type stuff. And so I haven't done all the classic stuff that I'd have to do traditionally. I've just Been chatting to it and it really felt like one of those moments where I sort of saw a glimpse of the future.
Speaker B: I mean, you can do that because you know what you want to build.
Speaker A: That's the thing. Yeah. So like, I obviously have a background in engineering, so I kind of know how to prompt it, but I'm trying to not say anything. I'm trying not to point it towards GitHub or anything like that. And I'm trying to code like a Normie or someone will do next year so that I know it's basically so I can Dog food, Supabase, um, and know that. Oh, is it going to have a good time with Supabase in one year's time?
Speaker B: Yeah. It's funny for Boris to say, like, oh, I just wanted to do it automatically and like, certainly once it's into distribution, like literally the model has it, you know, in its weights, it can do it, but until then it needs like some markdown or so you just like a lit. Like not even a lot of prompting, like very small amounts of prompting. It can just do it. I. We're entering this very strange moment in society, I think, where like, uh, it sounds like RSI really is here and it's like going from like the 20% to 80% moment of like AI research is just happening, um, in sort of these, inside these loops inside, you know, Claude code or Codex or wherever it is. And then simultaneous to that, like society doesn't really have enough people like you, Paul, who like know what to build and how to ask it. And so it's like unstoppable force meets immovable object. Right now, like the capabilities, the models are like going parabolic. And then the number of people who know how to actually have an impact on society with it is like more or less constant.
Speaker A: Yeah. And want to be kind of excited by it. I think that's the other thing. I think a lot of people are getting paranoid, but I'm genuinely excited about what the future could be for a lot of people. A lot of my previous startups were focused on like blue collar workers and like people who I was wrapping tech around. A lot of people who just had to work a lot of their life, you know, and I. The thing that I really love about Supabase is that it's um, like I see a lot of entrepreneurship, um, because of the platform and so I can see this future where actually there is going to be so much more entrepreneurship and it's actually quite a fulfilling lifestyle for a lot of people. So I'm pretty pumped about 2027, actually. As long as we can keep this cadence up and avoid a few, few crazy events, then, then it should be a fun ride for a lot of people.
Speaker B: We're seeing this moment where vertical SaaS founders actually are kind of struggling with raising Series A's. Uh, you know, when you're subscale at like, you know, 5 to 10 mil ARR even, which like, historically is a lot of ARR, that's like a guaranteed Series a. Even like nine or 12 months ago. And today it's like, uh, I don't know, people are kind of like, not really into it, um, for vertical, like horizontal and AI investments. Like, seems like it's totally, uh, greenlight. But like, vertical SaaS people are really struggling. But it's also sort of happening right at the moment where you can get to 10 to 15 mil, often 25, 30 mil, 50 mil with like 10 or 15 people. And so at that point, like, you're very profitable at that point.
Speaker A: Yeah, yeah, yeah. With like, if you got 15 people, 2 million ARR per head, and with 50 margins, you're all making a million million a year. I mean, that's an amazing outcome for, for a lot of people. Yeah.
Speaker B: Uh, it's simultaneous to that. We just do a lot of office hours with people who do like, they got the brass ring and then they're bummed out that they can't raise the Series A. And so, you know, uh, many of my office hours there are just like, you're probably going to look back on this as a blessing because you don't need the money. Like, time was you had to raise like a hundred million dollars to get to like 30 million a year in revenue because you just had to hire all these people and now you don't have to do that.
Speaker A: Yeah, yeah. There's a real thing in startups like the badge. I mean, it was the same for me, like, to get funding at the start, like, feel felt like, you know, I was achieving something great. But actually, you know, to actually not fundraise now would in my mind be like, oh, that's achieving something great. So, like, I'm a little bit envious of these companies that, that are getting to that point.
Speaker B: Yeah. So I don't know. I mean, it's a super changing world. But, um, your supabase of all the companies has really been able to ride high through every single wave. Um, do you have any thoughts for people as they try to emulate what you've done?
Speaker A: One thing that helps me sleep well at night is that it's kind of the Lindy effect. Databases have been around for 50 years. I think they'll be around for another 50 years. And this is one that at the end of AI, no matter what, I'm pretty certain there'll be databases. So pause from that, whatever you will like, uh, you got to choose categories that are very durable. And if you're going to bet your entire life, which is basically what I'm doing, you choose the category that you feel is worth investing in. I think the other one is like, things are changing so fast. So we don't try to have all the answers as Supabase, but we just try to make sure that we're always adapting the fastest. And you know, for me, I've uh, evaluated or like watched a lot of my favorite dev tools. Um, they kind of start with the developer focus and then they always move up and they become very corporate and they kind of stagnate a lot and they lose that love. And from our point of view, at least from my point of view, companies like Stripe, for example, they have this real like someone like uh, a founder who just cares about like almost focusing on what the new ways of building are. Uh, and so if you're like building for this next wave, you just always need to be one eye on the future of what is next, which is a very short timeline now. Things are moving so fast, but, um, being super adaptable, um, and making sure you've got capacity within your team to shift very fast, that's the thing that we're focusing on for the next year.
Speaker C: I think that you've learned maybe any specific things you've learned there because you've had, maybe you had the initial vibe coding inflection point and Then the opus 4.8 inflection point and just cogen the next sort of wave. Hopefully next many inflection point hit for you. But are there things that you'll do differently to be better prepared for it?
Speaker A: Well, first of all, dog fooding is one of the most important things, at least from our um, perspective. So I'm always trying these tools with ours to know where are the gaps. There's no better feedback than you getting stuck on your own tooling, um, and then having capacity. So we try to partner with, with the key players in the space and this ecosystem player has been really helpful because they give us feedback on what they're building and we try to leave some capacity within the team, which is also very difficult. Um, so that when they have ideas we can give it a shot. And not a lot of the bets actually win. Even when they seem like we're partnering together to do some new cool thing we actually don't know. They might sound cool, and we try them out and they kind of flop, but the ones that do work then end up meaning that we ride this awesome wave together.
Speaker B: That's a great note to end on, Paul. Thanks so much, man. We'll see you guys next time.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.