Why Agents Choose Supabase—and What Database Infrastructure Still Has to Solve

1. Guest Background

Paul Copplestone and Ant Wilson are the founders of Supabase, described in the supplied guest background as a fully remote, open-source company offering hosted Postgres and related development services. Their relevant experience in this conversation is practical: building a database platform, responding to developer needs, and trying to support applications as they grow beyond their initial prototypes. The interview draws on that operating perspective rather than presenting an independent survey of the database market.

In this approximately 77-minute Latent Space episode, hosted by Alessio Fanelli and Shawn swyx Wang, the subject extends well beyond a new agent integration. The discussion connects development interfaces, compute, database architecture, community distribution, enterprise adoption, and Supabase's own use of AI.

The founders also explain their working relationship. They lived with other technical builders in a Singapore entrepreneurial setting and later hired several former housemates. They describe disagreements as opportunities to try the other person's suggestion, supported by a division of responsibilities. Their argument is that developers building developer tools already possess relevant domain knowledge.

There is an important relationship disclosure: the introduction identifies the host as a seed investor and describes sponsorship ties involving AI Engineer and Latent Space. Performance figures and business outcomes below therefore remain attributed interview claims. The episode offers unusually close access to the founders' reasoning, accompanied by an explicitly disclosed financial and professional connection.

2. What the Episode Covers

The product story begins with work that does not fit comfortably inside a short function invocation. The founders describe community demand for chunking, embedding generation, and agents, contrasting it with an earlier functions constraint they characterize as approximately two seconds. Supabase Compute is presented as a full container environment supporting languages including Rust and Python, running on the database's private network with direct Postgres connections. Colocation and fewer execution constraints are the proposed benefits.

The host pairs that compute layer with a less visible requirement: making infrastructure understandable. Lighter startup, declarative schemas, logs, checks, connection details, SQL documentation, and skills all contribute. The founders' code-first, Git-native direction makes files represent database state. Their example is an agent asked to understand a table after roughly a thousand migrations: it must reconstruct history or start a database and inspect it. Declarative files and the discussed pgdelt library aim to shorten that route, with expanded schema coverage presented as a conference announcement.

The database announcements address three different pressures. OrioleDB targets single-database performance. The founders claim compatible replacement of Postgres Heap, approximately 1.5–2 times performance, and removal of vacuum and bloat-related work. They describe compatibility and fault-testing efforts, a full beta, and an Apache 2 license covering the patent. Multigres addresses cluster management. The founders say their operator evaluations exposed conditional data-loss risks and report that their rewrite survived 1,000 sequential failovers without losing data. Hosted access is initially by invitation. Transparent sharding remains unreleased, with unchanged queries and application code as the compatibility objective.

Instance count is the third pressure. The founders report approximately five million database launches per month and anticipate billions. They announce the Turso acquisition, retaining its SQLite focus while planning smaller Spark instances compatible with Supabase libraries. The intended progression runs from a small database to full Postgres and eventually Multigres. They call zero-downtime movement between backends necessary, without demonstrating that the complete path is finished. Teacher-founded Magic School illustrates the nontechnical builders they want to serve; compute-capacity pressure explains why assigning every experiment a conventional dedicated cluster is unattractive.

Object storage enters as an architectural option for those many small databases. The speakers cite S3 Express writes of approximately 1–2 milliseconds and discuss moving data into cheaper storage afterward, while rejecting it as a Redis replacement. Distribution has produced capacity shocks before: the founders recall growing from roughly eight to 800 users after adopting the open-source Firebase alternative positioning and receiving outside Hacker News exposure, then exhausting cloud credits and migrating databases to AWS. They describe subsequent AI demand in three chapters—embeddings, late-2024 vibe coding, and improving models—which helps explain their simultaneous investment in small prototypes and larger workloads.

3. Core Views: Reasoning, Examples, and Limits

The strongest architectural argument is that agent usability spans understanding, execution, and diagnosis. Declarative state tells a tool what exists; Compute gives longer tasks somewhere to run; operational context helps it interpret what happened. These are complementary capabilities. A readable schema cannot compensate for an unsuitable execution environment, and successful execution cannot compensate for missing failure information. The host's observation that humans benefit too makes this a broader developer-experience argument. Its practical limits still depend on which announced capabilities are actually available in a given environment.

The scale discussion is useful because it resists treating every bottleneck as the same problem. OrioleDB concerns efficiency within a database. Multigres concerns managing and eventually distributing a larger workload. Turso and Spark concern the cost and mechanics of enormous numbers of small databases. Faster execution in one database does not automatically make billions of isolated instances economical. Conversely, a file-and-object-storage architecture suited to small instances does not establish suitability for demanding transactional workloads. The speakers' distinction between durability and availability, and their refusal to equate S3 Express with Redis, preserve that workload-specific reasoning.

The evidence supports examining these directions, not treating every promise as settled. A reported thousand successful failovers describes a test result; it does not establish safety under every fault combination. The OrioleDB testing program indicates validation effort, but the supplied material does not independently establish its performance multiplier for a reader's workload. Multigres sharding compatibility is explicitly a goal for an unreleased capability. The proposed Spark upgrade ladder similarly remains a plan rather than a completed migration demonstration. Acquisition, testing, beta availability, and production guarantees belong to different evidentiary categories.

