Supabase credibility gap: debugging and control
Founding engineer at healthtech startup on Supabase's ready-at-scale credibility gap
The real issue is not whether Supabase breaks at scale, it is whether engineers can still see and control enough of the system when something subtle goes wrong. In the evidence here, the credibility gap is mostly about debugging posture, migration risk, and architectural trust. Teams that expect complex workflows, strict controls, or custom infrastructure often prefer raw Postgres, Aurora, or containerized stacks because more of the moving parts stay visible and directly editable.
-
The healthtech engineer is explicit that this is architectural intuition, not observed failure. They never ran a Supabase proof of concept, but expected abstraction layers like managed auth, policies, and bundled services to hide the exact levers needed during production incidents or no downtime migrations.
-
A second interview sharpens the same point in practice. The CTO argues Supabase projects are harder to audit because security rules, database logic, and infrastructure are spread across places that are less visible in one Git based workflow, which becomes a problem when reviewing code, testing changes, or cleaning up AI generated systems.
-
The counterweight is that some teams are already running core workloads on Supabase without hitting that ceiling. The public sector startup uses Supabase for database, auth, and storage, says scaling issues came from other microservices, not the database, and expects migration away to take months because the platform is deeply embedded.
Going forward, the dividing line will be less about raw scale and more about who values packaged speed versus low level control. Supabase can keep winning where fast setup and integrated workflows matter most. The harder enterprise push depends on proving that teams can debug, audit, and gradually unbundle the stack without losing that speed.