Supabase for Agents: Compute, Postgres and Developer Workflows

Latent Space host swyx interviews Supabase co-founders Paul Copplestone and Ant Wilson after the company’s 2026 Select announcements. He discloses that he invested in Supabase’s seed round and that the company sponsors the podcast, so the conversation has a financial relationship.

The founders present long-running Supabase Compute alongside the database. They describe running container workloads on the same private network as Postgres, extending beyond the earlier edge-function use case. These are product descriptions from the company.

They discuss OrioleDB, testing and a beta release under the Apache 2 license, as well as Multigres for managing and scaling Postgres. Their reliability claims reflect their own tests and should not be read as a guarantee that data loss is impossible.

The founders explain the Turso acquisition as part of preparing for large numbers of agent-driven databases. They contrast scaling a single database with distributing many databases and discuss SQLite’s single-writer model.

The conversation shifts to developer marketing and community. The founders describe using humor and public communication while building a distributed company.

They recount an early positioning change from “real-time Postgres” to an open-source Firebase alternative, followed by a sudden influx of users. That launch exposed infrastructure and migration problems that the team had to solve.

The founders describe vector support in Postgres as an early AI-related growth driver, followed by demand from AI application builders. They argue that recommendations by agents can influence which backend developers choose; the extent of that effect is a company and host interpretation.

On enterprise growth, they describe product-led sales based on signals such as usage, limits and errors. They discuss comparing contacted users with a nonresponding group; that comparison alone does not establish a randomized causal effect.

The conversation turns to live database migrations. Moving a transaction-processing workload without downtime is hard because writes must remain consistent, and a split-brain situation can make reconciliation difficult.

The founders discuss declarative schemas: a file representation of the desired database structure can give agents a more direct view than reconstructing the current state from a long migration history. Migration execution and review still matter.

They describe hiring contributors to work on Postgres itself and using the company’s asynchronous documentation as context for internal AI workflows. The discussion closes on measuring work completed rather than treating token spending as the goal.