Enterprise databases almost never migrate: greenfield customers are the real battleground
Supabase's internal data shows enterprises almost never move production databases, which shapes their growth strategy to capture greenfield projects rather than attack incumbent vendors' existing customers.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
Declarative schema is the last lesson Postgres owes
Supabase treats declarative schema as the most important step in its build mandate—traditional Postgres follows a ‘schema first, then constant migration’ pattern, but agents need a single file in Git showing ‘what the database looks like right now’. The episode notes this seems simple, but Postgres was designed 40 years ago and never optimized for it. Supabase is now completing this final-mile adaptation, and the benefit isn't just for agents—humans gain equally.
— swyxEvery Postgres ops tool loses data under specific conditions
Supabase tested nearly every operator in the Postgres ecosystem—software that manages clusters, failover, and backups—and found each one loses data under specific conditions. So they rewrote the operator layer from scratch: Multigress. The priority wasn't sharding; it was complete compatibility with native Postgres, so not a single query needs to change. They've run 1,000 consecutive failover tests with zero data loss, and sharding is expected early next year.
From 5 million databases a month to billions
Supabase currently launches roughly 5 million databases per month, but the founder projects future scale must reach billions monthly—a completely different order of magnitude. They acquired Turso not for the SQLite technology itself but for its architecture redesigned around object storage: 11 nines of durability as the foundation, SQLite as the file format, making it possible to launch billions of small databases.
One deal convinced them vibe coding is real
Early on, they were skeptical about the vibe coding wave until they saw someone earn $10,000 from Stripe within days of launching a product. That convinced the team it wasn't a toy but something that would stick. So they decided to support both ends: early-stage prototypes and scaled customer operations. This led to evolving from ‘build in a weekend, scale to millions’ to ‘prototype to petabyte’.
Sales commissions are based only on incremental growth versus control group
Supabase sales doesn't work like traditional phone sales. They use AI to screen thousands of product signals—like customers approaching usage limits or seeing more errors—then dispatch sales reps only to those who respond, using non-responders as a control group. The control group experiences 25% natural growth; sales-contacted customers grow 125%. Sales earn commissions only on the 100% incremental growth—making true value creation visible instead of crediting natural expansion.
Enterprise customers almost never migrate databases
The founder is direct: even with a bigger, more scalable Postgres, it's nearly impossible to convince enterprises to move production databases. This lesson is validated across every database company they've studied. So all enterprise effort focuses on day-one wins, not converting incumbents: capture greenfield projects, not expecting Oracle-scale customers to migrate wholesale. This judgment will determine strategy for at least the next five years.
Agents can now read Postgres as a single snapshot file
Traditionally Postgres tracked changes via migration files. To know what a table looks like now, an agent had to parse thousands of files or spin up the database to introspect—too slow. Supabase's pgdelta release turns tables, policies, and comments into a declarative schema folder as a ‘current state’ snapshot. Agents just read the file to see the database's true shape right now—no recompilation, no step-by-step migration.
Token spending above 1.5× payroll is a warning sign
The founder offers a portable benchmark: divide monthly AI spending by total payroll to get a ratio. Most companies sit around 0.1; climbing to 1 is still healthy; above 1.5 suggests waste rather than labor savings. Supabase spends roughly $300,000 per month on AI with a 450-person team. They care less about money saved than about how many previously human-supervised processes are now fully automated.
In their own words · checked verbatim
what we had found was that under, um, certain conditions, every single one of them could lose data.
So then they built this Turso architecture, which basically builds MVCC for SQLite so that you can have multiple writers.
it turns out just getting on a call and helping people out, their account then grows a hundred and twenty-five percent. So that a hundred percent uplift, the incremental uplift, is what we compensate our salespeople.
I guarantee they'll almost never migrate.
I think it was like one year ago, someone said that only five percent of Oracle workloads by revenue ran in the cloud.
there's, like, layers upon which you want to get to where things will be rewritten, and then you don't wanna be spending your actual innovation tokens or your actual tokens rewriting everything.
you can probably go up to one pretty safely, and if you're over 1.5, you're probably in trouble.
Figures
| OrioleDB performance improvement | 1.5–2× faster than existing Postgres storage engine | 7:26 |
| Multigress failover test | 1,000 consecutive failovers with zero data loss | 9:27 |
| Current monthly new databases | Approximately 5 million | 12:44 |
| ChatGPT monthly active users | 1.2 billion | 55:58 |
| Oracle cloud workload share by revenue (approximately one year ago) | 5% | 48:19 |
| Supabase monthly AI spending (450-person team) | Approximately $300,000 | 1:12:16 |
| Healthy token spending to payroll ratio | Typically around 0.1; above 1.5 is a danger signal | 1:12:16 |
Glossary
- AEO
- Answer engine optimization—optimizing content so AI language models recommend it when answering user questions
- Vitess
- MySQL sharding middleware used by YouTube and GitHub; Multigress is its Postgres counterpart
- Multigress
- Supabase's from-scratch rewrite of the cluster and sharding operating system for Postgres
- Declarative schema
- Describing a database's structure directly in a file rather than deriving it from a sequence of migration scripts
- MVCC
- Multiversion concurrency control—allows multiple writers to operate on the same data simultaneously without blocking each other
How to listen
Founders, investors, and engineers interested in AI-native backend infrastructure, enterprise database migration strategy, and how to establish AI spending baselines for their teams.
The opening 0:00–5:20 is the host's personal introduction and show announcements; the formal interview recaps this content, so you can skip it.