Supabase’s Plan for a Billion AI-Built Apps

Summary

• Supabase’s billion-database thesis requires cheaper starting points and a credible path to large production workloads. The founders report launching five million databases monthly and expect to need billions; acquiring Turso supplies technology for smaller, file-based databases. Supabase Spark is intended to offer “one database for any idea,” with upgrades to full Postgres and eventually Multigres for larger workloads.
• Better models are improving acquisition, activation and paid conversion together. The founders say agent-driven activation is almost 100%, while these users convert to paid accounts at higher rates than traditional developers. Paul says seeing a customer earn what he thinks was $10,000 within the first few days changed their assessment of vibe coding: “People are making real things that generate real money.”
• Supabase compensates salespeople for expansion above the growth it already sees without their intervention. In Paul’s illustrative example, nonresponding accounts grow 25% month over month, while accounts receiving help grow 125%. Paul calls the difference “100% incremental uplift”; the sales instruction is to diagnose problems and help users, supported by product telemetry and AI-generated scripts.
• Enterprise expansion remains a greenfield strategy because production databases are exceptionally difficult to displace. Paul expects almost all enterprise attention over the next five years to go toward new workloads. Coding agents might simplify rewriting legacy applications, but revenue-threatening downtime and split-brain reconciliation remain the migration barriers: “I guarantee they’ll almost never migrate.”
• AI labs and product-led growth outrank enterprise sales in Supabase’s priorities. Swyx describes Supabase’s former expectation that product-led growth might reach a $100–200 million ceiling; now the question is, “Is it a billion? Is it two billion?” CPU shortages also make infrastructure access strategic, with incoming investor CapitalG offering access to the Alphabet ecosystem as Supabase considers GCP and deeper Alphabet relationships.
• Supabase is treating community participation as both distribution and something worth rewarding with ownership. It has earmarked $1 million in stock to give community members after finding conventional crowdfunding too restrictive. The first recipient to be highlighted, Gary Abbott, answered 20,000 community questions over six years, including 13,000 within an hour.
• Internal AI spending is substantial, but the operating goal is completing entire processes. Ant reports approximately $300,000 monthly for 450 people, with teams largely choosing their own tools. Its async documentation supports company-wide AI systems, while the founders agree that keeping production infrastructure running remains unsolved for AI: “Not yet.”

Deep dive

1. Postgres scaling begins with compatibility and failure testing

• Paul’s performance announcement, OrioleDB, replaces Postgres’s Heap storage engine and claims 1.5–2 times faster performance: “You don’t have to change anything else.” It removes the need for some background tasks, such as vacuum and bloat. Supabase acquired the technology, continued development, paid for its patent, and is releasing a full beta under Apache 2.0, which covers the patent.

• The engine underwent pg_regress compatibility testing, Antithesis, nightly TPC-C benchmarks and Jepsen. Multigres tackles a separate reliability problem: Paul says every Postgres operator they examined could lose data under certain conditions. Supabase rewrote the operator architecture and reports 1,000 sequential failovers without data loss; platform access initially targets serious workloads by invitation.

• Sharding remains unfinished. Paul recounts Sugu’s lesson from Vitess: “I want to focus only on compatibility first,” so applications should eventually keep their queries unchanged when moving to sharded Postgres. Some sharding work should land by early next year, depending on platform developments. Design partners include Booz Allen, Postman and Perplexity; the project is open source beyond Supabase’s own service.

2. Turso supplies the architecture for billions of small databases

• Supabase currently launches about five million databases monthly; the founders think it will need billions. Giving every prototype a dedicated Postgres cluster would exhaust available computers. The Turso acquisition addresses this different scaling problem: tiny databases need an economical file format, while demanding transactional applications retain a separate route through Postgres and Multigres.

• Paul describes Turso’s architecture as adding MVCC capabilities around SQLite, including multiple writers. Its rewrite created a pathway toward Postgres compatibility, which prompted his outreach to Glauber. Paul says object storage has, he thinks, “11 nines” of durability and can supply part of what a database cluster otherwise provides. Swyx’s correction matters here: durability is distinct from reliability.

• Turso will retain its brand and SQLite focus. Supabase Spark will introduce a smaller instance type compatible with Supabase’s libraries: “One database for any idea, any prototype.” The intended progression is Spark to full Postgres to Multigres. The founders call zero-downtime migrations a requirement: an experiment reaching Hacker News’s front page must have somewhere to grow.

3. Compute removes an execution limit while CPU scarcity shapes strategy

• Supabase Compute addresses Edge Functions’ stated two-second limit. It supports long-running, serverless container workloads, including Rust, Python, agents, chunking and embedding, inside the database’s private network with direct Postgres connections. Durable workflows become possible to build because the missing primitive was compute; previous community attempts on Edge Functions ran into the timeout.

