Evidence at a glance
The Problem Is Where Backend State Lives
In an interview published on October 28, 2026, Supabase co-founders Paul Copplestone and Ant Wilson discussed why coding agents often use Supabase and how backend infrastructure might adapt to agent-built applications. Supabase is a backend platform centered on Postgres. The question is not merely whether a model can write SQL, but whether an agent can take an application from code to something that runs and can be maintained.
In the older workflow, an agent might work mostly in a repository while backend configuration remained in a dashboard: creating tables, adjusting RLS policies, then using the CLI to turn those changes into migrations. Code and deployed backend state could drift apart, leaving the agent unable to infer the system's current shape from the repository alone. Supabase's direction is an attempt to make that hidden state visible within ordinary software development work.
Put the Desired State in the Repository
Supabase is moving toward describing the desired database schema in SQL files and keeping project settings in config.toml. An agent can inspect and edit these files alongside application code; pg-delta then compares the desired state with migration history and generates SQL migrations. The point is not to make an agent better at hand-writing migration scripts. It is to let the agent state the target structure first, then use a tool to translate that target into change steps.
This shifts where backend changes can be reviewed. Engineers need not reconstruct the current database solely from a chain of historical migrations, and an agent can propose schema edits in the same repository as the application. But a declarative description does not make every migration safe: Supabase's documentation warns that a column rename may be interpreted as dropping the old column and adding a new one. pg-delta also does not handle ordinary table-data changes or orchestrate zero-downtime production releases, so risky changes still need human review and deployment planning.
The Environment and Runtime Matter Too
A repository the agent can read is only the first step. Local dependencies and setup become more costly when an agent repeatedly creates and tests environments than when a human developer sets one up occasionally. Supabase's new local runtime can run without a Docker daemon and supports multiple local instances in separate directories, allowing different branches to be tested independently. At launch, however, it was still alpha and disabled by default, so it should not be treated as a generally available foundation.
An application also needs somewhere to do longer-running work. Supabase Compute is intended to provide a persistent runtime in the same project as the database for tasks such as agents and embeddings. It offers a full Linux environment and can be deployed through the CLI or Management API. The idea is to reduce the extra services, connections, and context an agent must handle, but Compute was in private alpha at launch. Edge functions remain useful, though they do not cover every long-running workload; the available material does not establish whether Compute is ready for production use.
An Agent Must Also Understand What Happened
Being able to issue SQL does not mean an agent understands what it changed, how the application uses the database, or where a failure occurred. Supabase presented its Operate capabilities alongside Build: agents can access project logs and inspect projects through database queries and notebooks, with permission controls. A user's own agent can also use an application's MCP server to access data authorized for that logged-in user. These features aim to close the context gap between making a change and diagnosing its effects.
That gap also points to a boundary for agent access to backends: capabilities should be tied to authorization, and diagnostic information must be sufficient to assess the result of an operation. The material describes permission controls and user identity as design directions, but does not provide a complete account of the permission model, auditing, or failure guarantees. Technical leaders should treat these as operational interfaces the platform is building, not as proof that agents already have safe, comprehensive production-operations capabilities.
Many Small Databases and a Few Large Ones Are Different Problems
A Supabase co-founder said in the interview that the company launches about five million databases per month. A separate figure in the company's October 2026 announcement of its Turso acquisition was more than one million per week. The figures are of a similar order, but public materials do not establish whether their definitions and time windows match, so they cannot be treated as a precise conversion. In June 2026, the company also reported 600% year-over-year growth in database launches and said more than 60% of newly launched databases were initiated by some kind of AI tool. These are company-reported figures, with no further detail on classification or measurement.
Those numbers help explain why agent-friendly infrastructure eventually becomes a scaling question, but the scaling work is not one problem: handling many newly created small databases differs from supporting a customer's database as it grows. Supabase's Scale announcements included OrioleDB, Multigres, and the Turso acquisition, while the interview placed reliability and scaling up or out under a prototype-to-petabyte narrative. The host's claim that frontier models almost uniformly preferred Supabase came from a personal tracker with no public sample or evaluation method, and cannot establish a general agent preference. A practical decision for teams is to use repository-based schemas to improve reviewability now, keep explicit human review for alpha features and hazardous migrations, and expand automation only as runtimes mature and metrics become clearer.