Supabase: Realtime schema is now fully locked down against modifications
Component: supabase · Channel: stable. Automated analysis, not a compatibility certification. How this works.
Analysis updated: 2026-11-01.
Breaking-change evidence from the source
table, and a future Realtime migration also needed to create an object with that name, the migration would fail and Realtime would stop working for
Supabase has strictly locked down the 'realtime' schema, preventing users from creating, altering, or dropping objects within it to ensure system stability. Any existing migrations or SQL scripts that modify this schema will now trigger permission errors and must be refactored.
💻 Software Engineers & Devs
Audit your codebase and migration files for any DDL statements targeting the 'realtime' schema and relocate that logic to user-defined schemas.
📊 Product & Engineering Leads
This change ensures higher platform reliability for Realtime features by preventing user-side database conflicts that previously could break project-wide functionality.
⚙️ DevOps & Security
Update your CI/CD pipelines to remove any scripts that manage objects within the 'realtime' schema to avoid failed deployments.
⚠️ Breaking Changes & Deprecations (1)
- table, and a future Realtime migration also needed to create an object with that name, the migration would fail and Realtime would stop working for that project. The team doesn't inspect project data without prior authorization, so checking every project for name conflicts before shipping a migration isn't realistic. Every new migration carried the risk of breaking projects the team had no way to check in advance. Locking down the schema removes that risk and lets Realtime ship schema changes safely.
⚡ Performance & Enhancements (1)
- Enhanced stability of Realtime service by preventing destructive user-side DDL modifications
🔧 Bug Fixes & Patches (1)
- Eliminated potential for system-breaking name collisions between user objects and internal Realtime migrations