30:09
I am genuinely excited about what the future could be for many people. What I really like about Supabase is that I see a lot of entrepreneurship thanks to this platform. I definitely believe that everyone in the world who has access to AI will become a developer of some kind. You can create anything, you can customize it. If you want to make changes to some application or interface, you don't need to depend on anyone. I'm actually really excited about 2027. Welcome back to another episode of The Lightcone. Today we have Paul Copplestone, co-founder and CEO of Supabase, an open Postgres backend that has become the standard database for
tools like Cloud Code and CodeX. Supabase now has 13 million users and creates over a million databases per week. Paul, welcome to The Lightcone. Thank you for inviting me. So, for starters, you know, YC is famous for giving away a T-shirt on the first day that says, "Create what people need." But we are all increasingly realizing that it should be "Build what agents need." And your company is truly a great example of that. You know, about 70% of new activity comes from agents. Is n't this madness? Yes, that's wild. This is simply incredible.
I think this year, especially judging by the numbers, we're seeing a huge shift towards agents. So that we can understand how much you have grown, because it is simply amazing. What numbers are important to you, and where were you last year at this time compared to now? I think last year at this time.now we have 13 million registrations. It was probably around three million 12 months ago This year, revenue will quadruple. I'm trying to remember what exactly we're doing. Currently, about a million databases are created per week. Yes, over a million. Yes, yes, yes.
How many were there last year at this time I think we actually have about 50 million databases under management now, up from 8 million last year, so that's a huge, just a huge leap. What was the driving force behind this? First, people build non-stop- software engineers. Secondly, I think there are a lot more developers emerging. So what was traditionally only possible for people with experience in software development is now becoming possible for non- engineers to create things using Supabase. So, this is a really big shift. What have you guys actually done to facilitate or encourage this transition?
It's clear that software developers will continue to choose Superbase, but how do you even engage agents? Yes, we mostly see three stages of Superbase development. We started as a control panel company, then we moved to an API company, and now we are a code-centric company, so we try to support formats that agents actually want to work with, which is code-centric. They mostly want to use command line interfaces. Another point is the choice of us as the standard in LLM, and I think we have benefited enormously from when we became the default choice for databases.
How big a role do you think open source played in this, since agents love open source? It 's hard to assess the alternative course of events, but I think it was critically important. I mean, everything we do is open source, and it seems to have benefited us tremendously, and we do it very openly, trying to support existing tools. It's not just Superbase tools. We support, for example, Postgres as a very well-known tool for the Postgres ecosystem, and we help support it, so we've kind of expanded into a lot of communities.
I guess agents actually really like open source because when something goes wrong they can just look at the source code. Yes. Yes, I've noticed that agents like to feel influential, and they love data. And there's nothing more frustrating than getting stuck in a rut, not understanding what's going on, and not being able to fix it. I think this will become increasingly important because now that security is so important, many businesses will want to check the source code to make sure it is secure. And if you have closed source code, you probably won't want to choose them as a vendor.
Is the developer still the main user you are targeting, or how do you see it now, in 2026? Yes, I think the world we're moving in, and at least what we're seeing this year, is the arrival of creators, people who create; and a huge number of people are going online. The craziest thing about this year is that usually when, say, our sales funnel or signups are growing, we see a lot of other metrics-activation, conversion- start to go down. But actually this year they're all kind of growing rapidly, so to speak, which is just incredible, because the models are getting better and better at building, and we're starting to see people who traditionally didn't have any experience in software development, but now they can come in and
build things. Here's the difference: "builder" means they may not be a professional developer, meaning it could just be someone who needs to build something and they, you know, open source the cloud code, but it turns out that you ca n't get very far with files alone. M-hm. Yes. And in a sense, this category of people has all these ideas that they could never convince a developer to help them implement, and now they don't have to convince anyone. They have all these ideas that they bring to life. Software developers still make up a huge share, but the growth rate of the " builders" segment is quite significant.
I also don't know where the line is. I remember our first investors saying that PLG, i.e. product growth, would reach a certain revenue limit and we would have to move into another market segment, but so far there is no limit in sight, and I don't understand where it will stop. I mean, that was almost true 2 years or a year ago, but it's definitely not true this year. Yes. I was just chatting with someone last weekend; This is a representative of the " builder" category, a fintech founder who just exited his company with a capital of over a billion dollars. He was always tangential to the product, studied
math at YC in undergrad, and could somehow string together a few Ruby scripts, but they always needed an engineer to write the software. And now these are outside projects; he just builds his own stuff, with all the knowledge on how to build a fintech company. So he can actually build pretty sophisticated tools for his own finances, like balance sheets and tracking software, knows how to integrate with banks, and writes all the integrations from scratch-this is exactly the kind of software that wouldn't have been possible to build even 2 years ago. This is also the ideal type of "builder" because developers like me have ideas focused specifically on development and things they want to create. But then
all these industry experts come along and they know their niches exactly: "Oh, this is an unsolved problem in my niche." And now they can really delve into these niches without convincing anyone else to join them. I think you guys were talking about this at YC, about changing the profile of who you take into the cohort. I think if you look at the period 2022-2025, there's a real shift in thinking: artificial intelligence is coming, and suddenly software engineering becomes the foundation, so a technical co-founder is needed under any circumstances This was a mega idea that really came to the forefront at YC during that period. That was always true to some extent, but we redoubled our efforts and last year
finally said, "Yes, it's the creators." We're starting to see people who are able to.I mean, it's much harder to understand what's worth creating. You know, the ability to create is something that is now available to everyone. And that's actually really cool. Can you imagine all the things that would never have been created because of what you said? Like, "Oh, we know people will buy this." "We know there's a problem here." But at first these people couldn't convince the engineer to work on it Paul, do you have any examples of apps that people have created on Supabase?
Maybe just for yourself that would never have been created before? Well, there was one pretty cool example at our conference. We had a conference here, and after it, I was approached by a guy from Brazil who had created an entire taxi app using his phone. It's kind of like a little mini-Uber for its local market. And I just thought: he's a taxi driver himself. I don't actually know why he created it, but the very fact that he was able to do it-he came away very grateful that he had succeeded.
And also, with that energy-he was in his 50s, but he had the energy of a teenager who suddenly started building something, which I think is really cool, because we're coming to a point now where there's a lot of uncertainty about what the future of work will look like, but there's a sense of excitement about the future in this category of creators And that's exactly what I love about Supabase. It's like a place where people can come, and those who are insecure now discover these skills and opportunities, even though before they were just "blue collar", people of that profile.
Okay, you've been creating your own software lately. Can you tell me what you were thinking there? Development. Yes, it feels like the end of an era, but it all stems from the fact that I just became really addicted to open core. In fact, probably six months ago, I'm even ashamed that I said that there would be no interfaces and everything would be just chat through my open core. But it turned out that it wasn't, and I was determined not to use the database for a long time. I wanted everything to be in markdown format only. But it turns out that there comes a point when the database becomes useful and an interface is still needed. So that's what I've been doing for the last few weeks, and it's a sort of "
control tower" where every area of my life has an interface to sort through emails so I don't have to read my inbox. It tracks both weight and workouts, all in one place, and the magic is-it's even a little impressive-that the financial section of my app is at least as functional as Mint or Monarch, and in some ways even better, because it allows for personalization. For example, he can figure out what kind of transaction it is by checking the name in my " digital brain" to find out who it is . Oh, I know who that is, and he classifies it correctly. And before, entire companies and startups were just about personal finance, and I can just do it for myself without worrying about whether it will work for others or whose opinion to take into account.
It's just my thing, and it's incredible. We see this a lot, especially in finance and health-two areas where you want to be in control of your data. Many people do the same, and syncing devices to one database is real magic, because then you can query to find correlations between all of it. It's the correlations that are really important, like again, if we take the health example: yes, all this data is in my database, but she also has access to my calendar, so she knows something. For example: "Oh, I know your weight
has increased recently, but you've been traveling, so it's normal." "You can just go back to normal next week," and that context is really valuable. I also noticed that when I started using personal agents, I became a little paranoid about centralizing all my routines and CRM in one agent. So now I'm gradually isolating it to be able to connect different agents from above and know that I can use any of them. So, CRM is another critically important element. Yes, that's why you are so valuable, because in fact, the database as a repository of records is the most valuable thing.
I want to have my own database and build all my applications or agents on it, instead of keeping it all in someone else's database. Mhm. Which is an absolutely crazy idea. If you think about the history of databases, there used to be only a relatively small number of very large databases in the world, run by large companies. I remember when Supabase first came out, you had the idea that creating your own database should be very easy for anyone. And at the time, it wasn't entirely clear why so many people would want to do this, because if you can't
write code, what are you going to do with a database? And not many people can actually write code and create such a personal CRM. For most people before the AI era, this was too difficult. Another example of where Supabase is very useful for me: another section I have is just uploading files. It sounds very simple, but any file that I can send by email or just drop into this interface, my agent analyzes it, understands what it is, how it relates to my life, and what to do with it. But all of this is stored in Supabase. So, all in all, Supabase will eventually contain all the data about my life in one place. And I would never, I would never have thought that
I needed a personal database a year ago, because it wouldn't have made any sense. But now I think that's actually the most valuable thing. Yes, you have something like Supabase Files compatible with S3, and all my stuff is there Oh, really? Class. Yes. This is typical of G-brain. Perfectly. Thank you. What do you think, Paul, is this a future where almost everyone in the world, not just developers, but every person, will have a Supabase database with information about their lives: health, finances, relationships?
Yes, we would like that. I mean, I definitely think that's what's going to happen, everyone in the world who has access to AI will become a developer of some sort. That is, you can build anything, you can customize it. You want to make changes to some application, some interface, and you don't need to depend on anyone. Of course, we consider ourselves an index company. When we came to YC, we focused only on YC companies. We wanted to engage all of YC's clients. And you know, it was because we knew we had to be there from day one, when the business was just starting out. The mission has not changed, it has just grown significantly in scale.
Now that more developers are coming in, we know we have to service them, which is a whole different challenge, but quite exciting. Significantly, i.e. 10 million times? So, what's up, we're currently running a million databases every week, but, you know, if you do some simple calculations, say, with ChatGPT, I think they were talking about 1.2 billion active users per week. And let's say they all want to run something every month-that's 1.2 billion databases per month. So, this is the scale we're moving towards, and we need architectures so that we can enable this scale,
which has never been seen before in the database space Is this even possible with Postgres, or would you have to build your own database engine to scale to 1 billion new databases per week? I think so. Well, if we could negotiate better with AWS, maybe we could, but it turns out that everyone needs computing power these days. And actually, yeah, I'm not sure you need a Ferrari like that for many of these workloads. And we recently made an acquisition- Turso. They have an architecture compatible with Postgres And in fact, it is also compatible with SQLite. I think SQLite is a phenomenal database. So we're going to provide this tier, which we call Supabase Spark, which is
essentially designed for entry-level workloads. The idea will be the same. You start with the same capabilities. You can scale to petabytes. So our slogan is kind of from prototype to petabytes. And we as a company have to make sure we can provide for everyone. And as they scale and their business grows, we make sure they are comfortable. Yes, actually, I was wondering what you thought about that. Like in a classic software company: you start, perhaps, with early-stage startups, like at YC, and then look towards big business. And it seems to me, especially if you're a database development company, before AI came along, you wanted to become Oracle, so you need to get to the corporate level faster, because that's where
all the money is. So you start building enterprise features. You're leaning towards SQLite, which seems to be going in the opposite direction. How do you, how do you look at this? Are you looking in both directions at the same time? Yes. Yes, we have to do both, which is incredibly difficult. Essentially, we have two products that cater to both ends of the spectrum. So, Multigress scales to petabytes, and Turso scales down to prototyping and SQLite-type workloads. So trying to do it at that rate of growth, hiring more people, even with AI, becomes a real challenge, but an interesting one.
You recently conducted a survey where the proportion of your engineers writing 80% of their code using agents increased from 10% to 60% in just 6 months. How did it happen? What is happening? Where is this all going next? We have no internal policy on AI. We simply allow people to do whatever they want and provide access to the tools they want to use. And I think now they've just realized that models can do a lot better and a lot more work. So the pace of implementation is just crazy, and the things they're building internally-it's not just some basic code.
They are quite serious. And as we move into this realm of AI coding, the amount of testing we do and the tools we implement for testing have become quite useful to ensure that the end result is truly high-quality. Yes, we see this in all the YC startups, like Blacksmith Depot or Ubi Cloud, they are all actively growing because they are all implementing CI. Yes. And the number of tests you have is just off the charts. For verification. So, to be honest, it's pretty weird to watch. Was it because the models got good enough, or did people just spend enough time on it and realize, "Oh, this is actually pretty good"?
People need to be convinced, especially engineers. I mean, at the beginning of the year, they might not have thought it was very good. The models have gotten better, but they're also starting to see, "Oh, you can actually achieve great results with these models." And everything related to the Navier- Stokes equations convinces the market that we can really open up new horizons here. So I think we are moving towards this kind of world, and now people are convinced that this is how it will be. You've seen Superbase for three eras First as a company that created a dashboard in 100 days during YC. Then as an API company, and now it's,
you know, this "agent" moment, the moment of creating what agents want. Were there one or two things in each era that struck you as, "Oh, that's what made us in that moment"? I think these changes have happened. First-actually, yes, you say, why was there a need to create a database when we came to YC? At the time, this seemed like a very controversial idea. Yes. I think we saw how difficult it was to use the database even for developers. So that first dashboard was an idea: "Oh, let's make an Airtable-like interface on top of Postgres." Because I actually liked Airtable too. I thought, "Wouldn't it be
cool if there was just a Postgres database on the backend?" So, um, it was just a realization that even software developers were having difficulties. And then when we moved on to AI, I think we talked about that in another podcast. The move to an AI API happened because someone integrated with us and said, "Oh, we want to run a lot of databases. We need an API to do all this." And that was sometime in 2021, maybe. And it turned out that this was absolutely the right move for 2024, when companies like Bolt, Lovable and everyone else started building on our foundation. Then this year I just saw that no one was actually going to the dashboard.
Like, no one, no one visits dashboards anymore. So, um, how are agents going to create something? In this case, I simply sent the team a product memo stating that everything should be "code first", native to Git. Supabase should simply switch to a " code first" approach. So if something is on the dashboard, it should run synchronously in the code, essentially like infrastructure as code. And we reworked a lot of the CLI and everything else to work in sandboxes in the code. We're probably going too far back in time, but were you inspired by Parse, another YC company? Yes. Parse and Firebase, I liked both of these companies. And these waves are funny, right? Because they were doing the backend, and Firebase
was acquired by Google, Parse-Meta. But in some ways I think they paved the way for us to come in and build a real database business, because in 2014 it would be silly not to use RDS for your database Then they came along, [__] came along, [__] started moving to Atlas, and a lot of these database companies showed that you don't have to use just one of the three hyperscalers. You can really have a serious database company. And so this time was crucial for us. Yes, Parse is a bit forgotten now, but it was a very well-made product. They launched just when I was first building iPhone apps, and it was quite nice to move to a nice RESTful API as I was trying to figure it all out.
These changes always happen because of certain turning points, right? So, at that point, two things happened in the market. Somehow, MongoDB convinced everyone that NoSQL must be an incredible way to store data. And, um, the second thing is mobile technology. So, you know, we were lucky that we caught a few of those waves as well. And now we are at their very epicenter. And yes, that's exactly what I was asking: how do you view the corporate segment compared to the initial stage. Because I think if you look even further back, Heroku was the first to say, "Hey, just start with the best developer experience and then scale." But
in reality, it can be quite difficult to scale with customers. And I think Heroku, you know, hasn't been able to bridge that gap-how to retain customers as their applications get bigger, need higher performance, and so on. But historically, every company has had to figure this out. And, they say, you guys are looking that way, but maybe you do n't have to. Honestly, if the service market, say from zero to ten, continues to grow at this rate, it will become huge. Yeah, well, we won everything. Yes, yes. So maybe we won't have to, but we will definitely do it. And I give credit to Heroku. I think they popularized Postgres. But at that time Postgres was quite, well, it was still in its early stages of development and
had some limitations in scaling. And so, yes, we had to supplement Postgres with tools that would allow it to scale infinitely, but perhaps a better analogy for you is how AWS was able to get people on board early and scale. So, are there any lessons, perhaps? How do you think about enabling infinite scalability? The lesson that I think.I've heard statistics and they've said, oh, I could be wrong, so check, but something like 40% of AWS's revenue comes from startups that started with them and then grew. And it is this category that we strive for. You know, we understand that convincing people to switch from one database provider to another is almost impossible. So we want to be there from day one, provide them with a great experience, and
make sure they don't want to leave. business model like Stripe. This is, in fact, the best business model on Earth, if it can be implemented. Just engage them from day one, then scale with the world's fastest-growing companies indefinitely. You do this for a generation, and you become a business that defines an entire generation. That's all. Yes, it's hard for us, because what does this "first day" look like? This is changing quickly, it used to be that day one for me was always YC clients. And now the first day becomes something like, "Okay, everyone is a developer." What will they use? What are the modalities? How will they choose their
databases? These are difficult questions. YC is accepting applications for the next round. Do you have an idea for a startup? Apply at ycombinator.com/apply. It's never too early, and filling out the application will help improve your idea. Okay, back to the video. This is a slightly different customer segment. Initially, when you were just starting out, there was no individual market for databases. The idea that a database could be a B2C business would sound like a syntax error. Yes. Ahem. But now you have two segments. You have early-stage startups with a strong business model, like Stripe, but you also sell directly to consumers or perhaps their agents.
Yes, yes, yes. And these use cases probably won't scale like startups, but they can continue to use you for life because you're powering an app that manages their personal finances, or runs their taxi service, or something like that. Yes. And as their lives develop and they accumulate information, it becomes an index of our own growth, you know? So they just store more. People are collecting more data. This "prosumer" market is essentially a good growth vector for us How do you view the world of personal agents in this perspective? If, say, agents writing code want Supabase, that's understandable. Do you think the next stage is that each of us will have personal databases, and does
something need to be done to make it easier for agents to work with them, or is it basically the same thing Yes, I'm a big believer in personal agents now after a week when my personal assistant was on vacation and I learned what they are capable of. And now I'm just obsessed with the idea of creating products for personal agents. It's true, I told our company: we're " code first," we build for people who write code, but really we build it for agents. People pretty soon won't actually interact. So, I'm developing this using dots. I'm constantly on the call with him, chatting and saying, "Oh, can you make these changes?" My heuristic for making sure I'm using my own product correctly is
that I just don't look at the code and never allow myself to check the architecture except when I want to make sure everything is building correctly. But when I make these changes, I just want to talk to him and see what he can change. So, One of us. This is also madness. He does phenomenal things that seem like something out of a science fiction movie from two years ago, but now I have so many moments that it's just amazing. If you showed this to someone 6 months ago, they would just think it was impossible. Yes, I was at your Supabase Select conference a couple of weeks ago, great conference by the way, and I had this crazy idea.
I was sitting there and you were talking about all these cool new features that Supabase was releasing. And I thought, you know, if I were building an app on Supabase, maybe I wouldn't even bother figuring out all these cool features myself. I want to send my agent to Supabase Select so he can hear about all these new features and figure out how to integrate them into my code. Oh, that's just wild. A truly virtual conference. We have to do this. The conference is for agents only. Conference for agents.
They will appear live. On air. They will be able to communicate with each other, exchange tips about, say, Supabase Live. Wow. You can make a bridge. You can sort of " airdrop" them markdown files for everyone, but you have to be present in the room to receive them. We will call this "artifactry." Oh man, I love this. We talked about this before, there are a lot of things you do that really make agents better. For example, error messages, you know what was the key insight? Are there a bunch of other things
you do that are, on the one hand, obvious, and on the other hand, no one is doing them yet? For example, error messages. Yeah, I was at Dbt Labs last night, and I was surprised that it wasn't that obvious, but we've really dug into our error messages so that you can take a use case like, "Oh, I want to build an app," and usually the error messages in the developer tools look like " 500" or something like that, and you just know there's a problem, but now you actually want the agents to fix it themselves. So, in the error messages themselves, you literally tell them how to fix that error or where to read the documentation to fix it. So in many ways it's just a matter of choosing your usage scenario and trying to cyclically
improve your own error messages so that you can accomplish pretty much anything you want the first time. Yes, that makes sense. You essentially know if an agent uses you, they will encounter an error message. Before, a person would have to Google it and do a bunch of things, but now you can just say, "Oh, you just ran out of I-nodes, so you should do this." Yes, because there are two stages of working with agents. The first is model selection, and the second is that if they get stuck, you don't want them to switch, so it's guaranteed that they'll get stuck at some point.
You just want to give them the tools to fix it, so it's really not that difficult. They're smart enough now to figure out a lot of things, but you have to rework a lot of what used to be just for people and developers, now for agents. Are you testing your project, your product for agents? Do you allow agents to try out Supabase and report any areas where they have difficulty Yes, yes, yes. We have all the different models on the Evals site where we see which models work best, and we also have our own evaluation suite within the company. We're also evaluating which ones work best with Postgres specifically, so that's interesting to the industry, and developing skills around that so they can adopt them and
actually develop on Postgres. So, yes, that's a lot of testing. And in fact, a significant portion of our engineering efforts are now focused on testing specific usage scenarios, rather than development. We want to think about how people build and create solution sets around that. Gary, when you created Gbrain, you built it on Supabase. Can you tell us why you decided to build this on Supabase? So, how was it for you to be a user? Yes, I think Gbrain was a kind of concentrate of what I wrote before. I first worked on Gary's list, which was a kind of news agency, and I had to create a research system for RAG, politics, and documents so that it would read every article on a given
topic and then try to summarize it Then I took that and turned it into an open-source data mining tool for OpenClaw. Because the idea was that before it worked on Rails, like a " Foxconn factory" for agents. I treated every LLM challenge as something very expensive and incredibly dangerous. And when I saw OpenClaw, it was, you know, like Esselen. This was a completely different approach to working with AI, because here the AI is already intelligent. It's not trying to harm you, so you can allow it to operate by simply providing data and opportunities. And I realized that a million tokens is
actually an incredible amount of working memory. Most people can only hold seven plus or minus two objects in their heads, while a million tokens is essentially three Harry Potter books. But even that is not enough for agents. After all, keeping the correct three Harry Potter books in context at any given time is a real challenge. So it seemed like something in between was needed for the corporate brain or my personal affairs. I have half a million markdown files with all the communications I've ever had. So this system really has context about me and everything that's important to me. But at any given time, an agent may only need a page or two. This is a data retrieval problem. So, when the volume reaches 30-40 gigabytes
, you need PG vector, you need Postgres, because it's very easy to create graph databases in SQL. That's what Gbrain is. This is RAG search plus a graph database that creates structure from unstructured data. So it's like dynamic schemes, a bit like what I remember about Palantir back in the day. Yes. And the whole idea is that agents are much more powerful when there's that middle ground where the agent can just say, "This is what I'm looking for." And he will go through the graph. It will do all this vector search and come back saying, "Here's the report, load this into the context."
That's what G-brain is, and with Supabase everything was very simple. It's like: "I need a hosted Postgres that can quickly support a 50, 100, or 300 GB database body And it works great. Auto-scaling works very, very well. And now the most interesting thing: with Browser Use-I'm currently using Side Browser to work in the browser-everything looks like: "Oh, yes, Open Interpreter can go into Supabase and use the database or new APIs that you created." And he just handled it himself. He can self-manage. Have you ever had to tell him how to deal with data structures? For example, graphs or RAG or something like that? Or, you know, it's funny, I remember going into Cloud Code and just saying, " Use Exa, download and organize every article you can
find in AI research." Today I could use Alpha Signal or something similar. But it sounds like this: "Find every academic paper on RAG, graph databases, and text search, and then summarize it for my case, which is how to help an agent access this." "And after he did it, he's like, 'Oh, okay. Well, here's how we're going to do it.'" Yeah, I was at a dinner the other night, they were talking about the future of databases, and one of the ideas was that databases are essentially a mechanism for retrieving data, and you can create indexes so that they look for information in certain formats. For example, graph or RAG. And one of them, which was extremely interesting, was to put the agent in a loop to create the perfect data structure for
searching. For example, if you search this dataset so many times and it takes 10 seconds, why don't you just run the agent in a loop to create a new index type or find the best index that will return the result in less than a second. Dynamic search will obviously come into play once you have really, really smart code generation. Yes. So, I mean, I'm using this for Open Claw right now. So I use my working instance and then extract traces from it as a dataset for evaluation. I have a separate repository called G Brain Evals where there are 40 different categories of specific search types, search efficiency, e.g. cost efficiency, and latency. And the cool thing about assessments is that you can just tell the agent to "
roll," you know, just auto-research and roll, and anything that improves your performance in that assessment, send to master by default. And anything you tried that didn't work, write it down in a markdown file that explains why it didn't work, and save it in G Brain Evals. I use Cappy. Cappy has a concept of captains, kind of like Grok bots, so you can just give them context So I have one who is constantly working and saying, "Come up with new categories," and I have another captain who is constantly working and saying, "Go through all the categories in the ratings, do some self-study, and try to find a way to improve our results on our own internal ratings every day."
Mhm. And it works all the time. This is a very primitive version of RSI for a specific use case, but I think if you go up one level of abstraction, you can do it not only for my case, for example, for Open Claw. This can be universal for any search use case. The only thing that changes is the use case, tracing, and data set You, of course, know about the ratings and can improve your software because you create such a structure around it. Do you think developers in the future will actually need to know about such things, or. Maybe not. Honestly, I feel like we're still at such an early stage that I'm just experimenting, and I like doing it in open source. And someone else, you know, I hope someone
will look at this and say, "Oh, I can apply this." "You know, we're, I think, literally just figuring out the basics of how to use these things right now." Yeah, I remember reading about Steve Yegge's factories and stuff like that earlier in the year and not being able to fully understand them, but now I feel like I've at least put together something that works for me. Yes. When we had Boris Cherny, his vision of the future of programming was that you just talk to Claude like a friend, and you don't have to know about grades and all that stuff, and Claude just understands how to build what's in your head.
I have the domain name openusd.dev because there is actually a file format called OpenUSD, and I collect domains. And suddenly Stripe, Visa, and everyone else announced OpenUSD, and I thought, "Oh, I better use this domain," but I never had time for that. So I talked to him and he designed this site for developers with an ecosystem and stuff. I was chatting with him on my computer, and then, at the end of the day, I opened him on my phone, just before I went to bed, which sounds suspicious, but I promise I was just. Just checking. Just programmed with it and said I don't like the information architecture of how the ecosystem is connected to the use cases.
Can you give me some suggestions? He gave it, and I said, "Okay, yes, implement them." And 20 seconds later he replied, "Oh, yeah, okay, I did." Do you want to refresh the page? I updated the site and everything was very well written and everything was connected to each other. And he set up all this SEO stuff. So I didn't do all the classic things that I would have to do traditionally. I was just chatting with him, and it really was like one of those moments where I saw a glimpse of the future. Well, you can do it because you know what you want to build. That's the thing, yeah. So, obviously, I have an engineering background.
So I kind of know how to make requests, but I try not to say anything. I try not to push it to, say, GitHub or something like that, and I try to code like a normal person so that I know I can use Superbase in my daily work and understand, "Oh, will anyone be comfortable using Superbase in a year?" Yes, it's funny to hear from Boris: "Oh, I just wanted it to be done automatically." And of course, once it hits the distribution, the model literally already has it in its scales. She can do it. But until then, it needs some kind of markup format. You need very few, not even many prompts, just a tiny amount of clues. She just might do it.
I mean, we're entering a very strange moment in society where it seems like RSI is really here, and it's a transition from 20% to 80% where AI research is happening within these cycles, say, at Claude Coder, Codex, or wherever. And at the same time, there really aren't enough people in society like you, Paul, who know what to create and how to ask for it. So now it's like an unstoppable force meeting an unyielding object. The capabilities of models are growing parabolically, while the number of people who know how to really influence society with their help remains more or less constant.
Yes, and I want to be inspired by this somehow. I think this is another point. I think a lot of people are becoming paranoid. But I am genuinely excited about what the future could be for many people. A lot of my previous startups were focused on the working class, on people I was helping with technology, on people who just had to work hard their whole lives, you know? And the thing I really like about Superbase is that I see a lot of entrepreneurship through this platform. So I see a future where there will actually be a lot more entrepreneurship, and it's a pretty fulfilling way of life for a lot of people. So I'm pretty excited about 2027, if we can keep this pace up and
avoid a few crazy events, then it should be an exciting journey for a lot of people. We are seeing a point where founders of vertical SaaS companies are having some difficulty raising Series A investments, even when they reach the scale of $5-10 million in annual revenue, which is historically a significant amount. This was a guaranteed round of the A series some 9 or 12 months ago. And today everything is somehow.I don't know. People aren't really interested in it; The light is "green" for horizontal solutions and AI investments, but vertical SaaS developers are really suffering. But this is exactly when you can reach $10-15 million, and often $25, 30, or 50 million in
revenue, with only 10-15 people on the team And at this point you become very profitable. Yes, yes, yes. With 15 people, 2 million in annual revenue each, and 50 % margin, you're all making millions a year. So, this is a great result for many people. Yes. And at the same time, we do a lot of consulting with people who have reached their goal but are frustrated that they can't raise an A round. And I often tell them, " You'll probably look back on it as a blessing, because you don't need that money Previously, you had to raise a hundred million dollars to reach $30 million in revenue per year, because you had to hire a bunch of people, but now that's not necessary.
Yes. Yes, in startups there is a kind of cult of "honor" for raising capital. I was like that myself: getting funding at the start seemed like a great achievement to me. But in fact, in my opinion, not raising funds now is a truly great achievement. So I'm a little envious of companies that reach this stage. Yes, I don't even know. The world is changing very quickly, but your company, Supabase, has been able to successfully navigate through all these waves. Do you have any advice for those trying to emulate your success? One thing that helps me sleep well is the Lindy Effect.
Databases have been around for 50 years. I think they will be around for another 50 years, and that's something that even after the AI era, despite everything, I'm sure databases will remain. So interpret it however you want. You have to choose categories that are very long-lasting, and if you're going to bet your whole life on it, which is actually what I'm doing, you choose a category that you think is worth investing in. I think the other thing is-everything changes so quickly, so we at Supabase don't try to have all the answers, we just try to be the ones who adapt the fastest. And, you know, I've evaluated or watched a lot of my favorite developer tools, they start with a
developer focus, and then they go higher level, become very corporate, often stagnate and lose that love And from our perspective, at least from my perspective, companies like Stripe have a true founder who cares about focusing almost entirely on new ways of building products. So if you're building something for the next wave, you always need to keep one eye on the future, on what's next, and that's a very short timeframe right now. Everything is moving so fast, so it's important to be extremely adaptable and ensure your team has the capacity for rapid change. This is what we are focusing on over the
next year. I think you may have learned some specific lessons, because you had the initial inflection point of "vibe coding", then the inflection point of Opus 48 and just code generation. When the next wave, hopefully the next inflection point, hits you, are there things you will do differently to be better prepared for it? Well, first of all, using your own products is one of the most important things, at least from our perspective. So I'm constantly testing these tools alongside ours to understand where the gaps are. There is no better feedback than when you get stuck on your own toolkit. And also-the availability of resources. So we try to collaborate with key players in this space, and this ecosystem play
helps a lot because they give us feedback on what they're building. So, we try to leave some free resources in the team, which is also very difficult, but so that when ideas arise, we can try to implement them. And not many of those bets actually win, even when it seems like we're coming together for some cool new cause. Actually, we don't know. They might sound cool, we try them, and they, well, somehow fail. But the ones that work ultimately mean that we will ride this incredible wave together. A great note to end on. Pole, thank you very much, friend. See you next time.
