Supabase Not a Scaling Bottleneck

This shows Supabase was not the scaling bottleneck, because the hard problems sat in stateless compute and external services, not in the system of record. In this stack, document processing and third-party LLM calls create bursty workloads, retries, timeouts, and queueing problems, while Supabase kept handling auth, storage, and customer data. The company also says it had no schema issues, used row-level security for tenant isolation, and expects a move to self-hosting for specific government customers without replacing the stack.

• The concrete pain points were microservices orchestration, document processing, and external LLM calls. That usually means jobs that spike CPU, wait on outside APIs, or fail unpredictably, which is a very different class of problem from a database hitting limits.
  1 sacra
• Supabase was deeply embedded, not a side tool. It powered auth, PostgreSQL, storage, local dev instances, staging, backups, and production. That matters because if the team hit scaling pain everywhere except Supabase, the platform was already carrying the core data path under real load.
  1 sacra 2 sacra
• The contrast with other interviews is useful. In higher control environments like healthtech, teams avoided Supabase before launch because they wanted full ownership from day one. In this public sector case, the managed setup met requirements and the open source base preserved an eventual self-hosting escape hatch.
  1 sacra 3 sacra 4 sacra

The next phase is likely a split architecture where compute becomes more specialized and customer specific deployments increase, while Supabase stays the default data layer for most environments. If that pattern holds, Supabase becomes harder to displace over time, because the team will keep rebuilding volatile service layers around a database and auth foundation that has already proven stable.