Supabase credibility gap at scale

This is the line where Supabase shifts from being a labor saver to being judged like infrastructure. Branching and the CLI help because they give professional teams safer schema changes, local testing, and cleaner handoffs between app engineers and platform engineers. But they mostly improve developer workflow, not the core concerns that make infra teams hesitate at larger scale, like replica topology, service boundaries, failure modes, and how much of the stack can be tuned or owned directly.

• Supabase branches are real isolated environments with their own database, API endpoints, auth settings, storage buckets, and edge functions. That makes them useful for serious team workflows, especially staging and preview environments, because schema changes can be tested without touching production.
  2 supabase 3 supabase
• The CLI gives teams a more standard infra style loop, run the stack locally, generate migrations with db diff, test, and ship through Git. That narrows the credibility gap for teams that want reproducibility and code review, but it still sits on top of Supabase operating the production control plane.
  3 supabase 4 supabase
• The bigger gap shows up in production scale behavior. Supabase offers read replicas and geo routing for database reads, but Auth, Storage, and Realtime do not independently run on replica endpoints in the same way. That means the platform remains a bundled service, while infra teams often want each piece managed and scaled with more direct control.
  5 supabase 6 sacra 7 sacra

The likely path is that Supabase keeps winning the period from first prototype through early scale, then has to earn its way into larger accounts by looking more like configurable infrastructure and less like a black box backend. Branching and local dev are important steps because they train teams into disciplined workflows before the handoff to full platform scrutiny arrives.