Before You Consider Using Supabase, Watch This

Summary

The presenter argues that Supabase should be developed with the Supabase CLI, rather than making database changes directly in the Supabase dashboard or through an AI agent connected to a live project.

• Develop locally first: The CLI can run a Supabase instance on a developer’s computer, allowing an app to be built and tested without immediately creating or modifying a hosted project.
• Track database changes as migrations: Record schema changes in migration files alongside application code. This makes changes reproducible, reviewable, and reversible through Git, while helping preserve existing production data when adding features.
• Keep development separate from production: Test changes locally, then commit the code and migrations. Once deployment is configured, deploy migrations to the hosted Supabase project without manually editing the production database.
• Organize the backend separately if useful: For mobile apps, the presenter prefers keeping Supabase backend files in a separate folder or repository from the frontend, citing security and deployment priorities.
• Use MCP cautiously: The presenter considers direct changes to a working database through Supabase MCP unreliable and risky. In their view, a more appropriate use is read-only access to production logs, so an AI agent can help diagnose errors. MCP permissions should be restricted because compromised access could expose user data.

Guide and Recommendations

This video presents an opinionated Supabase development workflow: use the CLI and local development, track schema changes with migrations, and protect production from experimental changes. Its main warning is against treating a live Supabase database as the place to develop.

Main speaker/source: John Kealy, the video’s presenter.