Supabase's Multigres and OrioleDB strategy

Supabase is moving from being a convenient Postgres wrapper to owning the hard parts of running Postgres at scale. Multigres tackles the control plane problem, meaning how to keep many database nodes pooled, failed over, and eventually sharded without operators stitching tools together. OrioleDB tackles the storage engine problem inside Postgres itself, reducing table bloat and write overhead while keeping the same SQL surface for developers.1 2 3 4

• Multigres is the operational path. Supabase describes it as an operating system for Postgres that manages sharding, connection pooling, automatic failover, and backup orchestration. That is the layer teams normally piece together with PgBouncer, replicas, failover tooling, and manual runbooks.1 3 5
• OrioleDB is the engine path. Instead of fixing scaling around standard Postgres, it changes how data is stored so old row versions move to undo logs rather than bloating main tables. Supabase says projects keep the same SQL, connection string, Auth, and Row Level Security, which makes it a drop in performance upgrade if it matures.2 4
• The pairing matters because Supabase is selling into AI generated apps and larger production workloads at the same time. Its own research tracks ARR rising from $30.4M at the end of 2024 to $170M by May 2026, while customer interviews still point to a ready at scale credibility gap. Infrastructure ownership is how Supabase closes that gap against Neon and PlanetScale.6 7 8 9

The next step is a Supabase stack where developers start with easy hosted Postgres, then stay as workloads get hotter and more complex instead of graduating to a different database platform. If Multigres delivers Vitess style horizontal scale for Postgres and OrioleDB becomes production safe, Supabase can turn infrastructure depth into retention and bigger enterprise contracts.1 2 3 8