Supabase Overhauls Platform as AI Agents Drive 70% of New Activity
Y Combinator
As AI coding agents commoditize technical execution, domain expertise and owned databases have replaced engineering skill as the scarce bottleneck in software creation.
AI-assisted summary of What Happens When Everyone Can Build Software — original source. Check the original for full context.
Source published:
Key ideas
- Roughly 70% of new activity on Supabase now originates from autonomous AI agents rather than human developers, driving platform scale to 13 million users and over 1 million newly provisioned databases per week. (0:00)
- The classic SaaS product-led growth (PLG) ceiling has effectively disappeared in the AI era, with Supabase observing simultaneous increases in signups, activation, and conversion as coding agents require persistent database backends. (4:47)
- Developer tool interfaces are shifting from human-oriented dashboards toward code-first, CLI, and instructional error payloads designed to let autonomous agents diagnose and one-shot fixes without stalling. (2:30)
- Software creation efficiency is creating an economic paradox where vertical SaaS companies face a Series A venture capital crunch despite being able to scale to $30M–$50M ARR with lean teams of just 10 to 15 people. (43:40)
Detailed notes
## Background Published on October 30, 2026, by Y Combinator on their podcast feed, this episode of The Lightcone features Supabase co-founder and CEO Paul Copplestone joining hosts Garry Tan, Harj Taggar, and Jared Friedman. According to the show description, the conversation explores how Supabase evolved into the default open-source Postgres backend of the AI coding era—surpassing 13 million users with roughly 70% of new activity coming from autonomous agents—and examines what happens when everyday people can build software on demand.
## TL;DR Paul Copplestone discusses Supabase's explosive inflection to provisioning over a million databases each week as autonomous coding agents shift the product from an API- and dashboard-driven tool to a code-first, CLI-native foundation. The conversation traces how democratized software creation empowers non-traditional builders—such as a Brazilian taxi driver programming a local ride-sharing app on his phone—and prompts early adopters like Garry Tan to run bespoke, owned personal operating systems powered by Postgres and knowledge graphs. Addressing infrastructure challenges, Copplestone outlines how Supabase bridges lightweight SQLite engines with enterprise petabyte scale while re-engineering error handling to support self-healing AI workflows. Finally, the group reflects on the emerging economics of software, forecasting lean 10-person teams hitting tens of millions in ARR and highlighting the enduring Lindy effect of databases amid rapid AI capability jumps.
## Atmosphere & style The episode carries an electric, late-night hackathon energy mixed with seasoned startup pragmatism, driven by genuine excitement about how fast developer paradigms are shifting. Rather than speaking from abstract theory, the hosts and Copplestone swap visceral war stories—from Garry hacking custom context pipelines over decades of personal markdown to Paul dogfooding Supabase via voice calls while winding down for bed. The dynamic is candid, collegial, and playfully contrarian, balancing technical depth around database primitives with an infectious optimism for everyday builders unlocking creative agency in an agentic world.
## Bulletin - `00:00` Roughly 70% of new activity on Supabase now originates from autonomous AI agents rather than human developers, driving platform scale to 13 million users and over 1 million newly provisioned databases per week. - `04:47` The classic SaaS product-led growth (PLG) ceiling has effectively disappeared in the AI era, with Supabase observing simultaneous increases in signups, activation, and conversion as coding agents require persistent database backends. - `02:30` Developer tool interfaces are shifting from human-oriented dashboards toward code-first, CLI, and instructional error payloads designed to let autonomous agents diagnose and one-shot fixes without stalling. - `43:40` Software creation efficiency is creating an economic paradox where vertical SaaS companies face a Series A venture capital crunch despite being able to scale to $30M–$50M ARR with lean teams of just 10 to 15 people.
## Key takeaways - `00:00` Y Combinator's core thesis has evolved from 'make something people want' toward 'make something agents want', reflecting a market where autonomous agents are becoming the primary users of developer infrastructure. - `00:00` Supabase's operational metrics show an unprecedented inflection, with managed databases jumping from 8 million to nearly 50 million within a single year and revenue pacing toward a 4x annual increase. - `02:30` Open-source infrastructure holds a structural advantage with AI agents, as LLM-driven agents require full visibility into source code to inspect and resolve execution errors rather than hitting proprietary black boxes. - `04:47` The scarce resource in software development is rapidly pivoting from technical implementation capability to domain-specific knowledge of what to build. - `08:15` Democratized AI development enables bespoke personal software tailored to individual or hyper-local needs—such as regional taxi apps or custom personal operating systems—that historically made no economic sense to fund or build. - `10:00` Owning an independent database layer protects users from proprietary vendor lock-in, enabling personal knowledge graphs and records to serve as permanent backends while frontends and underlying models remain swappable. - `15:45` Servicing mass-scale agentic workloads requires a dual-ended architectural model, combining ultra-lightweight SQLite instances for ephemeral prototyping with multi-instance Postgres clusters scaling up to petabytes. - `17:35` Internal AI adoption at Supabase saw engineers writing 80% or more of production code with AI jump from 10% to 60% in six months, causing automated testing, CI, and verification tooling to become the dominant engineering bottlenecks. - `20:00` Supabase transitioned through three distinct eras—from an Airtable-like visual dashboard at YC, to an API-first provisioning engine, to a code-first, Git-native architecture engineered directly for agent sandboxes. - `30:00` Error payloads in developer tools are being re-engineered to deliver self-healing instructions and direct documentation pointers so that failing agents can resolve bugs autonomously in a single attempt. - `32:30` Large context windows cannot replace structured databases: long-term retrieval systems like GBrain combine pgvector with relational SQL knowledge graphs to dynamically synthesize massive archives into tight context briefings. - `36:00` Autonomous continuous optimization loops can run automated evals against production traces, allowing AI agents to iteratively modify code and ship retrieval improvements directly to production with no human intervention. - `43:40` The venture funding freeze for $5M to $10M ARR vertical SaaS companies can be a founder advantage, as lean teams operating at $2M ARR per employee can achieve high profitability without dilutive equity raises. - `45:00` Rooted in the Lindy effect, foundational primitives like relational databases will outlast fleeting application and AI interaction layers, making adaptability and ruthless self-dogfooding the key to surviving technological shifts.
## Detailed walkthrough ### `00:00` The Agent Inflection and Supabase’s Astronomical Growth
Paul Copplestone reflects on his excitement for what the future holds, anticipating that by 2027 nearly anyone with AI access will become a builder who can create, customize, and modify apps or user interfaces without being beholden to engineering gatekeepers. Welcoming Paul to *The Lightcone*, the hosts highlight how Supabase—the open-source Postgres backend—has turned into the default database layer embedded in tools like Claude Code and Codex. The classic Y Combinator motto given on day one, “make something people want,” has shifted decisively in practice toward “make something agents want.” Supabase exemplifies this reality directly, with approximately 70% of all its new activity originating from autonomous AI agents rather than human hands typing into keyboards.
```mermaid flowchart LR accTitle: Evolution of Supabase Product Modalities accDescr: Three stages showing Supabase evolving from Dashboard to API and then to Code-First CLI tooling favored by AI agents. subgraph Past["Past Eras"] D["Dashboard Company"] --> A["API Company"] end subgraph Present["Agent Era"] A --> C["Code-First & CLIs"] end C --> AG["Autonomous Agents (70% of Activity)"] ```
When asked to unpack the numbers behind this expansion, Paul outlines a massive year-over-year inflection: - **Signups:** Climbed from roughly 3 million signups 12 months prior to 13 million users today. - **Revenue:** On track to grow 4x within the year. - **Weekly database creation:** Spinning up over 1 million databases every single week. - **Databases under management:** Grown from about 8 million a year ago to nearly 50 million databases.
Paul attributes this inflection to two main drivers: traditional software engineers building with complete abandon, and a brand-new wave of non-engineer "builders" coming online who historically lacked the technical training to spin up databases.
`02:30` Adapting for Agents and the Open Source Advantage
Supabase’s ability to capture this agent workload stems from intentional shifts in how the product is designed and delivered. Paul describes the company's trajectory across three distinct chapters: 1. **Chapter 1:** A visual *dashboard* company. 2. **Chapter 2:** An *API* company. 3. **Chapter 3:** A *code-first* company centered around command-line interfaces (CLIs).
Agents overwhelmingly prefer code-first modalities and CLIs to interact with infrastructure. Additionally, Supabase benefited enormously from becoming the default database recommendation baked into leading LLMs right as agentic coding took off.
The conversation turns to the role of open source in agent adoption. Paul notes that while the exact counterfactual is impossible to know, being fully open source was critical. Supabase intentionally supports and maintains broader ecosystem projects like PostgREST, creating trust across multiple communities. The hosts observe that agents strongly prefer open source because they want full visibility: when an agent runs into an error, it can inspect the source code directly rather than hitting an inscrutable closed-source brick wall. Paul agrees, remarking:
> “I noticed the agents really like feeling powerful data and there's nothing more frustrating than hitting a brick wall and then you don't know what's going on and you can't fix it.”
Looking ahead, Paul emphasizes that security requirements will drive enterprises in the same direction: companies will demand the ability to audit source code for security, making proprietary, closed-source competitors far harder to adopt as vendors.
`04:47` The Rise of the "Builder" and Defying Product-Led Growth Ceilings
In classic SaaS product-led growth (PLG), accelerating top-of-funnel signups typically dilutes conversion and activation metrics. However, Paul points out that Supabase is currently experiencing a rare market dynamic where signups, activation, and conversion are all climbing simultaneously because underlying models are becoming exceptionally capable at building complete products. Non-technical users run into the limitations of simple frontend file generation in tools like Claude Code and immediately need real database backends to make their applications functional.
Early venture investors warned Supabase that PLG models inevitably hit revenue ceilings and force companies to pivot into traditional enterprise sales motions. Paul notes that this theoretical ceiling has simply vanished in the AI era:
> “I remember our early investors were saying, ah, PLG, product-led growth, it's going to tap out at this revenue, and you'll have to start moving into this segment of the market, and there just appears to be no ceiling so far.”
The shift also redefines the ideal builder. Non-engineers often possess deep domain expertise that software engineers lack. Software engineers tend to build tools focused strictly on developers, whereas domain specialists have years of pent-up ideas targeting niche, unsolved business workflows. The hosts note a parallel evolution in YC's admissions thinking: from 2022 through 2025, conventional wisdom dictated that an elite technical co-founder was an absolute requirement; over the past year, the far scarcer resource has become knowing *what* to build, because technical implementation can now be summoned on demand.
- **The Fintech Founder Example:** One host describes a founder who sold his fintech company for over a billion dollars. Despite an undergraduate math background, he previously needed engineers to construct production software. Now, working on personal projects, he writes complex balance sheet trackers and bank integrations entirely on his own through AI agents, executing work that would have required an engineering team two years prior.
`08:15` Personal Software and the Brazilian Taxi Driver
Democratized access to software generation unlocks tools that never made economic sense to build when developers had to be hired. The hosts ask Paul for real-world examples of people building bespoke software on Supabase that otherwise would never have existed.
Paul shares an encounter from a recent Supabase user conference: - A roughly 50-year-old taxi driver from Brazil approached Paul after the event to express his gratitude. - The driver had programmed an entire regional taxi application—a personalized, local alternative to Uber—directly from his mobile phone. - Despite having spent his career as a blue-collar worker with no formal software development background, he exhibited the infectious enthusiasm of a teenager discovering coding for the first time.
Paul reflects on the significance of this shift amid widespread economic anxiety:
> “There's so much uncertainty around like what is the future of work going to look like, but in this category of builders, there's that excitement of the future, and that's really what I love about Supabase.”
This breakthrough enables individuals confronting career uncertainty or blue-collar displacement to unlock high-leverage capabilities, building custom software tailored to their exact local realities.
`10:00` Personal Software and the "Control Tower": Owning Your Database
Garry Tan shares how his recent obsession with personal software evolved over the preceding six months. While he initially swore off graphic interfaces—claiming everything would live purely in Markdown files and interact through chat interfaces like OpenClaw—he eventually hit a wall where structured data and dedicated interfaces became indispensable. Over a couple of weeks, he built out a custom personal operating system dubbed "Control Tower." The system centralizes disparate aspects of his everyday life: an email triaging interface that bypasses his standard inbox, a workout and bodyweight tracker, and a personal finance dashboard.
The primary advantage of building single-user bespoke software is hyper-specific context. Entire venture-backed startups were founded to tackle personal finance categorization, yet Garry notes his own bespoke app works better for him because it cross-references ambiguous bank transactions with his personal knowledge graph, GBrain, immediately identifying individuals and tagging expenses accurately. Paul Copplestone observes that health and personal finance represent the two distinct domains where individuals refuse to hand over their data to third parties. Syncing biometric devices into a personal database unlocks powerful multidimensional correlations: Garry’s setup links his Supabase database to his calendar, recognizing when a weight spike coincides with business travel and contextually prompting him that everything is fine and he can simply reset the following week.
```mermaid flowchart TD accTitle: Personal Architecture of Garry Tan's Control Tower accDescr: Diagram illustrating how inputs feed into a central Supabase database and GBrain context engine to power swappable agents and custom UIs.
subgraph Inputs["Data Ingestion"] A["Biometrics & Fitness"] B["Bank Transactions"] C["Calendar Events"] D["Email & File Uploads"] end
subgraph Storage["Owned Data Store"] E["Supabase Postgres"] F["S3-Compatible Storage"] G["GBrain Knowledge Graph"] end
subgraph Interface["Application Layer"] H["Control Tower UI"] I["Decoupled Personal Agents"] end
A --> E B --> E C --> E D --> F E <--> G E --> H E --> I ```
Garry highlights a strategic danger with current agentic workflows: allowing routines, customer management, and personal records to become siloed inside a single proprietary agent provider. To avoid lock-in, he has systematically extracted his CRM and personal data into Supabase, utilizing its core database alongside its S3-compatible file storage for arbitrary email and document dumps. Historically, databases were massive systems maintained exclusively by large enterprises because setting one up required specialized programming skills. With coding agents, the paradigm has inverted: the database becomes the foundational, owned system of record on top of which swappable models and interfaces operate.
- Garry Tan on the shift toward owning your personal data layer: “The database is actually a 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.”
---
`14:15` From YC Index to a Billion Databases: The Scale of Universal Builders
The conversation turns to whether every individual in the world—not merely professional software engineers—will eventually run their own Supabase database to house their health metrics, financial records, and personal networks. Paul Copplestone welcomes that future, stating that access to artificial intelligence turns everyone into a builder capable of tweaking UIs and tailoring software without submitting to the design decisions of external SaaS vendors. When Supabase originally joined Y Combinator, its goal was to act as an index on YC by securing every incoming batch company on day one. While the founding thesis remains unchanged, the total addressable audience has widened by several orders of magnitude.
Supabase currently provisions over one million databases every single week. Paul points out the dramatic mathematics of the emerging agentic landscape: if ChatGPT commands 1.2 billion weekly active users, and each user prompts an agent to launch a project or app once a month, that demand translates directly into 1.2 billion new databases per month. Servicing this velocity requires an infrastructure architecture fundamentally distinct from anything the database sector has ever seen.
- Paul Copplestone on the inevitability of end-user creation: “I certainly think that it'll be the case that everyone in the world with access to AI will become a builder of some sort like you can build anything you can customize it you want to make tweaks to some app some UI then you don't have to be beholden to to someone of course...”
---
`15:45` "Prototype to Petabytes": SQLite, Supabase Spark, and the Two Ends of the Market
Addressing whether standard PostgreSQL instances can realistically withstand billions of deployments, Paul admits that provisioning full-blown computing instances on AWS for every nascent project is economically and architecturally impractical. Most early-stage workloads do not require the computing horsepower of a "Ferrari." In response, Supabase developed an architecture compatible with both PostgreSQL and SQLite, introducing a lightweight tier known as Supabase Spark to service entry-level and exploratory workloads under the company's motto: "prototype to petabytes."
Jared Friedman points out that traditional database companies followed an enterprise playbook: starting with startups before quickly pivoting upmarket toward large corporate accounts to mimic Oracle's high-margin model. Leaning into lightweight tools like SQLite seems to push in the exact opposite direction. Paul acknowledges the immense tension of serving both spectrums simultaneously:
- **Scaling Down:** Supabase utilizes lightweight engines like Turso and SQLite-based architectures to cater to zero-cost, ephemeral prototyping workloads. - **Scaling Up:** Supabase employs its Multigres architecture to satisfy massive enterprise workloads that scale up to petabytes.
Managing these divergent demands while expanding the company during an AI explosion has proven to be an intense operational challenge, but one that ensures users never outgrow the platform as their traffic compounds.
- Paul Copplestone on maintaining continuity across workloads: “The idea will be the same, you get started with the same experience, you can scale up to petabytes, so our tagline's kind of prototype to petabytes and we as a company need to make sure that we can provide for everyone and if they do scale up and their business keeps growing then we make sure that they have a great time...”
---
`17:35` The 60% Agentic Shift and the CI/Testing Explosion
Paul shares metrics from an internal survey tracking AI adoption among Supabase’s engineering staff: in roughly six months, the proportion of Supabase engineers writing 80% or more of their production code with AI agents rocketed from just 10% to 60%. The company maintains no prescriptive top-down AI policy; leadership simply gave the engineering team complete freedom and budget to experiment with any tools they wanted. The shift occurred organically as developers realized frontier models were no longer restricted to superficial "vibe coding," but were capable of executing rigorous, complex systems tasks.
Because agents produce code at unprecedented volumes, engineering discipline has shifted heavily toward automated testing and verification. The hosts emphasize that Y Combinator startups focused on continuous integration, compute environments, and code quality—such as Blacksmith, Depot, UbiCloud, and Greptile (for automated code reviews)—are experiencing vertical growth curves. Engineers who entered the year skeptical have been convinced by rapid model improvements and high-profile reasoning breakthroughs on complex domains like Navier-Stokes equations, solidifying the consensus that autonomous code generation is now the permanent industry standard.
- Paul Copplestone on internal engineering adoption: “And I think now it's just that they're convinced that the models can do so much better work and so much more so the adoption has been crazy and yeah the the things that they're building internally are not just vibe coded type stuff they're pretty intense...”
`20:00` Supabase's Three Eras and the Shift to Code-First
The group reflects on Supabase's evolution through three distinct product eras: beginning as a dashboard company built in 100 days during Y Combinator, morphing into an API platform, and now entering an agent-driven era centered on making something agents want. Paul Copplestone recalls that launching a database startup at YC initially felt deeply contrarian, prompting skepticism about why a new database company was even needed. The founding insight stemmed from recognizing how painful databases remained even for trained software engineers. Loving Airtable, the team set out to build an intuitive, Airtable-like user interface directly on top of Postgres.
```mermaid flowchart LR accTitle: Evolution of Supabase Architecture Across Three Eras accDescr: A flow showing the transition from a dashboard UI on Postgres, to an API platform for tools like Bolt, to an agent-driven code-first paradigm. subgraph Era1["Era 1: Dashboard (YC)"] D["Airtable-style UI"] --> P1["Postgres Database"] end subgraph Era2["Era 2: API (2021–2024)"] API["Programmatic API"] --> P2["Mass DB Spinup (Bolt, Lovable)"] end subgraph Era3["Era 3: Agent Era (Present)"] Ag["AI Agents / Code-First"] --> Git["Git-Native / Sandboxes"] end Era1 --> Era2 --> Era3 ```
Around 2021, customer demand prompted the second shift: external platforms integrated with Supabase and needed programmatic APIs to spin up high volumes of databases on demand. By 2024, tools like Bolt and Lovable began deploying massive fleets of databases. The most recent shift arrived when Paul realized human developers were simply no longer visiting the dashboard. In response, he circulated an internal product memo mandating that Supabase pivot entirely to a code-first, Git-native architecture:
> “So if it exists on the dashboard, it basically has to work in lockstep in code.” — Paul Copplestone
- **Era 1 (YC)**: Airtable-like spreadsheet dashboard built on Postgres in 100 days to remove friction for software engineers. - **Era 2 (c. 2021–2024)**: API-centric model engineered for platform integrations and automated database provisioning (supporting tools like Bolt and Lovable). - **Era 3 (Present)**: Code-first, Git-native architecture engineered directly for autonomous agents executing infrastructure as code within sandboxes.
`22:31` Predecessors, Enterprise Scaling, and the Heroku Legacy
The discussion turns to earlier developer-platform pioneers, specifically Parse and Firebase. Paul acknowledges that both companies blazed a trail by validating standalone backend and database businesses. Around 2014, deploying a production database anywhere other than Amazon RDS seemed inconceivable, but the rise of Parse, Firebase (later acquired by Meta and Google, respectively), and MongoDB with Atlas demonstrated that companies outside the big three hyperscalers could establish viable database ecosystems. Those transitions were accelerated by historical market shifts: MongoDB convincing the industry that NoSQL was the future of data storage, combined with the explosive emergence of mobile app development.
The hosts draw comparisons to Heroku, which pioneered world-class developer experience but struggled to retain massive applications once they reached enterprise scale and performance bottlenecks. When asked whether Supabase must eventually move upmarket or whether it can build an enormous business purely by capturing the explosive 0-to-10 developer tier, Paul insists on pursuing both. While Postgres historically possessed scaling limitations, Supabase has wrapped it in proprietary tooling and abstractions to allow it to scale indefinitely. Paul points out an industry benchmark: roughly 30% of AWS revenue comes from startups that started on AWS on day one and grew into giants. Securing users on day one is critical because convincing an engineering team to migrate databases after the fact is nearly impossible:
> “We know that to convince people to migrate to from one database provider to another is near impossible and so we just want to be there on day one make sure that they have a great time and then make sure that they actually don't want to leave.” — Paul Copplestone
The hosts compare this dynamic to Stripe’s model—securing fast-growing startups on day one and riding their expansion for an entire generation. However, Paul observes that defining what "day one" looks like has become far more complex. While day one once meant onboarding standard YC batch founders, today it encompasses a sprawling new audience of non-traditional builders using novel modalities and agentic workflows.
`25:00` The Prosumer Database Market and Dogfooding with Voice Agents
The expansion of AI builders has fractured Supabase's addressable market into two distinct segments: standard high-growth early-stage startups and an emerging direct-to-consumer or prosumer base. Historically, running a direct-to-consumer database company would have sounded like an outright syntax error. Today, individual consumers and their personal agents spin up databases to power bespoke personal software, such as personal finance trackers or small local business tools. While individual personal databases do not scale with traditional venture-backed trajectories, users accumulate lifetime data within them, turning continuous personal data storage into a steady index of Supabase’s growth.
Paul explains that his confidence in personal agents surged after his executive assistant took a week off, forcing him to rely entirely on agents and discover their practical utility firsthand. To strictly dogfood the developer experience for agents, he forces himself to operate without ever inspecting raw code:
> “And my kind of heuristic to make sure I'm building or dogfooding correctly is that i just don't look at the code and i don't allow myself ever to check the architecture except when i want to check that it's actually building things correctly but when i'm making these changes i just want to talk to one of us.” — Paul Copplestone
Paul builds by staying on continuous voice calls with tools like Dot, dictating application adjustments verbally. The hosts and Paul joke about the surreal pace of advancement, noting that capabilities that feel standard today would have seemed like impossible science fiction just six months earlier.
`27:00` Brainstorming an Agent-Only Developer Conference
Recalling the recent Supabase Select conference, one of the hosts shares an epiphany: as software builders increasingly delegate implementation details to AI, human founders will no longer need to attend tech keynotes to learn about new platform primitives. Instead, users will send autonomous agents to conferences to digest feature announcements, evaluate compatibility, and autonomously integrate updates into production code bases.
The room riffles on the idea of launching an official virtual conference designed exclusively for AI agents: - Agents attend the live event simultaneously over network bridges to trade tips and discover platform updates. - Rather than slides or swag, the conference broadcasts documentation and machine-readable context files directly to connected agents. - Paul suggests an event name on the spot: **"The Artifactory."**
The conversation pivots to the concrete engineering adjustments Supabase is making to optimize for machine developers over human ones—particularly by retooling error messages and debugging outputs so agents can independently parse failures and fix their own code.
`30:00` Re-Engineering Developer Tools and Error Messages for AI Agents
Paul Copplestone recounts attending a developer tools dinner where he was surprised to find that optimizing developer tools for AI agents is still not obvious to many creators. Historically, developer tool error messages were bare-bones alerts—like a standard 500 error indicating that something went wrong—leaving it to a human developer to search Google and troubleshoot. For AI agents, however, error messages need to be instructional self-correction guides. Supabase has re-engineered its errors so that when an agent hits an issue, the error payload explicitly provides the remedy or points directly to documentation, allowing the agent to fix the problem in a single shot rather than getting stuck.
```mermaid flowchart TD accTitle: Agent Error Recovery Flow accDescr: How agents handle errors when tools provide instructional error messages versus generic errors.
subgraph Failure["Traditional vs Agentic Response"] A["Agent Executes Postgres Action"] --> B{"Encounter Error?"} B -->|"Generic 500"| C["Agent Stalls / Switches Tools"] B -->|"Self-Healing Payload"| D["Actionable Fix & Doc Pointer"] end
subgraph Resolution["Automated Recovery"] D --> E["Agent One-Shots Fix"] E --> F["Successful Execution"] end ```
Paul highlights that capturing mindshare in the agentic era requires winning two distinct battles. As Paul explains: “The first is being picked by the model, and then the second is if they get stuck, you don't want them to switch away.” Because agents will inevitably hit edge cases, systems must provide the diagnostic tooling required to resolve them autonomously. To ensure models succeed, Supabase spends a large portion of its internal engineering effort running automated evaluations that benchmark how various frontier models interact with Postgres, building agent skills and testing suites designed around practical user workflows rather than merely shipping raw infrastructure.
- Traditional developer tools rely on human troubleshooting (e.g., manually debugging depleted iNodes), whereas agent-ready tools embed resolution steps into the error string. - Supabase maintains a dedicated public evals website tracking which LLMs write the best Postgres queries and build applications most effectively. - A significant share of Supabase's current engineering capacity has transitioned from core feature development to building automated testing suites around real-world agent use cases.
---
`32:30` GBrain: Augmenting LLM Context with Postgres and Knowledge Graphs
Garry Tan shares how he developed "GBrain," a personal retrieval-augmented generation (RAG) system running on top of Supabase. Garry traces the lineage of the project back to "Garry's List"—an agentic newsroom that ingested research papers, policy documents, and news feeds to synthesize complex topics—which he later adapted into an open-source retrieval engine for OpenClaw. In earlier Ruby on Rails prototypes, Garry treated every LLM call as precious and fragile, likening the rigid architecture to a Foxconn assembly line. Moving to modern agent setups felt radically different, freeing him to treat the model as a capable partner with a massive working memory.
Even with context windows scaling to one million tokens—equivalent to roughly three *Harry Potter* novels—Garry emphasizes that keeping the *correct* information in working memory remains a difficult retrieval challenge. Garry possesses over half a million Markdown files capturing decades of emails, notes, and personal communications totaling 30 to 40 gigabytes. Dumping this corpus directly into an LLM context is neither cost-effective nor fast, creating a critical need for an intermediate structure that blends pgvector semantic search with dynamic SQL knowledge graphs.
```mermaid flowchart LR accTitle: GBrain Retrieval Architecture accDescr: Flowchart illustrating how Garry Tan's GBrain uses Supabase and Postgres to distill context for an LLM agent.
subgraph Storage["Personal Knowledge Store (30-40 GB)"] MD["500k+ Markdown Files"] PG["Supabase Postgres"] VEC["pgvector Embeddings"] GR["SQL Knowledge Graph"] MD --> PG PG --- VEC PG --- GR end
subgraph Query["Agent Query Loop"] AG["Agent (OpenClaw)"] -->|"Request Context"| PG PG -->|"Graph Traversal & Vector Search"| RPT["Synthesized 2-Page Briefing"] RPT -->|"Load into Context"| AG end ```
By leveraging Supabase's hosted Postgres, GBrain dynamically traverses relationship graphs and runs vector queries to condense tens of gigabytes of raw data into a tight, two-page briefing tailored to whatever task the agent is executing. As Garry describes the architectural shift: “It's like, oh, the AI is smart. It's not trying to hurt you. And then you should just let it do stuff, and you should just give it data and capabilities.” With tools like browser-use and modern APIs, agents can now interact directly with Supabase, handling schema updates, querying records, and managing database infrastructure autonomously.
---
`36:00` Autonomous Research Loops and Dynamic Database Retrieval
The conversation shifts to the future of data retrieval and self-improving software architectures. Paul recounts a database dinner where attendees explored the concept of dynamic retrieval: if a recurring search across an unstructured dataset takes ten seconds, an agent can run in an automated loop to invent, test, and apply a purpose-built indexing structure to slash query latency below a second.
Garry details how he implemented an autonomous optimization loop within GBrain using production traces and a dedicated repository titled `gbrain-evals`. Using the Cappy framework's "Captains" (persistent agent loops similar to Grok bots), he assigns specialized tasks: one agent continuously generates new evaluation categories, while another iterates on retrieval strategies to improve scores across forty performance dimensions, spanning latency, cost, and retrieval precision.
```mermaid flowchart TD accTitle: GBrain Recursive Self-Improvement Loop accDescr: Continuous evaluation and deployment loop using autonomous agent captains.
subgraph Evals["gbrain-evals Engine"] TR["OpenClaw Production Traces"] --> DS["40 Benchmark Categories"] C1["Captain: Category Creator"] --> DS C2["Captain: Auto-Research & Tuning"] --> DS end
subgraph Deployment["Automated Code Ship"] DS -->|"Metric Improved"| M["Merge to Master by Default"] DS -->|"Metric Degraded"| MD["Log Markdown Post-Mortem"] end ```
Whenever the autonomous research agent discovers a code or prompt modification that improves eval benchmarks, it automatically commits and merges the change to production. If an experiment fails, the agent writes a Markdown file analyzing why the hypothesis fell short and files it away into the repository. Garry notes that while this setup is currently tailored to his specific personal corpus, it functions as a working prototype of recursive self-improvement (RSI) that can be generalized to any structured or unstructured data pipeline.
- The `gbrain-evals` framework tests across 40 specialized categories, targeting trade-offs between context depth, vector similarity, latency, and token expense. - Successful algorithmic improvements are pushed directly to `master` with no human approval gate, while failures automatically generate diagnostic post-mortem reports. - Garry highlights the power of these autonomous loops: “And then the cool thing about evals is then you can just tell the agent like loop. Just auto-research and loop, and anything that improves your stats on this eval, like ship it into master on by default.”
---
`38:45` Software Factories, Evals, and Conversational Software Creation
Paul asks whether end users and future builders will genuinely need to master technical concepts like evals, benchmark datasets, and retrieval tuning, or if those mechanics will be abstracted away. Garry reflects on the rapid pace of change, noting that the industry is still actively discovering the fundamental primitives of agentic software. He recalls reading Steve Yegge's essays on "software factories" earlier in the year and initially struggling to visualize how they would function in daily practice, only to realize he had organically assembled his own personal factory through agent loops and evals.
The group contrasts this hands-on engineering paradigm with an alternative vision of software development where users never interact with evals or architectural frameworks at all. In that model, a person simply talks to Claude or another model as they would to a collaborator, and the system autonomously handles all testing, data modeling, and code generation. Paul shares a lighthearted anecdote illustrating how quickly project ideas can materialize: he had originally registered the domain `OpenUSD` because of Pixar's Universal Scene Description 3D graphics file format. When Stripe and Visa subsequently announced their open payment initiative under the same moniker, he suddenly found himself sitting on a topical domain name that he wished he had an autonomous agent to build out for him.
`40:00` Bedside Coding with Voice and Dogfooding for the "Normie" Era
Paul Copplestone recounts a personal breakthrough while building out a developer and ecosystem site. After working on his computer, he carried on by calling an AI agent over voice on his phone while getting ready for bed:
> “And as I was winding down my day, I called it on my phone as I'm getting to bed, which sounds sus, but I promise I'm just coding with it.”
He told the agent that he disliked the site's information architecture and wanted to know how better to link the ecosystem to the use cases. The model offered suggestions, Paul told it to implement them, and within twenty seconds it reported that the task was finished. When he refreshed the page, the cross-links and SEO setup were already live. Because he did not have to write boilerplate code or navigate manual configurations, it felt like an authentic glimpse of how development will work going forward.
```mermaid flowchart LR accTitle: Mobile Voice Agent Coding Workflow accDescr: Diagram showing the flow from voice instruction on mobile to automated architectural updates. subgraph Input ["User Input"] A["Voice call on phone<br/>(Late night)"] end subgraph Agent ["Agent Processing"] B["Analyze ecosystem<br/>& use case architecture"] C["Generate structural<br/>proposals"] D["Execute refactor<br/>(20-second turnaround)"] end subgraph Output ["Live Result"] E["Cross-links & SEO hooked up"] F["Page refreshed & verified"] end A --> B B --> C C --> D D --> E E --> F ```
The hosts observe that Paul's success still relies heavily on knowing *what* to build, which stems from his engineering background. Paul acknowledges this, noting that he deliberately avoids pointing agents toward GitHub repositories and instead forces himself to code like an everyday user ("a normie") to dogfood Supabase properly. He wants to ensure that a non-technical builder will have a seamless experience on the platform twelve months from now. While frontier labs often claim models will simply do everything automatically inside their weights, Paul notes that in practice, models still need clear markdown context and small amounts of targeted prompting to succeed.
---
`42:00` Parabolic Capability vs. Constant Direction: The 2027 Optimism
The group discusses the surreal inflection point society is facing as AI capabilities undergo rapid acceleration, likening it to recursive self-improvement (RSI) taking hold inside development loops like Claude Code and Codex. A core tension is emerging: model intelligence is spiking vertically, yet the number of people who understand what to build to create real-world utility remains essentially static.
> “Like the capabilities, the models are like going parabolic. And then the number of people who know how to actually have an impact on society with it is like more or less constant.”
Paul contrasts the prevailing tech-industry paranoia with his own optimism. Having spent earlier chapters of his career building software for blue-collar workers and wrapping technology around people who spent their lives doing hard manual labor, he views lowering the barrier of software creation as deeply emancipatory. Supabase's role in powering thousands of new micro-entrepreneurs points toward a future where self-directed enterprise becomes a viable, fulfilling lifestyle for ordinary people. Assuming macroeconomic shocks or major disruptions can be avoided, he is exceptionally bullish on where the industry will land by 2027.
---
`43:40` The Series A Crunch for Vertical SaaS and the $30M Lean Team
The hosts bring up a sudden shift in early-stage venture funding: vertical SaaS companies are struggling to secure Series A rounds even after reaching milestones that once guaranteed them.
| Metric / Scenario | Historical Expectation | Emerging Reality in 2026 | |:--- |:--- |:--- | | **ARR at Series A** | $5M to $10M was a guaranteed fundraise | VCs often pass; market favors horizontal AI plays | | **Headcount Requirement** | 100+ employees to reach $30M ARR | 10 to 15 people operating at $2M ARR/head | | **Capital Raised** | ~$100M raised to scale out sales & engineering | Near-zero dilution; businesses fund growth via cash flow | | **Profit Margins** | Heavy burn, reinvesting cash to scale headcount | ~50% margins yield massive distributions per head |
The hosts observe that founders routinely come into office hours demoralized because venture firms refuse to fund their $5M to $10M ARR businesses, despite horizontal AI infrastructure getting funded freely. Yet this funding drought is a hidden advantage: modern development efficiency allows small teams of 10 to 15 people to scale companies to $25M, $30M, or even $50M in ARR. At $2M in revenue per employee and 50% profit margins, the business generates massive, durable cash flows without diluting ownership.
> “You're probably going to look back on this as a blessing. You don't need the money. Like time was you had to raise like a hundred million dollars to get to like 30 million a year in revenue because you just had to hire all these people. And now you don't have to do that.”
Paul agrees, pointing out how founder culture has traditionally treated fundraising rounds as validation badges. He reflects that early in his journey, raising capital felt like achieving something monumental; today, achieving profitability without external capital represents true success, and he finds himself envious of lean teams that never have to take outside checks.
---
`45:00` The Lindy Effect of Postgres and Navigating Future Inflection Waves
Asked how Supabase manages to stay resilient and capture upside through successive hype cycles—from hand-coded applications to vibe coding to autonomous agentic workflows—Paul emphasizes two core operating principles:
1. **Category Durability (The Lindy Effect):** Rather than chasing ephemeral interfaces, Supabase anchors itself to the fundamental primitives of computing: > “One thing that helps me sleep well at night is that it's kind of the Lindy effect. Databases have been around for 50 years. I think they'll be around for another 50 years. And this is one that at the end of AI, no matter what, I'm pretty certain there'll be databases.” 2. **Speed of Adaptation Over Complete Answers:** Many developer-tool companies mature, prioritize enterprise sales, lose touch with grassroots builders, and stagnate. Supabase attempts to follow the Stripe model, where leadership keeps active attention trained on how emerging software is written, intentionally reserving engineering bandwidth to pivot quickly when developer behavior shifts.
When asked about tactical lessons for surviving future waves, Paul underlines relentless personal dogfooding. He constantly uses Supabase via third-party coding agents to hit walls firsthand, noting that there is no substitute for experiencing the points of friction yourself. Additionally, Supabase maintains tight feedback partnerships across its ecosystem, intentionally budgeting engineering slack so the team can run experimental collaborations. Many of these joint bets fail to gain traction, but the occasional winner enables Supabase to successfully ride major technological waves as they break.
## Notable quotes > `10:00` The database is actually a 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. — Garry Tan
> `45:00` Databases have been around for 50 years. I think they'll be around for another 50 years. And this is one that at the end of AI, no matter what, I'm pretty certain there'll be databases. — Paul Copplestone
## Mentioned Airtable, Amazon RDS, AWS, Blacksmith, Bolt, Cappy, ChatGPT, Claude Code, Codex, Control Tower, Depot, Dot, Firebase, Garry Tan, Garry's List, GBrain, Greptile, Harj Taggar, Heroku, Jared Friedman, Lovable, MongoDB, MongoDB Atlas, Multigres, OpenClaw, OpenUSD, Parse, Paul Copplestone, Pixar, PostgREST, PostgreSQL, SQLite, Steve Yegge, Stripe, Supabase, Supabase Select, Supabase Spark, The Artifactory, The Lightcone, Turso, UbiCloud, Uber, Visa, Y Combinator
## Video description <p>Supabase has become one of the default backends for the AI coding era. The open source Postgres platform now has 13 million users, spins up more than a million databases every week, and roughly 70% of its new activity is coming from agents.As coding shifts from developers writing software by hand to agents building on their behalf, Supabase has been rebuilding itself around that new user.Supabase co-founder and CEO Paul Copplestone joins Garry, Harj, and Jared on the Lightcone to talk about what happens when everyone can become a builder. They dive into why personal software may become as common as personal documents, how to design products that agents actually want to use, and why knowing what to build may matter more than knowing how to build it.</p>
[Source](https://anchor.fm/s/8c1524bc/podcast/play/128439961/https%3A%2F%2Fd3ctxlq1ktw2nl.cloudfront.net%2Fstaging%2F2026-9-30%2F435443834-44100-2-4c3222fd064fb.mp3)