DEV Community: dsplce.co

How to toggle realtime on a table in Supabase migrations

dsplce.co — Thu, 11 Jun 2026 21:28:54 +0000

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.

How to see running queries in Postgres and kill them

dsplce.co — Thu, 11 Jun 2026 21:28:08 +0000

Something is slow. Maybe a page takes forever to load, maybe a migration is hanging, maybe your Supabase dashboard just spins. You suspect a query is stuck somewhere in your database, but you can't see what's happening — Postgres doesn't exactly surface this on its own.

Turns out it does. You just need to ask.

Seeing what's running

Postgres keeps track of every active connection and what it's doing in a system view called pg_stat_activity. You can query it like any table:

SELECT pid, state, query, age(clock_timestamp(), query_start) AS duration
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

That gives you every non-idle process — its process ID, current state, the SQL it's running, and how long it's been at it. If something has been running for minutes when it should take milliseconds, you've found your problem.

A few things worth knowing about the columns:

pid — the process ID, which you'll need if you want to kill it
state — usually active (running right now), idle in transaction (sitting inside an open transaction doing nothing), or idle (waiting for work)
query — the actual SQL text
query_start — when the current query began

If you want to include the user and database to narrow things down:

SELECT pid, usename, datname, state, query, age(clock_timestamp(), query_start) AS duration
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY duration DESC;

The dangerous one — idle in transaction

An active query that's been running for a while is usually just slow. An idle in transaction connection is a different kind of problem — it means someone (or some code) opened a transaction and never committed or rolled it back. The connection is doing nothing, but it's still holding locks, which can block other queries from running.

These are the ones that tend to cause cascading slowdowns. If you see one that's been sitting there for longer than expected, it's almost certainly a bug in application code — a missing COMMIT, an unhandled exception that skipped the cleanup, or a connection pool that didn't reclaim the session properly.

Killing a process

Once you've identified the offending pid, you have two options.

The gentle approach — ask the query to cancel:

SELECT pg_cancel_backend(12345);

This sends a cancel signal to the running query. If the process is active, the query stops and the connection goes back to idle. It's the equivalent of hitting Ctrl+C — the session stays alive, no harm done.

The forceful approach — terminate the connection entirely:

SELECT pg_terminate_backend(12345);

This kills the entire backend process. The connection is dropped, any open transaction is rolled back, and the client gets disconnected. Use this when pg_cancel_backend doesn't work — which tends to happen with idle in transaction sessions, since there's no active query to cancel.

Replace 12345 with the actual pid from your pg_stat_activity query.

Killing in bulk

If you've got several stuck connections and want to clear them all at once:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND query_start < now() - interval '5 minutes';

That terminates every connection that's been idle in a transaction for more than five minutes. Adjust the interval to taste.

On Supabase specifically

If you're on Supabase, you can run all of this through the SQL Editor in the dashboard. The same pg_stat_activity view is available, and pg_cancel_backend / pg_terminate_backend both work. No extra permissions needed — the default postgres role has access.

One thing to keep in mind: Supabase runs background processes for Realtime, Auth, and PostgREST. You'll see these in pg_stat_activity too. Don't kill them — they'll usually show up with usernames like supabase_admin or authenticator. Stick to terminating connections from your own application's role.

Kubernetes kills your pod? Here's why

dsplce.co — Thu, 11 Jun 2026 21:27:31 +0000

Your pods keep getting killed. Not crashing — killed. One moment they're running fine, the next they're gone and Kubernetes is spinning up replacements. You check the logs and there's nothing useful. The pod just… disappeared.

Turns out Kubernetes killed it on purpose. And if you don't tell it how much memory your app actually needs, it'll keep doing it.

Why Kubernetes evicts pods

Kubernetes runs on nodes — physical or virtual machines that host your containers. Each node has a finite amount of CPU and memory. When a node runs low on resources, Kubernetes has to make a choice: which pods stay, and which ones get evicted to free up space.

