How to toggle realtime on a table in Supabase migrations

You set up a table locally, opened it in Supabase Studio, flipped the Realtime toggle on, and everything worked — your frontend was getting live updates, subscriptions firing perfectly. Then you ran supabase db diff, generated your migration, pushed it all to production… and Realtime is dead. No events, no subscriptions, nothing.

You check the table — it's there. Columns, RLS policies, indexes, all present. But the Realtime toggle? Off. As if you never touched it.

Why?

The supabase db diff command compares database schemas. Realtime configuration is not a schema change — it's a publication membership. Under the hood, flipping that toggle in Studio just adds your table to a Postgres publication called supabase_realtime. That's it. And because it's neither a schema change nor a data change, db diff is completely blind to it. It won't show up in the diff output, and it won't end up in your migration file.

If you want Realtime to travel with your migrations, you just simply need to write the SQL yourself.

So what's the SQL?

It's just one line:

ALTER PUBLICATION supabase_realtime ADD TABLE public.messages;

That adds your table to the publication. Any client subscribed to it will start receiving changes.

Multiple tables at once:

ALTER PUBLICATION supabase_realtime ADD TABLE public.messages, public.notifications;

Removing a table from Realtime:

ALTER PUBLICATION supabase_realtime DROP TABLE public.messages;

Turning it into a migration

supabase migration new enable_realtime_on_messages

Paste the ALTER PUBLICATION statement into the generated file and you're done. Next time you deploy, the table will be part of the supabase_realtime publication in the target environment.

One thing to watch out for — if someone already enabled Realtime on that table manually in production, the migration will fail with a duplicate table error.

The faster way — supabase-plus

Keeping track of which tables have Realtime enabled, remembering the publication name, checking the current state before writing the migration — it adds up. supabase-plus handles all of that with a single command:

sbp manage realtime

It connects to your local database, lists every table in the schema, and shows you which ones are currently subscribed to supabase_realtime. From there it's an interactive multi-select — toggle tables on or off, and the tool generates the ALTER PUBLICATION statements for you, drops them into a timestamped migration file in supabase/migrations/, and optionally applies the migration to your local database right away.

You can also scope it to a specific schema:

sbp manage realtime --schema private

No looking up syntax, no guessing what's already enabled — the tool shows you the state and lets you change it in one step.

One toggle in Studio, zero lines in your migration history. Now you know how to fix that.