• Capacity already requires close planning with AWS and paying more. Paul connects incoming investor CapitalG to both Alphabet’s AI products and a multicloud strategy: “We need more compute.” GCP is the obvious next candidate, although he explicitly does not know whether its object storage matches every relevant S3 feature.

• Swyx describes S3 Express write times of one to two milliseconds: applications can acknowledge a write after placing it somewhere sufficiently durable, then move data into cheaper S3 in the background, as Ant explains. Swyx asks whether Redis is still necessary; Ant’s answer is categorical—yes. Ant describes the storage layers as memory, an NVMe drive, locally attached storage, S3’s equivalent, and regular S3.

4. Better models turn experimental builders into paying customers

• Paul divides Supabase’s AI growth into three chapters. First came embeddings: Andrew Kane’s extension helped demonstrate that Postgres could also serve vector workloads. The pitch was consolidation—“You don’t need another database if you’re gonna store your own embeddings.” Paul separately praises Turbopuffer’s use of storage innovations resembling Turso’s.

• The second chapter arrived with Lovable and Bolt toward the end of 2024. Supabase debated servicing these builders and even building its own competing interface. Its mission resolved the question: “Store the world’s data” meant being present when projects started, including toy projects, while believing the tools would improve. Simultaneously, existing customers needed larger-scale infrastructure.

• Monetization made the change tangible. Paul says he thinks it was $10,000 that a customer earned within the first few days of launching. Agent-assisted Stripe integration lets projects collect money within their first week. MagicSchool supplies another example: its founder was a teacher who identified repetitive teaching tasks and built a business without the traditional technical-cofounder structure.

• The third chapter began when models improved at the start of the year. Signups accelerated despite little marketing expenditure, while activation and paid conversion also increased. Agents perform setup themselves, bringing activation close to 100%; the founders say these users convert to paid accounts more readily than traditional developers. Swyx’s compression: “Friction’s gone.”

5. Community distribution became model distribution

• Supabase’s original “Realtime Postgres” positioning attracted little attention. Switching to “open-source Firebase alternative” preceded an unsolicited Hacker News launch roughly 12 hours later. Users jumped from eight to 800. The infrastructure consequences were immediate: about $10,000 in DigitalOcean credits disappeared within 48 hours, followed by migrating 800 databases to AWS during YC’s first week.

• Swyx argues that Supabase benefited from being established three to four years before LLMs took off, positioned against an existing category leader. The founders acknowledge fortunate timing but now invest heavily in AEO. Community tutorials, videos and posts supplied material models could absorb; support answers were also collected in GitHub Discussions and mirrored onto Supabase’s website.

• After lawyers resisted broad crowdfunding without accredited investors, the founders asked, “What if we just give them the stock?” They have earmarked $1 million for community members. Gary Abbott, known as Gary Austin in Discord, answered 20,000 questions over six years, 13,000 within an hour. A retired enthusiast who built a wine app becomes the first highlighted recipient.

6. Product-led sales rewards help that produces additional growth

• Paul frames Supabase as an “index company,” reporting that 60% of each YC batch uses it. Stripe is the benchmark: a developer company that moved upmarket for more than a decade while retaining developer affection. Sales is layered onto that adoption through product signals, rather than replacing the developer-led motion.

• Triggers include important logos, scaling, errors, limits and spending. Paul’s illustrative example starts with 1,000 weekly triggers and outreach emails, producing 500 replies. Usage patterns reveal the account’s problem; AI helps prepare a script. The instruction to salespeople is: “Get on a call with these people and help them.”

• In the example, nonresponders serve as the comparison cohort and grow 25% month over month; responding accounts receiving assistance grow 125%. Paul calls the difference “100% incremental uplift,” and compensation follows that increment. His objection to conventional quotas is that they credit salespeople for expansion the product would already have generated.

• Enterprise demand also arrives from self-hosting that Supabase deliberately does not track. Paul describes pharmaceutical companies, for example, running 100 instances. Control Tower repackages fleet-management capabilities developed for Supabase for Platforms into an enterprise view for launching, monitoring and administering internal databases. Paul says the product launches tomorrow, though he does not know if it will be announced then.

7. Database stickiness survives easier code generation

• Paul’s enterprise position is unusually firm: “I guarantee they’ll almost never migrate.” For roughly the next five years, almost all of Supabase’s enterprise focus goes toward greenfield workloads. Enterprises want more employees building products; CPOs returning to development through Lovable and Supabase now become executive champions without a separate effort to cultivate them.

• Swyx pushes on the larger opportunity: coding agents might finally enable migration away from legacy systems such as Oracle. Paul concedes that rewriting million-line stored procedures is probably easier now. He still considers landing inside the enterprise the first priority; pursuing wholesale replacement sounds attractive but has repeatedly proved difficult for database providers.

