Cannot create RLS policy on realtime.messages from migration: "must be owner of relation messages" (SQLSTATE 42501)

[RMACTION]

Summary

I'm trying to enable Realtime Authorization following the official documentation.

A standard SQL migration executed by Supabase CLI fails while creating an RLS policy on realtime.messages with:

ERROR: must be owner of relation messages
SQLSTATE: 42501

The SQL matches the official documentation, so I'm trying to understand whether:

• this is expected behaviour,
• my project has an ownership/provisioning issue,
• or the deployment procedure has changed.

---

Environment

• Supabase Cloud
• Free plan
• Migration executed normally through Supabase migrations
• Executing role reported by the migration:

current_user = postgres
session_user = postgres

---

SQL executed

CREATE POLICY authorize_record_edit_presence
ON realtime.messages
FOR ALL
TO authenticated
USING (
  realtime.topic() LIKE 'record_edit:%'
  AND split_part(realtime.topic(), ':', 2)::uuid = fn_get_current_user_unit_id()
);

---

Result

The migration fails with:

SQLSTATE: 42501
must be owner of relation messages

---

Diagnostics already performed

Current owners:

realtime.messages owner:
supabase_realtime_admin

realtime schema owner:
supabase_admin

No manual ownership changes have ever been executed.

No:

• ALTER OWNER
• REASSIGN OWNED
• GRANT
• manual CREATE POLICY

have been attempted.

The migration aborts atomically and no policy is created.

---

Documentation consulted

Realtime Authorization:

https://supabase.com/docs/guides/realtime/authorization

Supabase announcement (April 2025):

https://github.com/orgs/supabase/discussions/34270

That announcement explicitly says users can still create RLS policies on:

• realtime.messages

---

Similar issues

CLI issue:

supabase/cli#3549

CLI issue:

supabase/cli#3070

Both describe ownership-related SQLSTATE 42501 errors on Supabase-managed schemas.

---

Question

Should creating RLS policies on realtime.messages still work from standard migrations executed as postgres?

Or is there now another officially supported deployment method for Realtime Authorization policies?

A full technical investigation report is attached below, including diagnostics, ownership checks, migration history and references consulted.

INFORME_INCIDENCIA_PASO18_REALTIME_MESSAGES.md

[GaryAustin1]

Can you run that SQL from the SQL editor as Postgres?

Yes you should be able to add RLS policies but not Alter Table or several other things in the realtime schema.

https://github.com/orgs/supabase/discussions/48441 specifically says you can still modify/add policies as Postgres.

Not seeing any other reports of this specifically.

[RMACTION]

Thanks for the suggestion.

I tested the exact same SQL directly from the Supabase SQL Editor, running as the postgres role (Superuser).

The statement executed successfully:

Success. No rows returned.

The policy was actually created successfully from the SQL Editor.

So the SQL itself is valid and can be executed manually as postgres.

The failure only occurs when the exact same statement is executed through our migration pipeline, where it fails with:

SQLSTATE 42501: must be owner of relation messages

This suggests the issue is specific to the migration execution context rather than the SQL itself.

Do you know what difference in the migration execution context could explain this behaviour?

[GaryAustin1]

I do not know much about migrations. It is supposed to run as postgres user I'm pretty sure. Any chance you do a set role in the migration?

You might post in the CLI repository issues... https://github.com/supabase/cli/issues

Are you running the latest CLI?

I'm finding no similar reports.

[RMACTION]

Thanks for checking.

I verified both points:

• We are running the latest Supabase CLI available on our machine:

  supabase 2.109.1

• I searched our entire project and there are no SET ROLE statements anywhere in our migrations or SQL files.

The same SQL succeeds when executed directly from the Supabase SQL Editor as the postgres role, and the policy is created successfully.

The failure only occurs when the identical statement is executed through the migration pipeline, where it fails with:

SQLSTATE 42501: must be owner of relation messages

So at this point the only difference we can identify is the migration execution context itself.

