Supabase Bets on AI Agents: The Database Foundation for a Billion Apps

When AI agents start generating software at scale, what exactly does the backend need to become? Supabase co-founders Paul Copplestone and Ant Wilson discussed this topic with swyx on a podcast, covering how long-running tasks can work alongside the database, the changes made to make schemas easier for agents to understand, and their vision of "a billion AI-built apps."

AI Writes Software, and Backend Requirements Change With It

The starting point of this conversation is straightforward: AI agents are creating more software, and backend design goals can no longer revolve solely around human developers. In the past, backend optimization focused on request-response latency, connection counts, and storage costs. When agents become the primary producers of code, backends must also handle a large volume of automated, potentially long-running workloads—as well as the "comprehension cost" for machines to understand database structures.

The two founders framed this shift at the level of product planning. Supabase positions itself as an open-source Postgres backend platform, and its schemas, authentication, storage, and other components were built around developer experience from the start. With AI agents in the picture, the audience for developer experience expands from humans to two types of users: humans and agents.

Running Long-Running Tasks Alongside the Database

One key point of discussion was how to run long-running tasks alongside the database. In traditional backends, the database handles state while task execution is delegated to external queues or workers, and the connection between the two is often where engineering complexity concentrates. If apps generated by AI agents rely heavily on background tasks—such as data processing, batch generation, or continuous synchronization—then having these long-running workloads work more closely with the database becomes a natural product direction.

The two founders did not provide specific performance numbers or architectural parameters in the conversation, but based on their remarks, the idea is to have Supabase take on more "application runtime" responsibilities rather than serving only as a storage layer that gets called. This is especially important for AI-generated apps: code written by agents often needs ready-made infrastructure to fall back on, and reducing glue layers means fewer points of failure.

Long-running jobs typically refer to background workloads that execute for anywhere from seconds to hours or even longer, such as batch data imports, video transcoding, batch model inference, or periodic cross-system synchronization. In traditional architectures, such tasks are usually handled by dedicated message queues (e.g., RabbitMQ, Kafka) or task scheduling systems (e.g., Celery, Sidekiq), with the database only storing task states and results. The problem is that maintaining state consistency between the queue and the database requires additional code, and task retry on failure, idempotency, and progress tracking can easily become failure points. When apps generated by AI agents rely heavily on such background logic, embedding task execution capabilities directly near the database platform can reduce intermediate layers, allowing state and execution to share the same transaction and permission model—thereby lowering the complexity that agent-generated code needs to handle.

Making Schemas Friendlier to Agents

Another direction mentioned was making schemas easier for agents to understand. This deserves elaboration: a database schema is inherently machine-readable, but for large models, the way table structures, relationships, and constraints are organized directly determines the accuracy of the SQL they generate and the APIs they call. If schema design itself takes into account how agents read it, the trial-and-error cost of AI-generated apps drops significantly.

Behind this is a product judgment—the backend of the future is not just a console for humans, but also an interface for agents. Human developers read docs and examples, while agents infer intent through schemas and type definitions. Treating the latter as a first-class user could become a new dimension of differentiation for backend products.

A schema is a machine-readable description of database structure, including tables, columns, data types, primary and foreign key relationships, indexes, and constraints. For large language models, the schema is both the basis for generating SQL and the context for inferring business semantics. If schema naming is vague, relationships are missing, or constraints are incomplete, models are prone to generating incorrect join queries or omitting necessary fields. "Agent-friendly" usually means the schema has clear naming conventions, explicit foreign key relationships, complete type information, and necessary comments—exposed in formats that models can easily digest (such as compact DDL or structured JSON). This way, agents make fewer trial-and-error attempts when generating queries, calling APIs, or modifying table structures, and the accuracy of their output improves.

What the Billion-App Vision Means

The "billion AI-built apps" in the title is a visionary statement rather than a verifiable prediction. Its value lies in pointing to a direction: when the cost of producing apps is driven very low by AI, the number of apps may rise dramatically, and backend platforms need to remain usable at that scale.

For platforms like Supabase, the requirements are not just about scaling, but also automated operations, lower barriers to entry, and enabling agents to complete configuration and deployment on their own. The conversation did not elaborate on specific implementation paths, but incorporating "agents as users" into backend design is itself a signal worth watching.

Some Observations

The information density of this conversation is concentrated at the level of product philosophy, lacking architectural details and benchmark data, so it is better suited as directional reference rather than a basis for technical selection. What can be confirmed is that Supabase is treating AI agents as direct users of the backend, not merely external programs calling APIs. For teams building AI apps, this perspective is worth noting—the criteria for choosing a backend may need to expand from "is it easy for human developers to use" to "is it easy for agents to use."

One-line Summary

Supabase treats AI agents as direct backend users, exploring long-running tasks and schema friendliness.

Paragraph Summary

Supabase co-founders Paul Copplestone and Ant Wilson proposed on a podcast that AI agents are becoming the primary producers of software, and backend design needs to expand from serving only human developers to also serving machine users. The directions they discussed include: running long-running tasks alongside the database to reduce glue layers, transforming schemas to make them easier for agents to understand and thereby lowering the trial-and-error cost of generating SQL, and envisioning the challenge that "a billion AI-built apps" poses to backend platform usability. The conversation leans toward product philosophy and lacks architectural details and performance data, but it clearly signals treating agents as first-class users.