• Paul’s explanation centers on OLTP economics. The production database powers a revenue-generating application, so a minute of downtime loses money. Running old and new systems in parallel creates split-brain risk, with data diverging across both. Reconciling that state is hard; starting new workloads elsewhere is one way to proceed. Swyx points out that this can leave customers with two problems.

• Swyx also asks whether customers will be more attached to Lovable or Supabase as their offerings overlap. The founders emphasize the difficulty of moving databases. They credit Lovable with being first to do a good job of preventing agents from stuffing images into Postgres or disabling RLS to make applications work; better skills helped, and newer models now make fewer such mistakes.

8. Analytical workloads deserve their own architecture

• Asked about Databricks’ HTAP claims, Paul says Supabase is particularly interested in DuckLake and DuckDB. Swyx describes DuckDB as “like a SQLite for analytics,” able to read object storage and Postgres. Paul says Supabase’s inclination is to use the right technology for each job. Swyx notes that he has not examined Databricks’ implementation closely and could be misquoting it.

• The architectural objection is physical: local NVMe capacity has limits, and if a transaction has to be split across servers, fetching data from object storage eventually slows the database. Paul sees sharding as the best route toward petabyte-scale OLTP, with analytics treated separately. Reading shared object-stored data through another route remains possible; “trying to smash these two together” does not necessarily make sense to him.

9. Lab defaults could lift the ceiling on product-led growth

• Paul ranks the priorities as winning strategic labs, winning models and continuing product-led growth; “P4 is enterprise.” US labs receive most attention because they currently deliver the most traffic, a condition the founders acknowledge could change. Becoming a default backend when an AI product creates an application is particularly attractive.

• Scale previously prevented that role. Using ChatGPT’s stated 1.2 billion monthly active users as a hypothetical, one database per user monthly means 1.2 billion databases. Paul presents Turso’s technology as the route toward that scale. The example is a capacity requirement for a possible distribution relationship, rather than an announced deployment.

• Swyx recalls that Supabase once thought product-led growth could reach $100 million, perhaps $200 million, before needing another sales motion. AI lifted that ceiling, but the founders do not know where it now sits: “Is it a billion? Is it two billion?” A revenue target colleagues feared would disappoint the team was reached in about four months.

10. Declarative files make the backend easier for agents to understand

• Paul describes a progression from dashboard-led development through APIs toward code-first, Git-native workflows. A local Supabase folder represents the backend, including functions and database structure. The new pg-delta library supports declarative Postgres schemas, covering tables, policies and comments, and can be used with Postgres databases beyond Supabase.

• Migration histories are a poor reading surface for agents: determining a table’s current shape might require reconstructing a thousand files. Launching a local database, replaying migrations and introspecting it also takes time. A declarative schema gives the agent the present state directly, supporting rapid iteration on the filesystem.

• Ant’s longer-term question is what people will build when personal agents can create applications almost immediately. Ant is already trying development from a phone, while acknowledging that infrastructure knowledge helps direct the agent. “I want to build X” producing a live application a second later is an imagined destination guiding today’s tooling decisions.

• Swyx raises the risk that agents could converge on one approach and trap development at a local maximum. Ant says low-taste, casual builders may converge on the model’s norm, while discerning, high-skill people will keep caring about the details. Paul asks how those high-skill people will continue to be trained; Ant suggests self-teaching and curiosity will persist among top-tier builders.

11. Open source may consolidate after an AI-assisted rewrite cycle

• An early hiring story illustrates Supabase’s approach to dependencies. Despite YC’s general advice against immediately expanding the team, its partner encouraged hiring Postgres maintainer Steve Chavez. The assignment was effectively “Don’t worry about Supabase”: keep improving Postgres, with Supabase hiring more people dedicated to that project as the team grew.

• Ant thinks many tools could converge on Rust if it proves the faster, more correct implementation choice. That could produce a few winning projects rather than endless individual rewrites; developers should preserve their “innovation tokens.” Ant also acknowledges operational tradeoffs around Elixir and BEAM. A coordinated dependency-rewrite fund appeals to the founders, although Ant doubts people would stop doing their own versions.

12. Internal AI investment targets complete processes

• Ant describes Supabase as different startups “glued together,” with product teams choosing tools and working practices. AI policy largely follows that autonomy, although costs are beginning to be consolidated. Checking internal records, Ant reports current spending of approximately $300,000 monthly for 450 people. Usage appears concentrated among a few employees.

• Swyx and Ant argue that spend leaderboards can focus attention on the wrong variable. The relevant question is how many complete processes AI handles without human intervention, or how much it compresses long-running work. Supabase’s async documentation makes a company-wide harness practical: its recorded history can supply decisions, context and operating principles.

• Reliability still requires hiring. Supabase reports roughly 50 open roles, especially SREs, with global remote work and location-independent salaries. Thriving in a fully async environment is a substantive requirement. Swyx says AI SRE remains one of the hardest startup categories; Ant agrees that AI has not yet cracked keeping systems running.