Supabase's Silent Defaults Caused Four Production Incidents
Four Supabase incidents in one week trace to one cause: silent wrong data, no errors. Three concrete rules to prevent it follow.
Looking at four Supabase incidents that hit within a single week, one shared failure mode emerges: the database returns HTTP 200 with silently wrong or incomplete data, never raising an exception. The first case stemmed from a SQL function missing an explicit REVOKE, leaving it callable by anonymous users by default; the second from an ON DELETE SET NULL cascade colliding with a CHECK NOT NULL constraint, producing a misleading error; the third from RLS policies referencing each other in a loop that froze live sessions; and the fourth — previously covered in isolation — from a query missing .order(), which quietly hit PostgREST's default 1000-row cap and fell back to ctid ordering. In every case, unit tests passed and code review missed the issue, because the bug lived in volume, auth context, or table history rather than in logic.
The author frames this pattern as structural rather than coincidental: undeclared vendor defaults act like frozen, invisible contracts baked into production behavior without appearing anywhere in the codebase. The proposed remedy is threefold: explicitly document every undocumented default in an ADR or rule file, or block the risky pattern with a hard guard (ESLint rule, SQL CHECK, pre-commit hook); replace manual code review with AST-based static analysis for patterns that recur at scale; and run daily production probes to detect drift, since none of these defects would ever surface in test environments. A further point stresses verifying vendor defaults against official documentation rather than trusting an AI agent's answer.
Overall, the piece serves as a concrete warning for engineers building on Supabase/PostgREST: platform defaults are invisible in review, silent in tests, yet capable of causing serious data-integrity and security failures in production.