Paul Copplestone on Databases for AI Builders and Agents

The Lightcone hosts welcome Paul Copplestone, cofounder and CEO of Supabase, to discuss databases in a world where more people and AI agents build software. Copplestone is optimistic that access to AI could enable more people to create and customize applications, while acknowledging uncertainty about future work.

Copplestone reports about 13 million signups, up from an estimated three million a year earlier, and says the company expects revenue to grow fourfold that year. The speakers also cite roughly a million databases created weekly and nearly 50 million under management. These are company figures and forecasts from the conversation.

He attributes the growth to both engineers building more and people without engineering backgrounds becoming builders. The hosts distinguish knowing how to implement software from knowing which problem is worth solving; domain experts may now be able to experiment with ideas without first recruiting an engineer.

Copplestone describes three chapters for Supabase: dashboard-first, API-first and now code-first. He says agents often prefer code and command-line interfaces, and that being a default choice in model-generated workflows has benefited the company.

Asked about open source, he says it is hard to know the counterfactual but considers it important. Supabase contributes to and supports tools in the PostgreSQL ecosystem. He suggests that access to source code can help agents investigate failures, while the hosts discuss its value for vendor security review.

Copplestone says new signups, activation and conversion have risen together in the period he describes. He sees strong growth among builders who did not previously write software, while noting that traditional developers remain a large part of the user base.

A host gives the example of a fintech founder building personal finance tools after previously relying on engineers. Copplestone says domain experts can identify niche problems that a developer might never encounter. He also recounts meeting a Brazilian taxi driver who built a local taxi application on his phone.

A host describes building a personal “control tower” after initially expecting to interact only through chat and store everything in Markdown. The application combines interfaces for email, finances, health and other parts of life. He values being able to customize it for himself rather than a general market.

The hosts discuss combining context across services, such as a calendar alongside health data, while noting that the examples are personal interpretations rather than medical conclusions. Copplestone says he has begun extracting personal data from one agent so he can connect other agents to the same underlying record.

They describe a personal database as a store of record that can support different applications or agents. One host says his system also accepts files and stores them through Supabase. The appeal, in their account, is the ability to keep the data while changing the interface or agent.

Asked whether everyone may eventually have a personal database, Copplestone says he expects many people with AI access to become builders. He explains that Supabase initially focused on serving YC startups from day one; the same ambition now extends to a much larger and more varied audience.

He illustrates the possible scale using a hypothetical comparison with the large number of AI users. The arithmetic is a planning scenario, not evidence that every user will create a database. It motivates questions about architecture and cost at a scale traditional database products did not have to assume.

Copplestone says small prototypes do not necessarily need the same resources as the largest workloads. He discusses Supabase’s acquisition of Turso and a proposed Spark tier for getting started, alongside the need to support customers that grow. The goal he describes is a path from prototype to very large data volumes.

The group asks how a database company can serve individual builders and enterprise customers at once. Copplestone says the company is trying to address both ends with different architectures. Hiring and supporting this range during rapid growth has been difficult, even with AI assistance.

A host cites an internal poll showing a rise in the share of Supabase engineers who write most of their code with agents. Copplestone says the company gives people access to tools rather than prescribing a single AI policy, and that engineers have adopted them as they see better results.

He emphasizes testing as the team writes more code with AI. The hosts observe increased demand for continuous-integration and review tools. Their discussion is about the engineering work needed to evaluate outcomes, not an assertion that generated code is automatically correct.

Looking back at the dashboard era, Copplestone says even developers found databases difficult to use, inspiring a spreadsheet-like interface over PostgreSQL. An integration partner later needed an API to launch many databases; he says that decision prepared the company for later application builders.

As more work moved away from the dashboard, Copplestone says he asked the team to make the product code-first and Git-native. Capabilities available in the dashboard should also work through code, and the company reworked command-line tools for sandboxed environments.

The group compares earlier backend products such as Parse and Firebase, and reflects on how mobile and changes in database preferences created opportunities. Copplestone says those companies helped establish that a database business could exist outside the major cloud providers.

They discuss the challenge of winning customers early and scaling with them. Copplestone says migration between database providers is difficult, so Supabase wants to serve businesses from their first day and keep them as they grow. He also cautions that a statistic he heard about AWS startup revenue should be fact-checked.

A host suggests that personal database users may not grow like startups but could remain customers for years. Copplestone sees stored data increasing with a person’s life and describes this as a potential consumer and prosumer market, rather than a proven outcome for every user.

Copplestone says using a personal agent while his assistant was away made him more interested in that market. He describes dogfooding: speaking to an agent while building, rather than constantly inspecting code, to experience the workflow a future customer might use.

A host imagines sending an agent to a developer conference to learn about new features and integrate them into a project. The group jokes about an agent-only conference, then returns to concrete product choices that make tools easier for agents to use.

Copplestone says a generic error message may tell a human that something failed but leave an agent without a recovery path. His team has improved messages to suggest remedies or point to documentation. The aim is to help an agent resolve a problem rather than immediately abandon the product.

He says Supabase tests workflows with different models, maintains internal evaluation suites and studies PostgreSQL use cases. More engineering effort is going into testing how people and agents build, rather than only adding features. The company’s tests are its own measures, not independent certification.

A host describes Gbrain, a retrieval system built from earlier research workflows. The problem is selecting relevant context from a large personal or company corpus: an agent may have a long context window, but still needs the right material at the right time.

He describes combining retrieval, vector search and graph-like structure over hosted PostgreSQL, with Supabase managing the underlying database. He says he asked coding tools to research retrieval approaches before implementation, then discusses the possibility of agents improving indexes for repeated queries.

The host says he extracts evaluation datasets from production traces and tests categories such as retrieval quality, cost and latency. He describes automated loops that try changes, retain improvements and record failed attempts. These are his own experimental workflow and metrics, not a universal development recommendation.

The group asks whether future builders will need to understand evaluations or whether an agent will handle more of the process. Copplestone recounts building a developer site through conversation with an agent, while recognizing that his engineering background helps him know what he wants.

The hosts contrast fast-changing model capabilities with the slower task of deciding what to build and how to have an impact. Copplestone says he is excited about entrepreneurship becoming accessible to people who previously lacked technical resources, though the future is uncertain.

The conversation turns to vertical software startups and fundraising. The hosts suggest that smaller teams with meaningful recurring revenue may not always need to raise the next round simply for validation. Their revenue and margin examples are scenarios, not promises of typical startup outcomes.

Asked how founders can adapt through repeated waves, Copplestone points to durable categories, using one’s own product, partnerships and reserving team capacity. Many experiments fail, he says, but rapid feedback can reveal the few that work. The group closes on the need to remain adaptable.