Self-hosted Supabase: switching Studio from supabase_admin to postgres (breaking change)

What's Changing?#

The week of June 15, 2026, the default docker-compose.yml in self-hosted Supabase will switch the database role used by Studio and postgres-meta from supabase_admin to postgres:

• studio.environment.POSTGRES_USER_READ_WRITE will default to postgres
• meta.environment.PG_META_DB_USER will default to postgres

This aligns self-hosted Supabase with the platform behavior introduced in late 2022, which removed superuser access from the dashboard SQL editor and shifted ownership of user-created objects to postgres. Self-hosted has been running with the legacy behavior until now.

⚠️ Existing instances that pull this change need to run a one-time ownership migration script for the public schema, or new operations from Studio may fail on objects still owned by supabase_admin.

Why?#

• Self-hosted has been three-plus years behind the platform on this. Behavior between deployment models should be consistent.
• The postgres role is non-superuser, so this reduces the privilege surface used by Studio's day-to-day operations.
• Migrations and scripts that work on the platform may currently fail on self-hosted because of the ownership mismatch - this closes that gap.

Am I Affected?#

You are affected if all of the following are true:

• You run self-hosted Supabase from the ./docker directory
• You pull updates from master without overriding POSTGRES_USER_READ_WRITE or PG_META_DB_USER
• You have an existing instance with database objects created via Studio (which would currently be owned by supabase_admin)

You are not affected if you:

• Use the Supabase platform - this has been the default since 2022
• Use the Supabase CLI for local development (supabase start) - it's a different deployment option
• Are starting a fresh self-hosted deployment - objects created via Studio will be owned by postgres from the start

What Should I Do?#

If you have an existing self-hosted Supabase instance, follow the Remove superuser access guide:

1. Run the included script to reassign ownership of objects in the public schema from supabase_admin to postgres:
   
   

   _10

   sh utils/reassign-owner.sh

   
   
2. Pull the new docker-compose.yml (or manually set POSTGRES_USER_READ_WRITE: postgres and PG_META_DB_USER: postgres if you maintain a customized compose file)
3. Restart the stack
4. Verify in the Studio SQL editor that select current_user; returns postgres

The script only touches the public schema. Supabase-managed schemas (auth, storage, realtime, etc.) and any custom schemas you've created are left intact. If you have objects in custom schemas that you want migrated, you'll need to reassign their ownership manually.

If you'd rather defer this for now, set POSTGRES_USER_READ_WRITE and PG_META_DB_USER back to supabase_admin in your override file. This is a default change, not a removal - but we recommend completing the migration soon to stay aligned with platform behavior.

Rollout#