Why Agents Love Supabase
· Summarized
Key takeaways
- Supabase Compute is designed to remove Edge Functions’ roughly two-second limit by providing long-running, container-like serverless workloads colocated with the database, including Rust, Python, and agent execution.
- OriolDB is intended as a drop-in Postgres storage-engine replacement that the founders say is 1.5 to two times faster, reduces vacuum and bloat concerns, and passed compatibility, performance, and data-integrity testing.
- Multigres was rewritten because the founders found that existing Postgres operators could lose data under some conditions; its tests included 1,000 sequential failovers without data loss, though transparent sharding is still forthcoming.
- The Turso acquisition gives Supabase a lightweight SQLite-based path for the millions or billions of small databases created by prototypes and agents, with a planned upgrade path through Supabase Spark, full Postgres, and Multigres.
- Supabase attributes much of its growth to open source, community content, memes, and AI coding tools, with its founders saying activation and paid conversion rose as agents began creating and monetizing applications more quickly.
- For enterprise growth, Supabase prioritizes greenfield workloads and product-led assistance over migrating existing production databases, because OLTP migrations risk downtime, revenue loss, and split-brain synchronization problems.
- Declarative, Git-native database schemas are a central part of Supabase’s agent strategy because agents can inspect the current desired state directly instead of reconstructing it from a long history of migration files.
- The founders measure internal AI investment by completed end-to-end processes and reduced human involvement, not simply by token consumption; Supabase currently spends about $300,000 per month on AI tools across roughly 450 employees.
Summary
Why the host is examining Supabase’s rise
The host opens by explaining why this interview matters to him personally. He invested in Supabase’s seed round six years earlier—his first angel investment—and says the company went from zero to a $10 billion valuation during that period. He describes it as a fully remote, open-source company that is becoming a standard for hosted Postgres and says he wants to understand both its momentum and why it ranks so highly in his AI-engineering assessments. He frames the company’s Select conference around three themes: build, operate, and scale. In the “build” category, he highlights starting Supabase without Docker, running compute next to the database, and moving from migration-based SQL workflows toward declarative schemas stored in Git. He argues that agents need a source of truth they can inspect, fork, and modify quickly, but that humans benefit too; these improvements are not merely “for agents.” He describes Supabase as doing the last mile of Postgres development needed to make the database work well for agent-built software.
Supabase Compute removes Edge Functions’ two-second ceiling
The founders say the headline announcement is Supabase Compute, an environment for workloads that are too long-running or unconstrained for Supabase Edge Functions. Edge Functions are powered by Deno and have roughly a two-second limit, while users increasingly want to perform chunking, embedding, agent execution, and other longer jobs. Supabase Compute runs in the same private network as the customer’s database, so applications can make direct Postgres connections with low latency. It is serverless but effectively provides a full container, comparable to a container-style AWS Lambda rather than a short function. Customers can run Rust, Python, or other workloads instead of being limited to Deno, and can run agents alongside their database. The founders present co-located compute as the missing primitive for long-running workflows and as a foundation for future durable-workflow features that were previously impossible under the Edge Functions time limit.
OriolDB and Multigres target Postgres performance and reliability
The founders describe three database innovations aimed at scaling Postgres. OriolDB is a drop-in replacement for Postgres’s existing heap storage engine. They say it runs about 1.5 to two times faster, remains compatible with the broader Postgres ecosystem, and reduces the need for background work such as vacuuming and handling table bloat. Supabase tested it with PG-Regress, Antithesis, TPC-C, nightly benchmarks, and Jepsen, and is releasing it in full beta under the Apache 2 license, with a patent included under that license. Multigres addresses the operational problems of running Postgres across multiple nodes. The founders say they examined existing Postgres operators—software that manages clusters, failover, and backups—and found that every one could lose data under some conditions. They therefore rewrote the operator architecture from the ground up. Multigres completed 1,000 sequential failovers without losing data and was tested aggressively for other failure modes. It is open source, will be available on Supabase for serious workloads on an invite-only basis, and is intended eventually to provide transparent sharding without requiring application code or queries to change. Sharding itself is still under development, with early functionality expected around the following year.
The Turso acquisition creates a path from tiny databases to petabyte scale
The founders say Supabase currently launches about five million databases per month but expects a future in which it must launch billions. They argue that simply giving every small prototype a dedicated Postgres cluster would exhaust available computers, because many of these databases are tiny applications that may never gain traction. The answer is a scale-down path as well as a scale-up path. Supabase is acquiring Turso while retaining the Turso brand and its focus on SQLite. Turso’s architecture supports multiple writers through an MVCC layer around SQLite, while newer object-storage techniques make database-like file formats increasingly practical. Supabase will use that technology for Supabase Spark, a smaller instance type compatible with its libraries. A developer can start with one lightweight database for a prototype, then move through full Postgres and eventually Multigres as the application grows, ideally with zero-downtime migrations. The founders say this matters because nontechnical builders and agentic coding tools are creating many more applications. A product can go from a few users to serious traction after appearing on Hacker News, so the backend must offer a smooth path from a tiny file-format database to a large distributed system.
From Hacker News launch to AI-driven growth and community marketing
The founders recount Supabase’s early growth. Before its public launch, the company described itself as “real-time Postgres,” but changed the tagline to “open source Firebase alternative.” A Hacker News post took the project from eight users to roughly 800, and the team burned through about $10,000 in DigitalOcean credits in 48 hours. After entering Y Combinator, Supabase moved those databases to AWS using YC credits, spending its first week migrating 800 databases—an experience they describe as painful and as a lost opportunity for DigitalOcean, which would not extend its credit program. They also discuss their unusually deliberate meme strategy. Supabase has run weekly meme workshops, employs a small team of teenagers to help, and learned that good technical memes require both knowledge of the technology and an understanding of what developers find funny. The founders were once criticized for repeatedly dominating Hacker News launch rankings because it looked as though a YC company had a built-in advantage; they acknowledge that publicly celebrating every front-page placement was also “gloating.” The company’s growth has passed through three AI-related phases: embeddings and pgvector, the late-2024 wave of vibe-coding products such as Lovable and Bolt, and the more recent improvement in models that caused sign-ups, activation, and paid conversion to rise sharply. The founders say they spend little on traditional marketing and benefit from open-source users, blog posts, videos, podcasts, and community content that models can absorb.
Community ownership, Control Tower, and a product-led enterprise strategy
Supabase plans to give roughly $1 million worth of company stock to notable community members rather than run the originally planned crowdfunding round. The founders say lawyers told them there was no practical way to include the desired number of people as investors, but discovered that the company could give stock away directly. The first announced recipient is Gary Austin, a retired community member who has answered around 20,000 questions in the Supabase Discord over six years, including 13,000 within the first hour. The founders describe him as a genuine user who built a wine-related app and even displays the Supabase logo on his Christmas tree. They acknowledge that Discord is useful but difficult to turn into publicly searchable, scalable knowledge. Supabase has mirrored questions and answers into GitHub Discussions and used GitHub as a content-management system, because users repeatedly ask the same questions across Discord, Reddit, and other channels. For enterprises, the company is launching Control Tower, a product for monitoring and administering fleets of Supabase databases. It repackages capabilities already developed for AI companies and other platform providers that launch millions of databases. The founders say their enterprise strategy remains product-led: identify product triggers such as usage growth, errors, or spending, then contact customers with practical help rather than simply trying to sell them more. A control cohort grows about 25% month over month, while customers who respond to this help grow about 125%, producing a claimed 100% incremental uplift attributable to the sales effort.
Supabase prefers greenfield enterprise workloads to risky migrations
The founders say Supabase has intentionally avoided making database migrations its central enterprise strategy. They believe migrating a production OLTP database is far harder than it sounds because the database often powers a company’s revenue-generating application. Even a minute of downtime can cost money, and running old and new systems in parallel creates a dangerous split-brain synchronization problem. Instead, Supabase tries to land inside an enterprise with a new, greenfield workload and expand from there. Its historical thesis was that companies rarely migrate an existing database merely because a new database is bigger or better; the more reliable route is to win the developer on day one and remain present through day 1,000 or day 10,000. Multigres could eventually help with customers facing serious Postgres-scale problems, but the founders expect greenfield use cases to dominate their enterprise effort for at least the next five years. They also say AI has changed the buyer mix. Supabase originally relied on developers becoming internal champions, but chief product officers who have not coded in years are now building internal tools with products such as Lovable and Supabase. The host asks whether the C-level builder will be more loyal to the agentic frontend or the backend provider; the founders answer that databases are harder to migrate and operate, making the backend potentially more durable, while still acknowledging that Lovable has done an excellent job preventing agents from making dangerous database choices such as disabling row-level security or storing image data directly in Postgres.
Declarative schemas, future agents, open source, and the company’s next bets
The founders say Supabase is moving from a dashboard-first product toward a code-first, Git-native workflow. The Supabase CLI can represent an instance as a local folder containing functions and database definitions, and the company is releasing a declarative representation of the full Postgres schema. Instead of forcing an agent to reconstruct the current database by reading hundreds or thousands of historical migration files, the agent can inspect the desired state directly. Supabase’s PG Delta library will support this approach with Postgres generally, while Supabase-specific mechanisms connect it to the platform. They expect development to move toward personal agents that can create and deploy applications from a phone or another personal device. The founders worry that casual builders may converge on whatever implementation the models recommend, but the host argues that highly skilled developers will continue to experiment and push alternative approaches. On open source, they predict consolidation: many projects may eventually be rewritten in Rust or another efficient language, leaving a smaller number of dominant implementations. They would support large-scale rewrites where they improve safety and correctness, but do not expect every dependency to be rewritten repeatedly. The company’s immediate priorities are partnering with frontier AI labs, continuing its product-led growth, scaling to billions of database launches, and serving enterprise greenfield workloads. Supabase is globally remote, has about 450 employees, around 50 open roles, and lets teams choose their own AI-coding practices. The founders say the company spends roughly $300,000 per month on AI tools, but argue that the important measure is not token spending; it is how many complete processes become faster or no longer require a human in the loop.
Show notes
AI agents are creating more software—and that changes what a backend needs to do. Supabase co-founders Paul Copplestone and Ant Wilson join swyx to discuss running long-lived workloads alongside the database, making schemas easier for agents to underst...
Follow this show on AudioBrevity and new episodes get summarized for you. Create a free account