Supabase Realtime latency spikes under concurrent WebSocket connections

Question

Goal: Determine whether the increase in broadcast latency observed in Supabase Realtime is caused by connection‑pool exhaustion, PgBouncer backpressure, or Node.js event‑loop lag when many clients open WebSocket connections simultaneously.

Constraints: The threshold at which latency becomes noticeable is unknown and may differ between free and paid project tiers; network jitter could also contribute. Uncertainty remains about which internal metric best predicts the latency rise and whether the behavior is intrinsic to the managed service or specific to a project’s configuration.

Questions: What concurrent WebSocket connection count begins to produce measurable latency increase? Which metric—PgBouncer wait time, Node.js loop lag, or database replication lag—correlates most strongly with the observed latency? Do latency patterns diverge between free and paid Supabase projects under identical load conditions?

Tasadduq Burney · Answer

Answer to the Core Question
During a surge of concurrent WebSocket connections, the most common latency driver in Supabase Realtime is the authentication overhead that occurs on every new handshake. The Realtime engine is written in Elixir/Phoenix and runs on the BEAM VM, which handles concurrency via lightweight processes. Therefore, Node.js event‑loop lag is not a factor, and broadcast messages do not hit PgBouncer or rely on WAL replication, making those mechanisms unlikely culprits for broadcast latency spikes.
Which Metric Predicts Latency Most Effectively?

Database CPU utilization – a spike in CPU usage during connection bursts typically coincides with increased auth query load.
  Auth query latency – the time taken to validate a new connection against the PostgreSQL database.
  Replication lag – relevant only for CDC‑based Realtime events, not for direct broadcasts.

Monitoring Database CPU Utilization and Auth Query Latency will usually reveal the root cause of the observed latency.
Free vs. Paid Tier Behavior
Free tier projects run on shared resources with lower CPU and memory limits. Consequently, the threshold at which auth queries saturate the database is lower, leading to earlier onset of latency spikes under identical load conditions. Paid tiers provide dedicated resources and higher priority, so the same number of connections will generally produce less latency.
Practical Verification Steps

Baseline Collection – record broadcast latency, DB CPU, and auth query latency while running a small number of connections (e.g., 10–20).
  Load Increment – use k6 or a similar WebSocket load‑testing tool to increase concurrent connections in increments of 50 or 100, recording the same metrics.
  Identify Threshold – the point where the 95th percentile broadcast latency rises above the baseline indicates the saturation point.
  Isolate Broadcast vs. CDC – send a broadcast message to already‑connected clients while opening new connections. If only new connections see delays, the bottleneck is the handshake/auth phase.
  Repeat the test on a paid tier to confirm that the saturation point shifts to a higher connection count.

Missing Diagnostic Detail
To refine the recommendation further, could you share the average payload size of your broadcast messages? Larger messages may shift the bottleneck toward network bandwidth on the Realtime instance rather than CPU.

Supabase Realtime latency spikes under concurrent WebSocket connections

1 answer

Answer to the Core Question

Which Metric Predicts Latency Most Effectively?

Free vs. Paid Tier Behavior

Practical Verification Steps

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments