Fanout scales with topology, not traffic
One row change becomes many subscriber deliveries. A single feature can run thousands of dollars per month with no traffic spike you would notice.
Supabase Egress Cost Reduction
Last reviewed Tame Supabase egress before realtime fanout scales your bill.
On modern stacks the cost inflection is rarely the scaffold tool — it is the subscription topology and event-delivery pattern the fast build makes easy to ship. NavyaAI maps Supabase, Neon, and Trigger.dev fanout to outbound cost so teams can fix it before every row change reaches every open tab.
~$3,200/mo
from one realtime feature
10–15%
of cloud bill is egress
$6,300 → $0
one cross-region path
Convenience defaults are the expensive defaults
Postgres Changes and full-row payloads ship fastest and cost the most. The scaffold is not the problem; the subscription pattern is.
Egress is spread across separate meters
Realtime messages, Edge Function invocations, outbound bytes, and database egress are different SKUs that each grow with the same fanout.
Deep Dive
Why realtime fanout is the cost inflection
Supabase's own docs are explicit: Broadcast is recommended for scalability, while Postgres Changes does not scale as well because every change event is authorization-checked per subscriber on a single ordered thread. The same benchmark pattern moved 10.4 GB at 1KB payloads versus 348 GB at 50KB — payload size, not logical event count, drives the bytes.
That is why teams shipping fast on Lovable plus Supabase get surprised: the meaningful unit is delivered messages and bytes per logical change, and it is dominated by topology and payload size, not the per-message rate. The audit instruments that fanout before recommending any change.
The graduation path that keeps realtime cheap
Ship the feature with direct subscriptions, but plan the graduation path early. The path is channel scoping, payload minimization, event batching, outbox tables, and webhook or Edge-Function aggregation rather than letting every row change instantly become a fanout event to every open tab.
Each move maps to a meter: narrower channels cut message count, deltas cut bytes, outbox batching cuts invocations, and aggregation cuts webhook egress. The audit ranks these by expected savings against the effort to implement them.
Audit Focus
What we inspect before prescribing a platform change.
The first pass is designed to identify the smallest useful intervention: routing, caching, prompt control, serving tuning, or a deeper break-even audit.
Realtime subscription topology (Broadcast vs Postgres Changes)
Payload size and full-row vs delta delivery
Edge Function and serverless invocation patterns
Webhook and pg_net trigger fanout
Outbound egress vs included quota
Polling vs event-driven delivery
Supabase and modern-stack egress map — see the full map
Where realtime and serverless stacks turn convenience into transfer cost.
| Signal | Likely leak | Audit question |
|---|---|---|
| Postgres Changes subscriptions | Per-subscriber auth checks on a single thread | Can this move to Broadcast with scoped channels? |
| Full-row broadcast payloads | Every event ships full metadata | Would a delta, or ID plus on-demand fetch, be enough? |
| Component-level subscriptions | Peak websocket count scales with components | Can one hub per page or tenant own the subscription? |
| pg_net triggers per row | Each row becomes a webhook and egress event | Can an outbox table batch and debounce? |
| Polling Edge Functions | Paying for no-change checks | Webhook or Broadcast instead of polling? |
Worked Example
Cost of one realtime feature at scale
Illustrative: one row update per second, a 2KB payload, and 500 subscribed clients, on Supabase Pro/Team pricing.
| Driver | Monthly volume | Modeled cost |
|---|---|---|
| Realtime messages | ~1.3B (500/sec) | ~$3,200 overage |
| Outbound event bytes | ~2.6 TB | ~$210 over quota |
| Duplicate subscriptions | × per component | scales ~linearly |
| Full-row vs delta payloads | 2KB vs ~100B | up to ~20x the bytes |
Direct consequences of Supabase's documented pricing and realtime fanout behavior — not vendor quotes. Your topology will differ; that is what the audit maps.
How It Works
How the audit works
Step 1
Share your stack shape
Submit your stack (Supabase, Neon, Trigger, hyperscaler), monthly spend, and biggest transfer driver. Takes minutes, no production access needed.
Step 2
Map the avoidable paths
We match your shape against known leak patterns — realtime fanout, full-row payloads, polling, per-row triggers, cross-AZ and NAT — and quantify where outbound cost concentrates.
Step 3
Rank levers by friction and savings
Each leak gets a lever — Broadcast migration, channel scoping, delta payloads, outbox batching, gateway endpoints — ranked by expected savings against implementation effort.
Step 4
Get the written read, then decide
You receive the first transfer-leak read in writing. If the economics justify deeper work, the next step is a scoped engagement; if not, you keep the findings.
Start with spend, provider, and workload shape.
The audit form routes teams below $20K/month toward self-serve estimators and routes qualified spend into follow-up.
FAQ
Common questions
Why are my Supabase costs rising faster than usage?
Usually realtime fanout. Every row change can multiply into many subscriber deliveries, and Supabase bills realtime messages, Edge Function invocations, and egress as separate meters that all grow with the same event topology. The traffic you see in product analytics is not the traffic on the bill.
How much can a single realtime feature cost?
A feature with 500 subscribed clients receiving a 2KB payload once per second is about 1.3 billion messages per month — roughly $3,200 in realtime message overage plus around $210 of egress over quota on Supabase Pro/Team pricing. That is one feature, with no spike.
What is the fix for Supabase realtime cost?
Supabase recommends Broadcast over Postgres Changes for scale. Beyond that: scope channels and filters, send compact payloads or deltas instead of full rows, centralize subscriptions into one hub per page or tenant, and replace polling and per-row triggers with batched outbox or webhook patterns.
Does this apply to Neon and Trigger.dev too?
Yes. The pattern is general to fast-build serverless and realtime stacks: per-event invocation pricing plus outbound transfer means a row-per-invocation or broadcast-everything design is rarely the cheapest at scale. The audit covers webhooks, pg_net, background jobs, and Edge Functions alongside Supabase realtime.