You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Run the included script to reassign ownership of objects in the public schema from supabase_admin to postgres:
sh utils/reassign-owner.sh
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)
Restart the stack
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.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
What's Changing?
The week of June 15, 2026, the default
docker-compose.ymlin self-hosted Supabase will switch the database role used by Studio andpostgres-metafromsupabase_admintopostgres:studio.environment.POSTGRES_USER_READ_WRITEwill default topostgresmeta.environment.PG_META_DB_USERwill default topostgresThis 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.publicschema, or new operations from Studio may fail on objects still owned bysupabase_admin.Why?
postgresrole is non-superuser, so this reduces the privilege surface used by Studio's day-to-day operations.Am I Affected?
You are affected if all of the following are true:
./dockerdirectorymasterwithout overridingPOSTGRES_USER_READ_WRITEorPG_META_DB_USERsupabase_admin)You are not affected if you:
supabase start) - it's a different deployment optionpostgresfrom the startWhat Should I Do?
If you have an existing self-hosted Supabase instance, follow the Remove superuser access guide:
publicschema fromsupabase_admintopostgres:docker-compose.yml(or manually setPOSTGRES_USER_READ_WRITE: postgresandPG_META_DB_USER: postgresif you maintain a customized compose file)select current_user;returnspostgresThe script only touches the
publicschema. 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_WRITEandPG_META_DB_USERback tosupabase_adminin 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
Beta Was this translation helpful? Give feedback.
All reactions