We'll also open an issue in the Supabase CLI repository as you suggested, unless you think this belongs somewhere else.

[GaryAustin1]

As it is not working with CLI I would put it there.
The only other thing you can do is file a support request or wait for another user to come along with ideas.

[cekuu35]

This is not an ownership or provisioning problem with your project — the owners you printed are the expected ones. It is how PostgreSQL resolves the ownership check for CREATE POLICY.

CREATE POLICY requires you to be the owner of the relation, and internally that check is has_privs_of_role(current_role, owner) — privileges of, not membership in. Those are two different things:

• MEMBER means you are allowed to SET ROLE to it.
• USAGE means you already hold its privileges without doing so, which only happens when the membership is inheritable.

If postgres is a member of supabase_realtime_admin but the grant is NOINHERIT, every ownership check fails until you switch into the role explicitly. That produces exactly 42501 must be owner of relation messages while current_user still reports postgres, which is the part that makes it read like a provisioning bug.

Run this to see which case you are in:

select pg_has_role(current_user, 'supabase_realtime_admin', 'MEMBER') as can_set_role,
       pg_has_role(current_user, 'supabase_realtime_admin', 'USAGE')  as inherits_privs;

can_set_role = true with inherits_privs = false is the situation described above, and the migration then becomes:

set role supabase_realtime_admin;

create policy authorize_record_edit_presence
on realtime.messages
for all
to authenticated
using (
  realtime.topic() like 'record_edit:%'
  and split_part(realtime.topic(), ':', 2)::uuid = public.fn_get_current_user_unit_id()
);

reset role;

If can_set_role also comes back false, then postgres genuinely has no path to that role on your project and no amount of SQL from the migration will work — that one is worth escalating rather than debugging.

---

One thing worth changing regardless of how the ownership resolves: schema-qualify fn_get_current_user_unit_id().

Your policy body is evaluated later, by Realtime, under whatever search_path that connection has — not the one your migration ran with. An unqualified function that resolves fine at CREATE POLICY time can fail at evaluation time, and a policy that raises an error does not fail open or closed in a way you would notice quickly: the statement errors instead of filtering. public.fn_get_current_user_unit_id() avoids the whole question.

Same reasoning applies to the ::uuid cast — if a topic ever arrives whose second segment is not a UUID, split_part(...)::uuid raises rather than returning false, and the error surfaces as a broken subscription rather than a denied one.

[RMACTION]

Yes, I confirmed that.

The exact same SQL executes successfully from the Supabase SQL Editor using the postgres role, and the RLS policy is created successfully.

The failure only occurs when the identical SQL is executed through supabase db push.

Following your suggestion, I opened a dedicated CLI issue with the full reproduction details:
supabase/cli#6116

Thanks for pointing me in the right direction.

[RMACTION]

I ran the checks.

select
  pg_has_role(current_user, 'supabase_realtime_admin', 'MEMBER') as can_set_role,
  pg_has_role(current_user, 'supabase_realtime_admin', 'USAGE') as inherits_privs;

Result:

can_set_role = false
inherits_privs = false

I also tested:

set role supabase_realtime_admin;

and got:

ERROR: 42501: permission denied to set role "supabase_realtime_admin"

So it looks like this project does not allow the postgres role to become supabase_realtime_admin.

Given that, should this role membership exist on Cloud projects, or is this project missing the expected provisioning?

[GaryAustin1]

There are several admin roles you can't become (like supabase_auth_admin) that are only used by Supabase. Postgres is not a super user and not in total control.

[RMACTION]

Thanks for clarifying.

That makes sense regarding SET ROLE.

However, I'm still trying to understand why the exact same CREATE POLICY succeeds when executed from the Supabase SQL Editor as the postgres role, but fails with:

ERROR: must be owner of relation messages
SQLSTATE: 42501

when executed through supabase db push.

Is the CLI executing migrations under a different effective role than the SQL Editor, or is there another difference between those execution paths?

[GaryAustin1]

