Why Everyone Is About To Have Their Own Database
In a Nutshell
Supabase is experiencing explosive growth—50M databases, 1M launched weekly—with 70% of new business coming from AI agents rather than human developers. The core thesis is that everyone will soon own their own personal database as AI makes software creation accessible to non-engineers, with Supabase positioned as the infrastructure layer for this shift. The company is adapting its entire product to be agent-first, optimizing error messages, CLI tools, and documentation so AI agents can independently build and troubleshoot on the platform.
These notes were generated by AI and may contain inaccuracies.
Paul Copleston expresses excitement about the future where everyone with access to artificial intelligence becomes a builder who can create and customize applications without being dependent on others. He believes this shift will fundamentally change how people interact with technology and create solutions.
Supabase is an open-source Postgres platform that has become the default database within tools such as Cursor and Cursor. The company now has 13 million users and launches more than one million databases per week. Revenues are projected to grow fourfold this year.
Approximately 70% of new business comes from agents rather than human developers. This represents a significant shift from the previous year when the company had around three million users compared to the current 13 million subscriptions.
The total databases under management have grown from 8 million last year to nearly 50 million currently. The company now creates more than one million databases weekly, compared to much smaller numbers twelve months ago.
Two primary factors drive this growth: software engineers building with complete freedom, and a massive influx of non-engineer builders who previously couldn't access these tools. This represents a fundamental democratization of software creation beyond those with traditional engineering backgrounds.
Supabase has progressed through three distinct phases: starting as a control panel company, evolving into an API company, and now becoming a code-based company focused on providing patterns that agents prefer to work with, particularly command-line interfaces.
Open source has been crucial to Supabase's success because agents prefer open-source solutions where they can examine source code when issues arise. The company supports existing tools in the Postgres ecosystem rather than only promoting Supabase-specific tools, which has helped spread adoption across multiple communities.
Open source provides security advantages because organizations can inspect code to verify security measures. Closed-source solutions face adoption barriers when security is a primary concern for organizations.
In 2026, the primary growth is coming from a new category of "builders" who may not have software engineering backgrounds but have ideas they want to implement. These individuals previously couldn't convince engineers to build their concepts, but AI tools now enable them to create solutions independently.
Unlike typical growth patterns where increased sign-ups lead to decreased activation and conversion rates, Supabase is experiencing growth across all metrics simultaneously. This indicates that AI models have become sufficiently capable at building, enabling non-engineers to successfully create functional applications.
Early investors predicted that product-led growth would reach revenue limits, requiring a shift to enterprise sales. However, this ceiling hasn't materialized, and the builder category continues expanding without apparent limits.
A fintech founder who exited his company for over a billion dollars exemplifies the ideal builder profile. Despite having only basic Ruby scripting knowledge, he now builds sophisticated personal finance applications including balance sheets, spending trackers, and bank integrations that would have been impossible to create two years ago without engineering resources.
Between 2022 and 2025, YC shifted from requiring technical co-founders to recognizing that builders themselves are foundational. The ability to build is now accessible to anyone, while the hardest challenge remains determining what to build.
A Brazilian taxi driver in his 50s built a complete mini-Uber application for his local market using only his phone, demonstrating how the builder movement reaches demographics far beyond traditional software engineers.
Paul has been building a personal "control tower" application that manages multiple life domains including email organization, financial tracking, health metrics like weight and workouts, and spending analysis. The application integrates with a personal "digital mind" that can identify transaction details and make sophisticated categorizations.
Finance and health represent the two primary areas where people want ownership of their own data. Supabase enables device synchronization across a single database, allowing agents to build connections across all personal data sources, such as linking health metrics with calendar information to provide contextual insights.
Paul is extracting his routines and CRM data to be agent-independent, ensuring he can connect different agents to his database rather than having all data locked within a single agent's system.
Previously, databases were massive systems run by large companies with limited individual access. Supabase's original vision of making databases accessible to everyone seemed unnecessary when most people couldn't write code to utilize them effectively.
Paul maintains a dedicated file upload section where any file added through email or interface gets processed by agents that determine relevance and appropriate actions, with all data stored in Supabase as the central repository for life-related information.
The vision extends to everyone having a Supabase database containing their life details including health, finances, and relationships. This represents a fundamental shift from a year ago when personal databases seemed unnecessary.
With ChatGPT having 1.2 billion weekly active users, if each wanted to launch something monthly, this would require 1.2 billion databases per month. Current infrastructure must scale to accommodate this unprecedented demand.
Supabase acquired Turso, which provides Postgres-compatible infrastructure that also supports SQLite workloads. The company is introducing "Supabase Spark" for initial workloads while maintaining the ability to scale to petabytes of data, following the principle of moving from prototype to petabyte.
Supabase must simultaneously serve both early-stage users with SQLite-compatible solutions and enterprise users requiring petabyte-scale Postgres capabilities. This dual-product approach is necessary given current growth rates and hiring challenges.
A survey showed that 10% of Supabase engineers were writing 80% of their code using programming agents, with this figure rising to 60% within six months. The company has no internal AI policy, allowing engineers to use any tools they prefer.
Increased testing volume has become essential for ensuring quality as AI-assisted development scales. YC startups like Blacksmith and UbiCloud are moving toward continuous integration with testing volumes exceeding previous expectations.
Supabase has evolved through three distinct phases: the control panel era built in 100 days during YC, the API company phase, and the current agent phase focused on making products that agents want to use.
When Supabase joined YC, a database company seemed counterintuitive. The initial control panel was built as an Airtable-like interface on top of Postgres, recognizing that even software engineers struggled with database complexity.
The shift to an AI API occurred around 2021 when an integration partner requested the ability to launch many databases programmatically. This proved prescient for 2024 when companies like Bolt and Lovable began building on the platform.
With no one visiting control panels anymore, Supabase implemented a "code first" approach where all functionality must work through code, with infrastructure treated as code. The CLI and other tools were redesigned to work in isolated code environments.
Parse and Firebase provided software backends before being acquired by Meta and Google respectively. These companies proved that legitimate database businesses could exist outside the three major cloud providers, paving the way for Supabase's success.
MongoDB convinced the market that NoSQL was viable for data storage, while mobile phones created new backend requirements. Supabase benefited from similar wave timing with AI creating demand for accessible databases.
AWS generates approximately 40% of revenue from startups that started with them and then scaled. Supabase targets this demographic, focusing on being the initial choice to prevent migration challenges that make switching database providers nearly impossible.
The approach mirrors Stripe's business model, which represents the optimal business structure for database companies where users start early and remain throughout their growth trajectory.
Attract customers from day one, then expand with the world's fastest-growing companies to infinity. Do that for a whole generation, and you will become a company with a lasting legacy. The challenge is defining what "Day One" looks like because it's changing rapidly. Previously, the first day meant Y Combinator customers, but now the first day means everyone is a developer.
Y Combinator has started accepting orders for the next batch. Submit applications via ycombinator.com/apply. It's never too early, and filling out the application will develop your idea.
Initially, there was no market for individuals in the field of databases. The idea of a database company geared directly toward consumers would have seemed like a programming error. Now there are two customer segments: companies in their early stages following the strong Stripe model, and direct sales to consumers or their agents.
Consumer use cases won't expand like startups do, but customers might use the service for the rest of their lives because they run apps managing personal finance software, taxi companies, or similar services. As their lives grow and knowledge accumulates, this represents an indicator of growth. They just store more data. This consumer-producer market is a good growth trend.
Programming agents wanting Superbase is pretty clear. The question is whether anything needs to be done to ensure personal agents can easily access databases, or if it's essentially the same. There is optimism about personal agents after a week of executive assistant being away and learning what they can do. The approach has shifted to building for agents, with the recognition that humans will not interact with each other in the near future.
The method involves using dots - sitting on the phone constantly and talking through changes. The way to ensure building and using tools correctly is to not look at the code and never examine the structure except when verifying it's building things correctly. When making changes, the goal is to talk and see what she can change.
She does incredible things that look like science fiction from two years ago. Many mind-blowing moments are being experienced now that would have seemed impossible 6 months ago.
At the Superbase Select conference two weeks ago, the idea emerged that if building an application on Superbase, there wouldn't be a need to understand all the amazing new features personally. The agent could be sent to Superbase Select to listen to all the great new features and learn how to integrate them into the codebase.
The concept of a conference for agents only was discussed, where they would attend in person directly, talk to each other, and exchange tips about Superbase life. The name "Artifactory" was suggested for this concept.
Error messages are one example of things that make agents better. The error messages have been deeply worked on so that for use cases like wanting to build an application, instead of basic 500 errors where you just know there's a problem, agents can now fix themselves. The error messages literally tell them how to fix the error or go read documentation to fix it.
Much of this depends on choosing the use case and trying to do loops to improve error messages so anything can be done in one go. When being used by an agent, the agent will encounter an error message. Previously, a person would have to go Google it and do many things, but now the system can say things like running out of I-nodes and suggest what to do.
There are two stages to gaining agents. The first is getting picked by the model, and the second is that if they get stuck, the goal is to not let them get away. It's guaranteed they'll get stuck at some point, but the tools need to be provided to fix it. It's not really that complicated - they're smart enough now to know a lot of things, but much of what was previously intended for humans and developers needs to be re-engineered to suit agents.
Products are tested for agents by having agents try using Superbase and then report on every place they encountered problems. All different models on the Evals website are evaluated to see which models build best, with an internal evaluation set. Evaluation is also done for what's best with Postgres only, which is interesting for the industry. Skills are built around it so agents can actually adopt and develop using Postgres. Much testing is done, and much engineering effort now goes toward testing specific use cases rather than building.
Gbrain was built on top of Superbase. The decision to build it using Superbase came from needing a hosted Postgres server that supports 50, 100, or 300 GB databases at super-fast speeds. Automatic sizing works very well. The experience as a user was positive.
Gbrain was a summary of a collection of things written. Initially, Gary's list was worked on, which was more like a smart newsroom. A search system for RAG technology, policies, and papers had to be built so it would read each newspaper article on a particular topic and then try to summarize it. That was incorporated into an open-source recovery system for OpenClaw.
The idea was that at Rails, every call to a large language model was treated as extremely costly and extremely risky. When OpenClaw was seen, it was similar to Esselen - a completely different way of working with artificial intelligence. The realization was that artificial intelligence is intelligent and not trying to harm you, so it should be allowed to do its job, with data and capabilities provided.
A million tokens is actually an amazing working memory. Most humans can hold seven things, plus or minus two, in their heads, while a million symbols is roughly equivalent to three books from the Harry Potter series. But even this is somewhat restrictive for agents - keeping the three correct Harry Potter books at any given time is a real challenge.
There was something mediating between the company mindset and personal matters, with half a million Markdown files for every single communication ever had. This already has context about everything that matters, but at any moment the agent might need two pages or something like that. It's a data retrieval problem.
At sizes up to 30 or 40 GB, PG vector and Postgres are needed, and graph databases can be easily handled in SQL. Gbrain represents a RAG data retrieval system plus a graph database that creates structure from unstructured data. It's similar to dynamic charts, a bit like what Palantir was in the past.
The whole idea is that agents are more powerful when there's something intermediate where the agent can simply say what it's looking for. It will pass the graph, perform all vector searches, and return to say here's the report to load in context.
Superbase was very clear and straightforward - needing a hosted Postgres server with support for 50, 100, or 300 GB databases at super-fast speeds. Automatic sizing works very well.
With the browser using a sidebar, it can say Open Cloak can access Subabase and use the new database or APIs that were created. It is self-governing and can manage itself autonomously. The guidance needed to understand data structures like charts or RAG was minimal.
The irony is going into Cloud Code and simply saying to use Exa and download and index every research paper found in the field of artificial intelligence. Today Alpha Signal can be used, but it's more like going and looking up all the research on RAG, graph databases, and text retrieval, then summarizing it for the use case of how to help an agent access these things. After that, the response was okay, here's how we're going to do it.
At a dinner about the future of databases, one idea was that databases are basically a data retrieval mechanism, and indexes can be set up to search through data in certain formats like graph or RAG. One of the most exciting things was putting an agent in a loop to create the ideal data structure for the search. If searching through a dataset many times takes 10 seconds, why not put an agent in a loop to create a new type of index or find the best index to return it in less than a second?
It's quite clear that dynamic recovery will occur once there is very intelligent software generation. Currently using it in Open Claw, the production version is used from which traces are extracted as if it were an evaluation dataset.
There is a separate repository called G Brain Evals containing 40 different categories for specific types of retrieval, retrieval efficiency, cost efficiency, and response time. The great thing about ratings is that an agent can be told to do a loop or perform an automatic search, and anything that improves stats in that rating gets automatically published in the main version by default. Anything tried that didn't work gets written as a Markdown file explaining why it didn't work and saved in G Brain Evals.
Cappy is used, which has a concept of leaders similar to Grok bots, so context can be given. There is one that is always working on creating new categories, and another leader that is always working on reviewing all assessment categories, automatically searching, and trying to find ways to improve scores in internal assessments every day. This works all the time.
This is a very rudimentary version of RSI for a particular use case, but if raised by one level of abstraction, it could be done not just for the personal case in Open Claw but for any use case for retrieval for anyone in general. The only things that change are the use case, the tracking, and the dataset. Ratings are known about and programs can be improved because they're surrounded by this framework.
Future developers might not have to know about these kinds of things. We're at a very early stage, just tinkering with things, and doing it in open source. The hope is someone else will look at this and say they can apply it. We're literally inventing the basic principles of how to use these tools right now.
Earlier this year, Steve Yee's factories were read about and couldn't quite be grasped, but now something has been put together that at least works. Boris Cherny's vision for the future of programming was closer to just talking to Claude as a friend, without needing to know the ratings and all these details, as Claude simply figured out how to build what was in mind.
The domain name openusd.dev was acquired because there is a file format called OpenUSD and domain names are collected. Suddenly Stripe, Visa, and everyone else announced OpenUSD, so it should be used now, but there wasn't time to use it. Talking to him developed this developer-specific aspect with the ecosystem and everything.
Talking on the computer, then toward the end of the day calling from the phone while going to sleep. Writing code with him and saying the information structure regarding how the ecosystem is linked to use cases wasn't liked, and asking for suggestions. He did so, and after saying okay apply it, after 20 seconds he said he was done and asked if the page should be refreshed. The website was updated and very well written with everything coherent. He also linked things related to search engine optimization.
All the traditional things that would have had to be done in the usual way weren't done - just talking to him felt like one of those moments seeing a glimpse of the future. This can be done because you know what you want to build.
There is a background in engineering, so knowing how to write commands, but trying not to say anything. Not directing it towards GitHub or anything similar, and trying to program like a normal person or a beginner next year, to know how to test Superbase and make sure it will be a good experience with Superbase a year from now.
When Boris says he just wanted to do it automatically, certainly once it reaches the distribution stage, the model literally has that in its weights and can do that. But until then, it needs some Markdown files. Only a little guidance is needed, not a lot, just very small amounts. It can do the job easily.
We're entering a very strange moment in society where it seems artificial general intelligence has already arrived, and we're moving from a 20% to 80% moment where AI research is happening within circles in Cloud Coder, Codex, or somewhere else. At the same time, society doesn't have enough people who know what to build and how to demand it. It seems like an invincible force is meeting an object that is not moving at the moment. The capabilities of models are skyrocketing, while the number of people who know how to make a real impact on society using them remains almost constant.
There is genuine excitement about what the future could hold. Previous startups focused on manual laborers and people provided with technology, people who had to work their whole lives. What is really loved about Superbase is seeing a lot of entrepreneurship thanks to this platform. This future where there will be a lot of entrepreneurship is seen, which is a very satisfying lifestyle for many people. There is excitement for 2027. As long as this pace can be maintained and some crazy events avoided, it should be a pleasant journey for many.
We're witnessing this moment when Vertical SaaS founders struggle to secure a Round A funding round, especially when recurring revenue is lower than usual, 5 to 10 million, a figure that was historically considered large. This figure guaranteed a funding round A until just 9 or 12 months ago. But today the situation looks different. People are no longer enthusiastic about it, while investments in general software and artificial intelligence are given the green light, founders of specialized software face real difficulties.
This is happening at a time when revenues of 10 to 15 million can be reached, sometimes 25, 30 or even 50 million, with a staff of only 10 or 15 people. At this point the company becomes very profitable. With 15 employees, revenues of $2 million per person, and a profit margin of 50%, $1 million is made annually. This is an amazing result for many people.
Many consultations are conducted with people who have achieved the desired success but are frustrated by their inability to raise funds. The advice given is that they will look at this as a blessing because they don't need the money. In the past, $100 million had to be raised to reach $30 million in annual revenue because many people had to be hired, but now that's not needed.
There is a real obsession among startups with the issue of obtaining funding. Going through the same experience, securing funding initially seemed like a great achievement. But in reality, not needing to raise funds is the real great achievement. There is a little jealousy of these companies that have reached that stage.
One of the things that helps sleep peacefully is what is known as the Lindy effect. Databases have been around for 50 years. They will last for another fifty years, and that's one thing - whatever happens at the end of the AI era, databases will absolutely certainly exist. Categories with high longevity should be chosen, and if betting your whole life on it, which is basically what is done, then the category that feels worth investing in should be chosen.
The other point is that things are changing very quickly, so at Superbase they don't try to have all the answers, they just try to ensure they adapt as quickly as possible. Many favorite development tools have been evaluated or observed; they start with a developer-focused approach, then expand and become very institutionalized, and then stagnate and lose that passion.
Companies like Stripe have a founder who is genuinely interested in focusing on new ways of building. If building for the next wave, the eye must always be kept on the future of what is to come, which is a very short timeline right now. Things are moving very fast, but being highly flexible and ensuring there is capacity within the team to adapt quickly is essential. This is what will be focused on next year.
Specific things were learned going through the initial Vape Code turning point, then the Opus 48 turning point, and code generation. When the next wave comes, and hopefully it will be another small turning point, there are things that will be done differently to be better prepared for it.
First and foremost, experiencing products ourselves is one of the most important things. Constantly testing these tools with ours to see where the gaps lie. There are no better comments than to hang yourself in your own tools. Also having the ability to adapt. Trying to partner with the key players in this field, and this environmental approach has been very helpful because they provide feedback on what they're building. Trying to leave some capacity for absorption within the team, which is also very difficult, but so that testing can be done when they have ideas.
Many bets don't pay off, even when it seems like teaming up to do something new and exciting. We really don't know. The ideas may seem great and we try them, but they somehow fail. But those that succeed ultimately mean that we're riding this wonderful wave together.
Keep Y Combinator in your library
Save the videos and channels worth coming back to, and find them again in one place.