The decision comes down to QoS classes — Quality of Service tiers that Kubernetes assigns to every pod based on how you've configured resource requests and limits.

There are three classes:

BestEffort — no resource requests or limits defined. Kubernetes has no idea how much CPU or memory the pod needs. These get killed first.
Burstable — requests and limits are defined, but they're different (e.g., requests: 256Mi, limits: 512Mi). The pod is guaranteed the request amount, but can burst up to the limit. Killed second.
Guaranteed — requests and limits are set to the same value. Kubernetes reserves exactly that amount of resources for the pod. Killed last.

If your pods don't have resource configuration at all, they're running as BestEffort. And when the node hits memory pressure, BestEffort pods are the first to go — no questions asked.

The Guaranteed class

Setting your pod to the Guaranteed class is one line in your deployment config. Define requests and limits for both CPU and memory, and make them identical:

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"
    cpu: "500m"

That's it. Kubernetes now knows this pod needs exactly 512 MiB of RAM and half a CPU core, and it reserves that capacity when scheduling the pod onto a node. If a node doesn't have 512 MiB available, the pod won't be placed there. And if the node runs into memory pressure later, this pod gets evicted last — only after all BestEffort and Burstable pods are gone.

The side effect — better autoscaling

On managed Kubernetes platforms like EKS, this has a second benefit: the cluster autoscaler pays attention to resource requests when deciding whether to add new nodes.

If your pods are BestEffort (no resource config), the autoscaler sees them as requiring zero resources. Ten pods running on a single node looks fine to it, even if that node is at 90% memory usage. It won't spin up a new node because, from its perspective, there's no unmet resource demand.

But if those same pods are Guaranteed with requests: 512Mi, and the current node doesn't have 512 MiB free, the autoscaler sees a pod that can't be scheduled and adds a new node to accommodate it. Your pods start spreading across multiple nodes instead of piling up on one.

This is particularly rigid on EKS — other Kubernetes providers are a bit more lenient, but EKS strictly follows the scheduler's resource calculations. If you don't define requests, autoscaling won't trigger, and you'll end up with all your pods crammed onto a single node until it runs out of memory and starts evicting things.

The trade-off

The downside of Guaranteed is that you're committing to a specific memory limit. If your app grows and starts using more than what you've configured, the pod gets OOMKilled (out-of-memory killed) instead of being allowed to burst beyond the limit.

With Burstable, you could set requests: 256Mi and limits: 1Gi, giving the app room to spike without getting killed. But you lose the scheduling guarantees — Kubernetes only reserves the 256 MiB request amount, so the pod might end up on a node that doesn't have the full gigabyte available.

Guaranteed means you need to monitor memory usage and bump the limit when your app legitimately needs more. It's a bit more maintenance, but in exchange you get predictable scheduling, protection from eviction, and autoscaling that actually works.

How to set it

In your Kubernetes deployment manifest, add the resources block under containers:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: your-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        image: your-image:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "500m"
          limits:
            memory: "512Mi"
            cpu: "500m"

Apply it:

kubectl apply -f deployment.yaml

Check the QoS class:

kubectl get pod <pod-name> -o jsonpath='{.status.qosClass}'

If it says Guaranteed, you're set.

Picking the right values

Start by looking at what your pods are actually using. Get current memory consumption:

kubectl top pods

Take the highest value you see, add 20-30% headroom, and use that as your request and limit. If a pod is sitting at 400 MiB, set it to 512 MiB. If it's consistently hitting 800 MiB, go with 1 GiB.

For CPU, half a core (500m) is a reasonable starting point for most apps. Bump it if you see CPU throttling in your metrics.

And then monitor. If you see OOMKills in the pod events, the limit is too low — increase it. If memory usage grows over time as you ship new features, update the config to match.

Kubernetes won't kill your pods arbitrarily once they're Guaranteed. But you have to tell it what "guaranteed" actually means.