Supabase adalah jebakan vibe coding Image: AI generated

Keajaiban 30 Detik

“Buatkan backend untukku.” AI merekomendasikan Supabase. Dengan satu URL kamu mendapatkan PostgreSQL, autentikasi, penyimpanan, dan langganan real-time. Dalam 30 detik login sudah berjalan. Dalam 2 menit CRUD sudah selesai.

Tiga bulan kemudian, tidak ada yang tahu siapa yang menulis kebijakan RLS (Row Level Security) itu.

Mengapa AI Merekomendasikannya

Supabase bukan menjadi pilihan default vibe coding karena keunggulan teknisnya. Melainkan karena data pelatihan banyak mengandung tutorial tentangnya.

Cursor, Bolt, v0, Lovable — alat coding AI manapun yang kamu gunakan, ketik “buatkan backend untukku” dan hasilnya adalah Supabase. AI merekomendasikan pola yang paling sering dilihatnya. Bukan pola terbaik.

Zhang et al. (ACL 2025) membuktikan bahwa 7 LLM secara sistematis memilih penyedia tertentu tanpa instruksi eksplisit, dan secara otonom memodifikasi kode untuk menyisipkan penyedia yang disukai. Pengguna percaya apa yang AI rekomendasikan adalah yang terbaik. AI merekomendasikan yang paling sering muncul dalam data pelatihan. Inilah versi infrastruktur dari bias sanjungan.

Ketika Logika Tersembunyi di Kotak Hitam

Masalah sebenarnya dari Supabase bukan Supabase itu sendiri. Masalahnya adalah logika bisnis yang masuk ke dalam kotak hitam.

1. Kebijakan RLS = Logika Bisnis yang Tersembunyi

Row Level Security adalah fitur yang kuat. Masalahnya adalah: ketika AI membuat kebijakan RLS, di mana kebijakan itu tinggal?

  • Tidak ada di kode. Ada di dasbor Supabase.
  • Tidak ada di git. Tidak ada version control.
  • Tidak ada di pengujian. Tidak bisa divalidasi di CI.

Jawaban atas pertanyaan “siapa yang bisa mengakses tabel ini?” tidak ada dalam codebase. Kamu harus login ke konsol Supabase untuk memeriksa. Agen tidak bisa membaca ini.

Jika AI memodifikasi kebijakan RLS untuk “merapikan”? Autentikasi jebol. Tidak ada pengujian, tidak ada yang tahu. Baru ketahuan setelah data pelanggan bocor di produksi.

Ini bukan hipotesis. Pada 2025, CVE-2025-48757 mengungkap bahwa lebih dari 170 aplikasi yang dibuat Lovable mengalami kebocoran seluruh database Supabase karena kebijakan RLS yang hilang. 303 endpoint rentan, bocornya email, kunci API, dan informasi pembayaran. Pada Januari 2026, jaringan sosial AI Moltbook diluncurkan dengan RLS dinonaktifkan, mengekspos 1,5 juta token API dan 35.000 email.

2. Edge Functions = Kotak Hitam Kedua

Logika bisnis tinggal di dua tempat: kode frontend dan Supabase Edge Functions. AI harus memutuskan logika mana ada di mana. Dan AI salah dalam keputusan ini.

Kalkulasi diskon pembayaran ada di Edge Function. AI merefaktor frontend dan membuat ulang kalkulasi yang sama di sana. Sekarang diskon diterapkan dua kali. Ketahuan tiga minggu kemudian di laporan penjualan.

3. Migrasi = Biaya Keluar

Untuk keluar dari Supabase, kamu harus membongkar empat hal sekaligus:

  1. Auth — struktur JWT yang terikat ke Supabase Auth, callback OAuth, manajemen sesi
  2. Storage — struktur bucket, kebijakan akses, penandatanganan URL
  3. Realtime — langganan WebSocket, channel Presence
  4. Kebijakan RLS — semua aturan bisnis yang tidak terdokumentasi

Masing-masing terlihat seperti pekerjaan satu hari, tapi keempat-empatnya saling terkait. Mengubah Auth merusak RLS, merusak RLS membuka akses Storage, mengubah URL Storage merusak frontend.

Inilah vendor lock-in. Masuk butuh 30 detik. Keluar butuh 3 bulan.

Versi Cloud dari Neraka Port

Neraka port yang dialami vibe coder secara lokal — AI menjalankan server, tidak mematikannya, port kacau, tidak ada yang tahu apa yang sedang berjalan — ini naik level di Supabase ke tingkat infrastruktur.

Neraka port lokal: proses tidak terlihat. Neraka Supabase: logika bisnis tidak terlihat.

Keduanya memiliki struktur yang sama. Apa yang dibuat agen tidak bisa dilacak oleh agen.

Apa Alternatifnya?

Bukan berarti jangan gunakan Supabase. Yang dimaksud adalah jangan masukkan logika bisnis ke dalam kotak hitam.

Prinsip: setiap keputusan harus tinggal di codebase.

  • Aturan autentikasi → dideklarasikan dalam kode, divalidasi dengan pengujian
  • Kebijakan akses → dideklarasikan dengan DDL + Rego, divalidasi di CI
  • Logika bisnis → hanya ada di satu tempat, tanpa duplikasi
  • Konfigurasi infrastruktur → dideklarasikan dengan Terraform/IaC, di-version di git

Menggunakan Supabase untuk prototipe adalah wajar. Tapi saat prototipe dibawa ke produksi, logika di dalam kotak hitam harus dikeluarkan dan dipindahkan ke lapisan deklaratif.

Agar keajaiban 30 detik tidak berubah menjadi 3 bulan penderitaan.

Apakah kebijakan RLS kamu ada di git?

Apakah Edge Functions kamu memiliki pengujian?

Apakah kamu yakin “pembersihan” AI tidak akan merusak autentikasi?

Supabase bukan masalahnya. Masalahnya adalah menyembunyikan keputusan di tempat yang tidak terlihat.

Artikel Terkait

Sumber

  • 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 생성 앱 170+ RLS 누락으로 Supabase DB 노출. ameeba.com
  • OG William (2026). “Moltbook Hack: Supabase Vibe Coding.” 1.5M API 토큰 + 35K 이메일 노출. 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