Key Takeaways

  • Supabase launches 5 million databases every month, but anticipates needing to launch billions per month to support automated agents.
  • Running a dedicated Postgres cluster for every automated agent run is physically impossible; hardware constraints will exhaust global server capacity.
  • Supabase acquired Turso, keeping it as an independent SQLite-focused brand to solve lightweight horizontal scale.
  • Turso's core technical advantage is building multi-version concurrency control (MVCC) on top of SQLite, allowing multiple writers on what is historically a single-writer file format.
  • Supabase is launching Supabase Spark, a micro-instance tier that lets builders run ideas on SQLite and cleanly upgrade to Postgres and Multigres as they grow.

Physical Hardware Limits Kill Dedicated Postgres Clusters

Most software engineers treat cloud compute as infinite. If an autonomous agent needs to test an idea, spin up an isolated staging database, run queries, and tear it down, developers usually treat it as a routine API call.

Paul Copplestone saw the ceiling coming. Supabase grew to a $10B valuation by making Postgres as easy to use as Firebase, provisioning millions of production databases. But when autonomous agents start creating databases dynamically, the math collapses.

“At the moment we launch about 5 million databases on our platform every single month,” Copplestone said. “And kind of the future where we know we're going, we think that we're going to have to launch billions per month. And so scaling out is a whole different beast.”

If every temporary agent task demands its own dedicated Postgres container, the cloud runs out of iron. “If we give everyone a dedicated Postgres cluster, we'll probably run out of physical computers in the world pretty fast, which is basically what's happening,” Copplestone observed. Dedicated relational databases carry connection overhead, fixed memory reservations, and idle compute tax. They are built to stay up for years, not seconds.

SQLite with Multi-Version Concurrency Control

To survive agentic architectures, the underlying storage engine must scale down to zero cost when idle and launch in milliseconds. SQLite fits that profile because it is an embedded file format rather than a heavyweight daemon. But plain SQLite brings its own wall: it locks the entire file on writes.

“SQLite itself is only a single writer. It's a file format,” Copplestone said. “So then they built this Turso architecture which basically builds MVCC for SQLite so that you can have multiple writers.”

By adding multi-version concurrency control and running on top of object storage, Turso created a model where millions of isolated, multi-writer databases can coexist on shared storage without reserving dedicated servers. Instead of forcing Postgres to do something it was never designed to do, Supabase bought Turso to power that layer directly.

Under the deal, Turso remains an independent brand dedicated to SQLite. Meanwhile, Supabase integrates the engine into a new entry tier called Supabase Spark. Builders get a database that works out of the box with existing Supabase client libraries, cost nothing at zero traffic, and provide a clear migration path. When an experiment gets traction, the founder can upgrade the workload to standard Postgres or Multigres without rewriting application logic.

What to Do With This

Audit your application today for any place where your backend spins up an isolated database or schema for ephemeral agent tasks, user sandboxes, or tenant tests. If you are provisioning dedicated relational instances for tasks that run for less than an hour, switch those workloads to an embedded SQLite architecture or wait for the Supabase Spark rollout. Stop treating dedicated Postgres clusters as disposable scratchpads.