--:-- Garry: 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 CloudCode 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.
--:-- Paul Copplestone: Thanks for having me.
--:-- Garry: So to start off, 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. Something like 70% of the new activity is from agents. Isn't that crazy?
--:-- Paul Copplestone: Yeah, it's wild. This year especially, what we've seen in terms of the numbers, the inflection is just a huge shift towards agents.
--:-- Harj: Just so we can understand how much you guys have grown — it's kind of mind-boggling. What are the numbers you care about? Where were you this time last year and where are you now?
--:-- Paul Copplestone: This time last year, we were around three million signups. Now we're at 13 million. Revenue will grow 4x this year. We have over a million databases being created per week. Databases under management are approaching 50 million. This time last year it was 8 million. It's just a huge, huge inflection.
--:-- Harj: What's been driving that?
--:-- Paul Copplestone: First, people are building with abandoned software engineers. Second, there are a lot more builders coming online. What was traditionally something for someone with a software engineering background is now becoming possible for non-engineers to actually build things on top of Supabase. This is a really big shift.
--:-- Jared: What have you guys actually done to facilitate or encourage this shift? Obviously software engineers are going to keep choosing Supabase, but how do you get the agents to come over in the first place?
--:-- Paul Copplestone: We've largely seen 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. 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 in the LLMs. We were a huge beneficiary of the timing of when we started to become a default choice for databases.
--:-- Jared: How much do you think being open source played a role? The agents love open source things.
--:-- Paul Copplestone: It's hard to know the counterfactual, but I think it was critical. Everything that we do is open source and it seems to have been a huge benefit to us. We do it in a very open source-y way. We try to support existing tools. It's not just Supabase tools. We support Postgres, which is a very famous tool for the Postgres ecosystem, and we help maintain it. We got sprawl across many communities. I would guess that the agents actually really like open source because when something goes wrong, it can just look at the source.
--:-- Garry: Yeah, the agents really like feeling powerful and they love data. There's nothing more frustrating than hitting a brick wall and not knowing what's going on and not being able to fix it.
--:-- Paul Copplestone: I think it's going to be increasingly important as well. With security being so important, a lot of enterprises are going to want to inspect the source code to know that it's secure. If you've got closed source code, you probably won't want to adopt them as a vendor.
--:-- Harj: Is "developer" still the core user you're going after? How do you think about it now in 2026?
--:-- Paul Copplestone: The world we're moving towards — at least what we're seeing this year — is that builders are coming online in crazy numbers. The crazy thing is that usually when your top of funnel signups are accelerating, you see a lot of the other numbers start to decline — activation, conversion. But actually this year, all of them are going up and to the right. That's a bit insane. 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.
--:-- The distinction is "builder" — they might not be software engineers, they might just be someone who needs to build a thing. They're popping open Cloud Code, and it turns out files only get you so far. This category of people has all these pent-up ideas that they could never convince a software engineer to help them build. 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 growth of the builder segment is pretty big. I don't know where the ceiling is on this one. Our early investors said PLG would tap out at this revenue and we'd have to move into this other segment of the market. There just appears to be no ceiling so far. I can't see where it stops.
--:-- Garry: That was basically true two years ago or one year ago, but definitely not true this year. I was just talking to someone this last weekend who fits the builder category. He's a fintech founder who just exited his company for over a billion dollars. He's always been product-adjacent — studied math as an undergrad, could pull together some Ruby scripts — but always needed an engineer to build the software. Now he's building side projects on his own. He has all the knowledge from building a fintech company, so he can build pretty sophisticated software for his own personal finances — balance sheets, tracking software, bank integrations. He's writing all the integrations from scratch. That's the kind of software that would never have been built even two years ago.
--:-- Paul Copplestone: These are the perfect type of builder. Developers like me have very developer-focused ideas. But domain experts know exactly the niches — "this is an unsolved problem in my niche." They're able to dig right into those niches without having to convince someone else to join them.
--:-- Harj: I think you guys were talking about this in YC — the profile shifting even from who you're bringing into the cohort. If you look at the era of 2022 to 2025, there was this real shift: "AI is coming, and having software engineering as a core — you need a technical co-founder no matter what." That was a mega idea that really came to the fore at YC. Then in the last year, we said, "Actually, yeah, builders." We're starting to see people who can build. The much harder thing to do is to know what to build. Being able to build is something anyone can sort of have on tap now. That's a really cool thing. Can you imagine all the things that never would have been built? People knew people would buy this, knew there was a problem, but at the margins those people couldn't convince an engineer to work on it.
--:-- Jared: Do you have some examples of apps that people have built on Supabase — maybe just for themselves — that are the kinds of things that would have never been built before?
--:-- Paul Copplestone: One cool example was at our conference. Afterwards, this guy from Brazil came up to me. He built an entire taxi app from his phone — a little mini Uber for his local market. He's a taxi driver himself. I don't actually know why he built it, but the fact that he could build it... He came up extremely grateful. He was 50 years old or something, but he had the energy of a teenager building something. That's kind of cool. There's so much uncertainty about what the future of work will look like, but in this category of builders, there's that excitement about the future. That's what I really love about Supabase. People who were uncertain are now discovering this skill set and these opportunities where previously they were just blue-collar workers.
--:-- Garry: You've been building some of your own personal software recently. Talk about what you've been cooking.
--:-- Paul Copplestone: It's grown out of getting really addicted to OpenClaw about six months ago. I said there was going to be no UIs and it was all just going to be chat through my OpenClaw. I was also really determined not to use the database for a long time — I wanted everything to be in markdown. But it turns out you hit a point where a database is useful and you do need UI. So I've been building that over the last couple of weeks.
--:-- I call it "Control Tower." It's every section of my life. I have a UI to triage all my email so I don't need to read my inbox. Finances — tracking spending. Health — tracking my weights and my workouts. Everything is all in one place.
--:-- The magic of it is mind-boggling. The finance section of my one app for myself is at least feature-parity with Mint or Monarch or all of those things. In some ways it's 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 and categorize it correctly. That was a whole company — several startups — just doing personal finance. Now you just build it for yourself. I don't need it to work for anyone else or have anyone else's opinion on it. It's just my thing. It's kind of awesome.
--:-- Harj: We see a lot of that — finance and health. Those are the two where you want your own data. Syncing all the devices to a single database is kind of a magic skill. Then you can prompt it to build correlations across everything.
--:-- Paul Copplestone: The correlations are really valuable. With the health example, all that data is in my Supabase database, but it also has access to my calendar. So it knows things like, "Your weight went up recently, but you were traveling, so that's okay. You can get back on track next week." It has this context that's really valuable.
--:-- I also found that as I started using personal agents, I got a little paranoid about putting all my routines and everything into one agent. So now I'm slowly extracting it out so that if I want to attach different agents on top, I know I can use any agent. The CRM is another really critical one.
--:-- Garry: That's why you guys are so valuable. 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. That's a totally wild idea if you think about the history of databases. It used to be that the world had a relatively small number of very large databases run by large companies. When Supabase got started, you had this idea that it should be really easy for everyone to make a database. It almost didn't make sense at the time why so many people would want to do that. Unless you can write code, what can you do with a database? There aren't that many people who can actually write code and build a personal CRM like that. It's just too much work for most people pre-AI.
--:-- Paul Copplestone: Another example where Supabase is really valuable for me is the file upload section. It sounds very simple. Any file I can forward via email or just dump into this UI. Then my agent figures out what that is, how it's relevant to my life, and what to do with it. That's all being stored on Supabase. Supabase is going to end up having all of the data about my life in a single place. 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.
--:-- Garry: You have an S3-compatible Supabase files thing?
--:-- Paul Copplestone: Yeah. All my stuff is in that.
--:-- Garry: It's default in Gbrain. Great. Thank you.
--:-- Harj: Do you think this is the future, Paul? Where basically everyone in the world — not every developer, every person — will have a Supabase database that has stuff about their life? Their health, their finances, their relationships?
--:-- Paul Copplestone: We'd love that. I certainly think it'll be the case that everyone in the world with access to AI will become a builder of some sort. You can build anything, you can customize it. If you want to make tweaks to some app or some UI, you don't have to be beholden to someone.
--:-- We think of ourselves as an index company. When we came into YC, we focused on YC companies. We wanted to win all YC customers. That was because we knew we had to be there on day one when businesses were getting started. The mission didn't change, just the aperture has increased significantly. As more builders come online, we know we need to service them. That's a whole different problem to solve, but an exciting one.
--:-- Jared: Significantly meaning 10 million times?
--:-- Paul Copplestone: We launch a million databases every single week. But if you do some basic arithmetic — ChatGPT has 1.2 billion weekly active users. If all of them want to launch something every month, that's 1.2 billion databases a month. That's the scale we're moving towards. We need architectures to cater for that scale, which is something that has never had to happen before in the database realm.
--:-- Jared: 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?
--:-- Paul Copplestone: If we could negotiate better with AWS, then maybe we could. But everyone wants computers at the moment. You don't need such a Ferrari for a lot of these workloads. We made an acquisition recently — Terso. They've got an architecture that's compatible with Postgres and also compatible with SQLite. SQLite is a phenomenal database. We'll provide this tier called Supabase Spark, which is for these getting-started workloads. The idea is the same: you get started with the same experience, you can scale up to petabytes. Our tagline is going to be "prototype to petabytes." We as a company need to make sure we can provide for everyone. If they do scale up and their business keeps growing, we make sure they have a great time.
--:-- Garry: That's something I was curious about. The classic software company starts with early-stage startups, then has one eye towards the enterprise. Pre-AI, the conventional wisdom for a database company was you want to be Oracle, so you get to the enterprise as quickly as you can because that's where all the money is. You start building out enterprise features. Leaning into SQLite is sort of going the opposite direction. How do you think about it? Are you looking both ways?
--:-- Paul Copplestone: We're having to do both, which is incredibly difficult. We've got two products that cater to the two ends. Multi-region, scale up to petabytes, and then scale down to prototyping and SQLite-type workloads. Trying to do this at the rate of growth while employing more people — even with AI — has been a real challenge, but a fun one.
--:-- Harj: You ran a poll recently where people went from 10% of your engineers writing 80% of their code with coding agents to that number recently getting up to 60% in a matter of six months. How did that happen? Where is this going from here?
--:-- Paul Copplestone: We don't have an AI policy internally. We just let people do whatever they want and give them access to whatever tools they want to use. Now they're convinced that the models can do so much better work and so much more. The adoption has been crazy. The things they're building internally are not just vibe-coded type stuff. They're pretty intense. As we shift into this AI-coded realm, the amount of testing we're doing and the tools we're adopting for testing has been pretty useful to make sure the end result is going to be good.
--:-- Harj: We're seeing that across YC. The YC startups are all vertical because everyone's doing CI. The number of tests is through the roof.
--:-- Paul Copplestone: The models are good enough now. People spend enough time and realize, "Oh, this is quite good." Engineers need to be convinced. They might not have thought it was very good at the start of the year. The models have gotten better, and they're starting to see that you can achieve great things. All the stuff with Navier Stokes and breaking new ground — that convinced the market. Now people are convinced this is the way it's going to be.
--:-- Jared: You've seen Supabase through three eras: first as a dashboard company built in 100 days during YC, then the API company, and now this "make something agents want" moment. Was there one or two things in each era that really jumped out where you thought, "That was the thing that made us in that moment"?
--:-- Paul Copplestone: Those shifts happened. The first one — why would a database company exist when we came into YC? It seemed like such a contrarian idea. We saw how hard it was to use a database even for developers. The dashboard-first approach was, "Let's build a UI that looks like Airtable on top of Postgres." I loved Airtable. I thought, "Wouldn't it be cool if that was just a Postgres database on the backend?" That one was about seeing that even software engineers struggled.
--:-- When we moved to AI, the API shift happened because someone was integrating with us and said, "We want to launch lots of databases. We need an API to do all of this." That was 2021. It turned out to be exactly the right move for 2024 when Bolt, Lovable, and all those people started building on top of us.
--:-- This year, I saw that no one comes to the dashboard anymore. No one visits dashboards. So how are agents going to build? I 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. If it exists on the dashboard, it basically has to work in lockstep in code — infrastructure as code. We re-architected a lot of the CLI and everything to work in sandboxes in code.
--:-- Garry: Were you ever inspired by Parse or Firebase?
--:-- Paul Copplestone: Yeah, Parse and Firebase. I liked both of those companies. It's funny how these waves work. They did the backend — Firebase acquired by Google, Parse by Meta. In some ways, they blazed the trail for us to come along and have a legitimate database business. In 2014, it would have been ridiculous not to use RDS for your database. Then Mongo came along and moved to Atlas. A lot of these database companies showed that you don't need to use one of the three hyperscalers. You can have a legitimate database company. That timing was crucial for us.
--:-- Garry: Parse is sort of forgotten now, but it was a really well-built product. They launched just when I was building iPhone apps for the first time. It was nice to switch to a nice, RESTful API instead of dealing with what I was trying to deal with.
--:-- Paul Copplestone: These shifts always happen with inflection points. At that point, two things happened in the market. Mongo somehow convinced everyone that NoSQL was an amazing way to store your data. The second was mobile. We're fortunate that we had a couple of these waves as well. Now we're right in the thick of it.
--:-- Garry: This is what I was asking about — how you think about the enterprise early. If you go even further back, Heroku was the first where it was, "Start with the best developer experience and then scale up." But it can be quite hard to scale up with people. Heroku couldn't quite bridge that gap — how to keep people on you as apps get bigger and need to be more performant. Historically, every company has had to figure that out. I know you guys are looking that way, but you might not have to. If the market for owning 0 to 10 whatever keeps expanding at this rate, it's going to be huge.
--:-- Paul Copplestone: We want it all. We might not have to, but we definitely do. Kudos to Heroku — they popularized Postgres. But at the time, Postgres was still pretty nascent and had some scaling limitations. We've had to wrap Postgres in tooling that will allow it to scale indefinitely.
--:-- Garry: A better analogy for you guys is AWS. They were able to get people early and scale. What are the lessons? How do you think about making sure you can scale infinitely?
--:-- Paul Copplestone: I heard a stat — 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 scaled up. That's the category we want. We know that convincing people to migrate from one database provider to another is near impossible. We just want to be there on day one, make sure they have a great time, and make sure they don't want to leave. It's basically the best business model on earth if you can get it. You get them on day one, you scale with the fastest-growing companies in the world, you do that for a generation, and you become a generational business.
--:-- It's hard for us because what "day one" looks like is rapidly changing. In the past, day one for me was always YC customers. Now day one is becoming, "Okay, everyone's a builder. What are they going to use? What are the modalities? How are they going to choose their databases?" These are tricky questions.
--:-- Harj: It's a different customer segment. When you started, there was not an individual market for databases. The idea of a database company being a direct-to-consumer business would have sounded like a syntax error. Now you have two segments: early-stage companies with that powerful business model, and you're also selling directly to consumers or to their agents.
--:-- Paul Copplestone: Yes. Those use cases presumably won't scale the way startups will, but they might just continue to use you for the rest of their lives because you're powering the app that runs their personal finance software or their taxi cab company. As their lives grow and they accumulate information, it becomes an index of their own growth. They just store more. People are collecting more data. This prosumer market is essentially a good growth vector for us.
--:-- Harj: Do you think about the personal agent world through that perspective? If coding agents want Supabase, that's clear. Do you think about the next phase as assuming we all have personal databases? Do you need to do anything to make it easy for personal agents to talk to you? Is that any different?
--:-- Paul Copplestone: I'm very bullish on personal agents now. After a week of my AI being away and learning exactly what they can do, I'm obsessed with the idea of building for personal agents. I told our company we're code-first, 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 directly.
--:-- The way I've been building is using Dots. I sit on a phone call with it all the time and chat to it, saying, "Can you make these changes?" My heuristic to make sure I'm dogfooding correctly is that I don't look at the code. I don't allow myself to check the architecture except when I want to check that it's actually building things correctly. When I'm making changes, I just want to talk to it and see what it can change.
--:-- Garry: It's crazy. It's doing phenomenal stuff that feels like something out of a sci-fi movie from two years ago. I'm having so many of these moments that are mind-blowing. If you had shown someone this six months ago, they would have thought it was impossible.
--:-- Jared: I was at your Supabase Select conference a couple of weeks ago — awesome conference, by the way. I had this crazy thought. I was sitting there, and you were talking about all these awesome new features. I thought, "If I was building an app on Supabase, maybe I wouldn't even care to understand all these awesome features myself. I want to send my agent to Supabase Select to listen to all the awesome new features and figure out how to integrate them into my codebase."
--:-- Paul Copplestone: That's wild. A truly virtual conference. We should do that. A conference just for agents.
--:-- Garry: A conference for agents. They all turn up live. They can talk to each other, exchange tips.
--:-- Paul Copplestone: You can bridge it. You can airdrop the markdown files for everyone, but you have to be there in the audience to get it. We'll call it the Artifactory.
--:-- Garry: Oh, man. I quite like that.
--:-- Harj: We talked about this before — there's a bunch of things you've been doing that make agents like you better. Error messages, for example. What was that key insight? Are there a bunch of other things you're doing that are obvious on one hand but nobody's doing yet?
--:-- Paul Copplestone: The error messages — I was at a DevTools meetup last night and was surprised this wasn't so obvious. We really dug into our error messages so that you can take a use case like, "I want to build an application." Developer error messages are typically "500" or something basic. You know there's a problem, but now you want the agents to remedy themselves. Inside the error messages, we're literally telling them how to fix this error or to go read some docs to fix it. A lot of it is picking your use case and doing these loops to improve your own error messages so that you can one-shot basically anything you want.
--:-- Garry: That makes sense. If you're being used by an agent, the agent will encounter an error message. In the past, a human would have to go Google that and do a bunch of stuff. Here, you can just say, "You're out of inodes, so you should probably go do this."
--:-- Paul Copplestone: There are two stages to winning the agents. First is being picked by the model. Second is — if they get stuck, you don't want them to switch away. They'll get stuck at some point. You just want to give them the tools to remedy. 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 was previously just for humans and developers — for agents.
--:-- Harj: 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?
--:-- Paul Copplestone: Yeah. All the different models. We've got an evals website where we see which models are building the best. We've got our own eval suite internally where we eval which ones are best with Postgres. That's interesting for the industry. We build skills around it so that they can adopt them and actually develop with Postgres. A lot of 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.
--:-- Jared: When you built Gbrain, you built it on top of Supabase. Talk about how you decided to build it on top of Supabase. How is it for you to be a user?
--:-- Paul Copplestone: Gbrain was a distillation of a bunch of stuff I wrote. I first worked on Gary's List, which was an agentic newsroom. I built a research system for RAG, for policy and papers. It would read every newspaper article about a given topic and try to synthesize. Then I took that and distilled it into open source retrieval for OpenClaw.
--:-- The idea was that I had it in Rails, and that was kind of a Foxconn factory for agents. I treated every LLM call as very expensive and incredibly dangerous. Then when I saw OpenClaw, it was kind of like Esalen — a very different way to work with AI. It's like, "Oh, the AI is smart. It's not trying to hurt you. You should just let it do stuff. You should just give it data and capabilities."
--:-- I recognized that a million tokens is an incredible working memory. Most human beings only have seven plus or minus two things they can keep in their head. A million tokens is basically three Harry Potter books. But even that is a little limiting for the agents — keeping the correct three Harry Potter books in your context at a given time is a real challenge.
--:-- So there was this thing in between for a company brain or my personal stuff. I have half a million markdown files on every communication I've ever had. This thing really has context on me and everything I care about. But at any given moment, the agent might need two pages. It's a retrieval problem. At 30 or 40 gigabytes, you need PG vector, you need Postgres. You can do graph databases very easily in SQL. That's what Gbrain is — RAG retrieval plus a graph database that creates structure out of unstructured data. Dynamic schemas, a little bit like what I remember Palantir was back in the day.
--:-- The entire idea is that agents are much more powerful when there's this intermediate thing where the agent can say, "This is what I'm looking for," and it'll traverse the graph, do all the vector search, and come back with a report and load it into context. Supabase was very straightforward. I needed hosted Postgres that could support a 50, 100, or 300 gigabyte corpus really fast. It's been great. The auto-scaling works really well.
--:-- Now the funniest thing is with browser use. I use a side browser for browser use. OpenClaw can go into Supabase and use the database or the new APIs you made. It just manages it itself. It can self-manage.
--:-- Jared: Were you having to prompt it to figure out the data structures — graphs, RAG, anything like that?
--:-- Paul Copplestone: What's funny is I remember going into Cloud Code and just saying, "Use Exa and download and diarize every paper you can find in AI research. Go and find every piece of research about RAG and graph databases and text retrieval, and summarize it for my use case — how do I help an agent get access to this stuff?" After it did that, it said, "Okay, here's how we're going to do it."
--:-- Harj: I was at a dinner the other night on the future of databases. One idea was that databases are essentially a retrieval mechanism for data. You can put indexes so they search across data in certain formats — a graph or RAG. One idea that was super interesting was just putting an agent on a loop to create the perfect data structure for the search. If you're searching this dataset this many times and it's taking 10 seconds, 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?
--:-- Paul Copplestone: Dynamic retrieval is pretty clearly going to happen the second you have really, really smart code gen.
--:-- Jared: For now, I use it for OpenClaw. I use my production instance. From the traces, I extracted an eval dataset. I have a separate repo called Gbrain Evals with 40 different categories of specific types of retrieval — retrieval efficiency, cost efficiency, latency. The cool thing about evals is you can tell the agent, "Loop. Auto-research and loop. Anything that improves your stats on this eval, ship it into master by default. Anything you tried that didn't work, write a markdown file explaining why you think it didn't work and file it away in Gbrain Evals."
--:-- I use Cappy. Cappy has this concept of "captains," which is similar to Grok bots. You can give it a context. I have one that's always going: "Come up with new categories." I have another captain that's always going: "Go through all the categories in evals and auto-research. Every single day, try to find a way to improve our scores on our own internal evals." That's going all the time. It's a very primitive version of RSI for a particular use case.
--:-- If you go up one level of abstraction, you could do that generically for anyone's retrieval use case. The only things that change are the use case, the traces, and the dataset. You know about evals, and you can improve your software because you're wrapping this framework around it.
--:-- Harj: Do you think in the future builders will have to know about these types of things?
--:-- Paul Copplestone: Probably not. Honestly, we're so early. I'm just messing around. I like doing it in open source. Someone else will look at that and say, "I can apply that." We're literally coming up with the primitives on how to use this stuff right now.
--:-- Jared: Earlier in the year, I was reading about Steve Yegge's software factories and things like that, and not being able to totally figure it out. Now I feel like I've cobbled together something that works for me.
--:-- Garry: When we had Boris Turney here, his vision of the future of coding was more like you just talk to Claude like a friend and you don't have to know about evals and all this stuff. Claude just figures out how to build the thing that you have in your mind.
--:-- Paul Copplestone: I've got this domain name, openusd.dev. There's a file format called OpenUSD. I collect domain names. Then Stripe, Visa, and everyone announced OpenUSD, and I thought, "I better put this domain to use." I never had time. So I was chatting to the dot, and it developed this developer site with the ecosystem and everything. I was just chatting to it on my computer. As I was winding down my day, I called it on my phone as I was getting to bed — which sounds sus, but I promise I was just checking in, coding with it. I said, "I don't like the information architecture of how the ecosystem links to the use cases. Can you make some suggestions?" It did. I said, "Okay, implement them." Twenty seconds later, it said, "I've done it. Do you want to refresh?" I refreshed the site. It was really well written. Everything was linking together. It hooked up the SEO stuff. I haven't done all the classic stuff I'd have to do traditionally. I've just been chatting to it. It really felt like one of those moments where I saw a glimpse of the future.
--:-- Garry: You can do that because you know what you want to build. That's the thing.
--:-- Paul Copplestone: I have a background in engineering, so I know how to prompt it. But I'm trying not to say anything. I'm trying not to point it towards GitHub or anything. I'm trying to code like a normie — like someone will do next year — so I can dogfood Supabase and know if it's going to have a good time with Supabase in one year's time.
--:-- Garry: It's funny for Boris to say, "I just wanted to do it automatically." Certainly, once it's into distribution, the model has it in its weights and it can do it. But until then, it needs some markdown or something. Not even a lot of prompting — very small amounts. It can just do it.
--:-- We're entering a very strange moment in society. It sounds like RSI really is here. It's going from the 20% to 80% moment of AI research happening inside these loops inside Cloud Code or Codex. Simultaneously, society doesn't really have enough people like you, Paul, who know what to build and how to ask it. It's an unstoppable force meeting an immovable object. The capabilities of the models are going parabolic, and the number of people who know how to actually have an impact on society with it is more or less constant.
--:-- Paul Copplestone: And you want to be kind of excited by it. 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 blue-collar workers — people who I was wrapping tech around, people who just had to work a lot of their life. The thing I really love about Supabase is that I see a lot of entrepreneurship because of the platform. I can see this future where there is going to be so much more entrepreneurship. It's actually quite a fulfilling lifestyle for a lot of people. I'm pretty pumped about 2027, actually. As long as we can keep this cadence up and avoid a few crazy events, it should be a fun ride for a lot of people.
--:-- Harj: We're seeing this moment where vertical SaaS founders are struggling with raising Series A when they're subscale at 5 to 10 million ARR. Historically, that's a lot of ARR — a guaranteed Series A even nine or twelve months ago. Today, people are kind of not into it for vertical. Horizontal and AI investments seem totally greenlit. But vertical SaaS people are really struggling. It's happening right at the moment where you can get to 10 to 15 million, often 25 to 30 million, 50 million with 10 or 15 people. At that point, you're very profitable.
--:-- Paul Copplestone: If you've got 15 people, 2 million ARR, with 50% margins, you're making a million a year. That's an amazing outcome for a lot of people.
--:-- Harj: Simultaneously, we do a lot of office hours with people who got the brass ring and then they're bummed out that they can't raise the Series A. Many of my office hours are just, "You're probably going to look back on this as a blessing because you don't need the money." Time was you had to raise a hundred million dollars to get to 30 million a year in revenue because you had to hire all these people. Now you don't have to do that.
--:-- Paul Copplestone: There's a real thing in startups about the badge. It was the same for me — getting funding at the start felt like I was achieving something great. But to not fundraise now would be achieving something great. I'm a little envious of these companies that are getting to that point.
--:-- Jared: It's a super changing world. Supabase of all the companies has really been able to ride high through every single wave. Do you have any thoughts for people as they try to emulate what you've done?
--:-- Paul Copplestone: One thing that helps me sleep well at night is the Lindy effect. Databases have been around for 50 years. I think they'll be around for another 50 years. At the end of AI, no matter what, I'm pretty certain there'll be databases. You've got to choose categories that are very durable. 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.
--:-- The other thing is that things are changing so fast. We don't try to have all the answers at Supabase. We just try to make sure we're always adapting the fastest. I've watched a lot of my favorite dev tools. They start with developer focus, then they always move up, become very corporate, stagnate, and lose that love. From our point of view — from my point of view — companies like Stripe have a founder who just cares about focusing on what the new ways of building are. If you're building for this next wave, you always need to have one eye on the future of what is next. That's a very short timeline now. Things are moving so fast. Being super adaptable and making sure you've got capacity within your team to shift very fast — that's what we're focusing on for the next year.
--:-- Garry: Any specific things you've learned there? You've had the initial vibe coding inflection point, the Opus 4.8 inflection point, and just code gen. When the next wave hits — hopefully many inflection points — are there things you'll do differently to be better prepared?
--:-- Paul Copplestone: First, dogfooding is one of the most important things from our perspective. I'm always trying these tools with ours to know where the gaps are. There's no better feedback than you getting stuck on your own tooling. Second, having capacity. We try to partner with the key players in the space. This ecosystem play has been really helpful because they give us feedback on what they're building. We try to leave some capacity within the team — which is also very difficult — so that when they have ideas, we can give it a shot. Not a lot of the bets actually win, even when they seem like we're partnering together to do some new cool thing. They might sound cool, we try them out, and they kind of flop. But the ones that do work end up meaning that we ride this awesome wave together.
--:-- Garry: That's a great note to end on. Paul, thanks so much, man. We'll see you guys next time.
