Founding engineer leaves Supabase for Aurora

The real issue is not a single outage, it is the moment a startup realizes a core workflow can stop and the team has no direct lever to fix it. In this case, even a brief vendor outage was enough to trigger a move off another tool, because dependence itself was the risk. That is why managed database platforms can feel fine for side projects, but dangerous for healthtech teams that want direct control over uptime, data, and migration paths.

• The engineer had already chosen self hosted Aurora over Supabase in professional work for control, cost visibility, and data ownership. The later outage with a different vendor reinforced that instinct, because waiting on someone else to resolve a bottleneck was itself unacceptable.
  1 sacra
• What makes this stickier with Supabase is bundle depth. The same interview says leaving would be much harder if the vendor held the primary database, auth, and storage together. Dependence compounds when one service owns multiple critical paths.
  1 sacra
• This splits the market. Another company using Supabase as its core data layer accepts months of migration pain because the product works and the switching cost is high. A CTO in a separate interview instead pushes founders off Supabase quickly, often to Firebase, when auditability and repo level control matter more than convenience.
  2 sacra 3 sacra

The likely direction is a sharper divide. Supabase can keep winning where speed and all in one setup matter most. Teams in regulated or high control environments will keep preferring stacks they can run, inspect, and move on their own terms, even if that means more work up front.