AI Exposes Supabase Audit Weakness

The hardest part to audit in Supabase is not one isolated feature, it is that critical logic gets split across the database, the dashboard, and the app, which makes the whole system harder to inspect as one coherent codebase. In this interview, the concrete pain points are Postgres functions and RLS policies, plus schema design itself, plus weaker infrastructure as code, plus less ability to share TypeScript packages and types across front end and back end. That is the basis for the PHP comparison, a stack that tends to accumulate hidden logic and cleanup work over time.

• The interview answers the question directly. The toughest pieces are logic tucked into Postgres functions and RLS policies, database structure decisions, and a setup where front end and back end live separately, so a reviewer cannot open one repository and trace the full system cleanly.
  1 sacra
• The Firebase comparison is really a repository shape comparison. The preference is for a codebase where security rules, tests, linting, CI, and infrastructure definitions are visible together, and where TypeScript code, shared types, and business logic can move across client and server without crossing a database boundary.
  1 sacra
• This fits the broader split in backend tools. Supabase sells an integrated Postgres based backend, while Firebase historically won by giving developers drop in backend services with simpler app level workflows. As AI writes more of the application, reviewability and code organization become more important than raw setup speed.
  2 sacra 3 sacra

Going forward, the winning backend products for AI built apps will be the ones that keep security, schema, tests, and deployment definitions legible in one place. That favors stacks that are easy for a CTO to review repository first. Supabase can keep growing with non developers, but its biggest pressure point is making its hidden database layer easier to audit like normal application code.