Scaling to Billions: The Hidden Architecture of AI-Native Backends

In this conversation, Supabase co-founders Paul Copplestone and Ant Wilson discuss the move from developer-centric tools to the Agentic Database era. Their core idea is that AI agents are changing backend infrastructure requirements, shifting from dashboards designed for humans to declarative states optimized for machines. This shift will lead to a massive increase in the number of databases, growing from millions to billions per month. The competitive advantage over the next decade will not go to those who build the most complex features, but to those who provide stable, zero-migration pathways for non-technical builders. This is important for technical leaders who need to tell the difference between temporary trends and the structural changes that will define the next generation of software architecture.

The Hidden Cost of Fast Solutions

Most teams scale databases by adding complexity like caching layers, custom operators, or distributed workarounds. Copplestone and Wilson argue this is often a trap. After testing existing Postgres operators, they found that nearly every standard solution could lose data under specific failure conditions. Their response was to rewrite their operator, Multigress, from the ground up, prioritizing stability over speed.

> We looked at the Postgres ecosystem and we looked at all the operators... what we had found was that under certain conditions, every single one of them could lose data.
>
> -- Ant Wilson

The systems-thinking takeaway is clear: immediate fixes for scaling often introduce hidden, compounding risks. By building a new foundation instead of patching existing ones, Supabase created a moat that competitors cannot easily bridge. This is the classic slow-to-fast dynamic where time spent on foundational stability creates a durable advantage that pays off when the system is under heavy load.

Why the Obvious Fix Makes Things Worse

Conventional wisdom says that as you scale, you must move to specialized databases, such as moving from Postgres to an analytical warehouse. The founders challenge this, noting that the common solution of combining OLTP and analytics rarely works. Instead, they emphasize that sharding is the most viable path to petabyte-scale, while analytics should remain a separate concern.

The result of trying to force a single database to do everything is a loss of performance and operational predictability. The system eventually routes around your solution, creating bottlenecks that are harder to fix than the original problem. Their strategy is to provide a zero-downtime migration path, recognizing that the biggest barrier to adoption is not the code, but the risk of migrating revenue-generating workloads.

The 18-Month Payoff of Declarative Infrastructure

The most non-obvious insight involves how AI agents interact with code. Most teams treat migration files as a historical log. However, for an agent to truly understand a system, it needs a declarative state, which is a map of the entire database schema that does not require recompiling through thousands of migration files.

> Imagine putting an agent across 1000 files and telling asking, oh what is the shape of this table? It has to guess through a thousand files. So it is a recompile.
>
> -- Paul Copplestone

This shift from imperative migrations to declarative schemas is a structural change that optimizes for machine-readability. It is an investment that offers no immediate benefit to human developers, but creates a massive advantage for agentic workflows. By making the infrastructure agent-native, they are positioning themselves as the default backend for the next generation of AI-built applications.

Key Action Items

• Audit your scaling dependencies: Over the next quarter, evaluate whether your current database operators or caching layers have been stress-tested against data loss, not just performance. If they have not, assume they are a hidden liability.
• Shift to Declarative Schemas: Begin transitioning your database management from a series of historical migration files to a single, declarative state representation. This is a 12-18 month investment that will pay off as your reliance on AI-assisted coding increases.
• Adopt Product-Led Sales Triggers: Instead of cold outreach, identify specific pain triggers in your user traffic, such as hitting rate limits or specific error patterns. Use these to initiate high-touch interventions; the founders saw a 100% incremental uplift in account growth by focusing on these moments of friction.
• Establish an AI-Spend Ratio: Monitor your token-to-human-salary spend. The founders suggest that a ratio of 0.1 to 1 is safe, but exceeding 1.5 may indicate inefficient usage or a lack of focus on end-to-end process automation.
• Build for the Greenfield Enterprise: Focus your enterprise efforts on winning new, day-one workloads rather than attempting to migrate existing legacy systems. Migrations are a high-risk, low-reward trap; winning the next project is where the growth lies.