Right. Hence the suggestion to file an issue in the CLI repository. As it should work.
Any other migrations running before this one? I know you said you checked for set role. I'd be surprised if the CLI is bugged here and not getting other reports.,

[GaryAustin1]

Also you are sure it is on that particular SQL? You can't use 'ALTER TABLE your_table_name ENABLE ROW LEVEL SECURITY;' for instance as Postgres can't alter realtime tables, just add/change policies.

[cekuu35]

That settles it, and it is not your project.

pg_has_role(current_user, 'supabase_realtime_admin', 'MEMBER') = false together with USAGE = false means the role behind that connection has neither the membership nor the inherited privileges, so CREATE POLICY cannot pass the ownership check on realtime.messages. SET ROLE failing with the same 42501 confirms there is no way to borrow them either. There is nothing to repair in your migrations.

The reason the identical SQL succeeds in the SQL Editor is that the dashboard does not execute over the same connection and privilege path that supabase db push uses. Your two results prove that difference exists even though the statement is byte-identical — which is the useful part of what you just measured.

So the guarantee in #34270 ("create RLS policies ... on realtime.messages") currently holds through the dashboard path only. That mismatch between the documented permission and what the CLI connection can actually do is exactly what supabase/cli#6116 should track, and filing it separately was the right call.

To unblock your pipeline meanwhile: apply the policy once from the SQL Editor, then mark that migration as already applied so db push stops retrying it:

supabase migration repair <version> --status applied --linked

The migration file stays in version control as the record of intent, and CI stops failing on a statement that connection cannot execute.

[cekuu35]

Those two results are the interesting part, because together with what you already know they are contradictory:

• can_set_role = false and inherits_privs = false — postgres has no path to supabase_realtime_admin at all.
• Yet CREATE POLICY ... ON realtime.messages succeeds in the SQL Editor.

Both cannot be true for the same role in the same database. CREATE POLICY checks has_privs_of_role(current_role, owner), so if that is genuinely false the editor would fail too. Since it does not, the two contexts are not running as the same identity — and that, rather than the CLI version or a stray SET ROLE, is what you are chasing.

The fastest way to see it is to print the identity from both sides and compare, instead of inferring it:

select current_user,
       session_user,
       inet_server_port()                                   as port,
       current_setting('is_superuser')                      as is_superuser,
       (select rolbypassrls from pg_roles
         where rolname = current_user)                      as bypassrls,
       pg_get_userbyid((select relowner from pg_class
         where oid = 'realtime.messages'::regclass))        as table_owner,
       pg_has_role(current_user, 'supabase_realtime_admin', 'USAGE') as inherits;

Run it once in the SQL Editor, then put the same statement at the top of a throwaway migration and run supabase db push with --debug so the result is in the output. Whichever column differs is your answer.

Two candidates worth expecting:

1. The port. db push uses the connection string from your config or --db-url. If that points at the pooler on 6543 rather than a direct connection on 5432, you are not connecting as postgres — the pooler expects postgres.<project-ref>, which is a separate role with its own membership list. That would produce exactly your symptom: same SQL, same-looking user, different privileges. A direct 5432 connection string for migrations is the usual fix.

2. is_superuser / bypassrls. If the editor path reports differently here, the editor is not simply "running as postgres" and the ownership check is being satisfied by something your migration connection does not have.

Either way, the result is worth adding to the CLI issue you opened — a reproducible identity diff is a much stronger report than "same SQL, different outcome", and it tells the CLI maintainers immediately whether this is a connection-string default rather than a bug in the migration runner.

One more thing worth doing regardless of how this resolves, since it will bite later:

select tgname, tgrelid::regclass
from pg_trigger where not tgisinternal and tgrelid = 'realtime.messages'::regclass;

If the policy eventually lands, schema-qualify fn_get_current_user_unit_id() as public.fn_get_current_user_unit_id() in the policy body. It is evaluated later by Realtime under that connection's search_path, not the one your migration ran with, and an unqualified function that resolves fine at create time can raise at evaluation time — which surfaces as a broken subscription rather than a denied one.