Supabase Is a Vibe Coding Trap Image: AI generated

The 30-Second Magic

“Build me a backend.” The AI recommends Supabase. One URL and you have PostgreSQL, auth, storage, and realtime subscriptions. Login is running in 30 seconds. CRUD is done in 2 minutes.

Three months later, nobody knows who wrote those RLS (Row Level Security) policies.

Why AI Recommends It

Supabase became the default choice for vibe coding not because of technical superiority. It’s because tutorials dominate the training data.

Cursor, Bolt, v0, Lovable — type “build me a backend” into any AI coding tool and Supabase comes out. AI recommends the most frequently seen pattern. Not the best pattern.

Zhang et al. (ACL 2025) demonstrated that 7 LLMs systematically favor specific providers without explicit instruction, and autonomously modify input code to insert preferred providers. Users believe what AI recommends is the best option. AI recommends what appears most frequently in training data. This is the infrastructure version of sycophancy bias.

When You Hide Logic in a Black Box

Supabase’s real problem is not Supabase itself. The problem is business logic moving into a black box.

1. RLS Policies = Hidden Business Logic

Row Level Security is a powerful feature. The problem is: when AI generates RLS policies, where do they live?

  • Not in code. They’re in the Supabase dashboard.
  • Not in git. No version control.
  • Not in tests. No CI validation.

The answer to “who can access this table?” does not exist in the codebase. You have to log into the Supabase console to find out. Agents cannot read this.

If AI modifies RLS policies during a “cleanup”? Auth breaks. No tests, so nobody notices. It’s discovered after customer data leaks in production.

This is not a hypothesis. In CVE-2025-48757, 170+ apps generated by Lovable had their entire Supabase databases exposed due to missing RLS. 303 vulnerable endpoints leaked emails, API keys, and payment information. In January 2026, AI social network Moltbook was deployed with RLS disabled, exposing 1.5M API tokens and 35,000 emails.

2. Edge Functions = The Second Black Box

Business logic lives in two places: frontend code and Supabase Edge Functions. AI has to judge which logic lives where. AI gets this judgment wrong.

A payment discount calculation lives in an Edge Function. AI refactors the frontend and recreates the same calculation there. Now the discount is applied twice. It’s discovered in the revenue report 3 weeks later.

3. Migration = The Exit Cost

Leaving Supabase requires ripping out four things simultaneously:

  1. Auth — JWT structure tied to Supabase Auth, OAuth callbacks, session management
  2. Storage — bucket structure, access policies, URL signing
  3. Realtime — WebSocket subscriptions, Presence channels
  4. RLS policies — all undocumented business rules

Each seems like a day’s work, but all four are tangled together. Change Auth and RLS breaks. RLS breaks and Storage access opens up. Storage URLs change and the frontend breaks.

This is vendor lock-in. Getting in takes 30 seconds. Getting out takes 3 months.

The Cloud Version of Port Hell

The port hell vibe coders face locally — AI spins up servers, never kills them, ports get tangled, nobody knows what’s running — this moves to the infrastructure level with Supabase.

Local port hell: processes are invisible. Supabase hell: business logic is invisible.

Both have the same structure. What agents create, agents cannot track.

What’s the Alternative?

This is not an argument to stop using Supabase. The argument is: don’t put business logic in a black box.

Principle: every decision must live in the codebase.

  • Auth rules → declared in code, validated with tests
  • Access policies → declared with DDL + Rego, validated in CI
  • Business logic → exists in one place only, no duplication
  • Infrastructure config → declared with Terraform/IaC, version-controlled in git

Using Supabase for prototyping is reasonable. But the moment you move a prototype to production, you must extract the logic from the black box and move it to a declarative layer.

So that 30 seconds of magic doesn’t turn into 3 months of pain.

Is your RLS policy in git?

Do your Edge Functions have tests?

Are you certain that an AI “cleanup” won’t break auth?

Supabase is not the problem. Hiding decisions where they can’t be seen is.

Sources

  • Zhang, Y. et al. (2025). “The Invisible Hand: Unveiling Provider Bias in Large Language Models for Code Generation.” ACL 2025. arxiv.org/abs/2501.07849
  • CVE-2025-48757 (2025). Lovable-generated 170+ apps exposed entire Supabase DBs due to missing RLS. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API tokens + 35K emails exposed. blog.ogwilliam.com
  • Willison, S. (2025). “Supabase MCP can leak your entire SQL database.” simonwillison.net
  • Cursino, D. et al. (2026). “Speed at the Cost of Quality? The Impact of AI Coding on Software.” MSR 2026. arxiv.org/abs/2511.04427
  • Storey, M.-A. (2026). “From Technical Debt to Cognitive and Intent Debt.” arxiv.org/abs/2603.22106
  • Encore (2026). “Backend as a Service (BaaS) in 2026: Providers, Tradeoffs, and Migration Paths.” encore.dev