On distribution, the episode suggests that community work can acquire a second life through models. The host says his AEO tracker finds frontier models recommending Supabase as an integrated backend. The founders speculate that accumulated tutorials, videos, podcasts, and open-source material helped establish that position. This is a plausible mechanism, but the interview does not identify training-data inclusion or isolate the effects of content, product quality, and brand familiarity. A more concrete mechanism is the team's practice of putting useful answers into GitHub Discussions and mirroring them on the website. Repeated questions can then reuse previous work. The founders' account of Gary Abbott answering approximately 20,000 questions, alongside a roughly $1 million community stock allocation, underscores the organizational value they attach to that contribution; the quantities remain their account.

Enterprise adoption reveals why being recommended is different from replacing an incumbent. The founders prioritize new projects and subsequent expansion. Control Tower repackages platform fleet-management capabilities for enterprises, while renewed coding by CPOs creates potential internal champions. Yet Supabase deliberately avoids tracking open-source deployments, so this discussion cannot establish a complete installation footprint. Nor does enthusiasm for a new internal application imply willingness to switch a revenue-critical production database.

The migration argument explains that gap. According to the founders, OLTP migration involves downtime, parallel systems, split brain, and reconciliation. Easier code rewriting addresses only part of that burden. Agent behavior introduces another boundary: early tools reportedly inserted image data into Postgres or disabled RLS to make projects work. The founders credit Lovable's skills with improvements. A functioning interface is therefore an incomplete success criterion when the route to functionality can undermine the database's intended constraints.

The growth claims require similar discipline. The founders attribute almost complete signup-to-activation to agents performing setup and report improved paid conversion, but provide no full cohort definitions or measurement windows. Their sales example is more detailed: nonresponders reportedly grow around 25% monthly, while customers accepting help grow around 125%, with compensation linked to the attributed difference. Responding is itself a selection mechanism. Those users may already have greater urgency or expansion potential. The transferable idea is helping customers around observable product problems; the interview does not establish the entire growth difference as a causal sales effect.

4. Learning and Application

A team building an agent development environment can begin with a representative task rather than a generic chat interface. Ask the tool to change a database policy and run an embedding job. Supply current schema, relevant constraints, an execution path, and failure information. Observe whether it reconstructs unnecessary history, guesses connection details, or bypasses security to reach a visible result. The acceptance condition should include preserving intended constraints. Declarative files also need comparison with the running database so that readable state does not become misleading state.

Infrastructure evaluation should begin by identifying the bottleneck: one database's efficiency, cluster management, or the number of small instances. Then match the validation to the claim. Test performance against the intended workload, inspect the fault conditions behind failover results, and confirm availability before depending on transparent sharding or a Spark upgrade path. Analytics deserves a separate workload decision. The founders favor technologies such as DuckDB and DuckLake and sharding for very large OLTP; this is their architectural preference, not evidence that every HTAP approach fails. The host explicitly qualifies his understanding of Databricks. Likewise, long-running compute is a prerequisite that opens workflow possibilities, not proof of a complete durable-workflow product.

Enterprise teams should evaluate a new internal application separately from migration of a core transaction system. The latter needs explicit decisions about downtime, authority during parallel operation, cutover, and reconciliation. Splitting off new workloads may reduce the initial migration burden while creating a longer-lived obligation to operate two systems. Sales teams can use product signals to identify problems worth solving, but should assess assistance against prior growth and differences in customer responsiveness before attributing an observed uplift to intervention.

Community teams can turn recurring, suitable questions into maintained public answers. That offers a direct knowledge-reuse benefit; any effect on model recommendations requires separate observation. Dependency strategy deserves an equally deliberate approach. The founders describe hiring Steve Chaves to keep developing a critical upstream project and funding additional contributors. The supplied transcript inconsistently names that project, so its identity should remain unresolved here. The applicable principle is investing in the maintenance capability behind a dependency rather than assuming its code can simply be replaced.

For AI-assisted rewrites, define the component boundary, test coverage, and runtime requirements first. The discussion of Elixir's BEAM illustrates why changing languages can also change operational mechanisms. Predicted convergence on Rust does not by itself justify migration. Internal AI budgeting needs similar restraint: the founders' approximately $300,000 monthly spending and corrected 450-person headcount describe one company's situation, alongside team autonomy and some cost consolidation, rather than a universal spending benchmark.

A more useful evaluation follows a documented process and measures end-to-end completion, human intervention, elapsed time, and cost together. Supabase's effort to build an organizational harness from asynchronous records is an example of that direction, without reported productivity results. Historical decisions should retain their conditions so that old reasoning is not applied indiscriminately. Finally, automation plans still need operational ownership. The founders stress fit for fully asynchronous work in SRE hiring, and agree with the host that AI had not solved continuous system operation. Faster application creation increases the value of deciding who will keep the resulting system running.

Source

• Original episode: Why Agents Love Supabase — with Paul Copplestone and Ant Wilson