Is WebRTC Too Expensive to Scale, and Does MoQ Fix That?

WebRTC gets genuinely expensive in one narrow place: large one-to-many broadcast, where every viewer needs its own relayed stream, the SFU — the server that forwards media to each participant — has to be provisioned for peak concurrency, and cascading between regions bills the same bytes more than once. Below roughly 1,000 concurrent viewers per stream, most “WebRTC is too expensive” pain is configuration and vendor-pricing pain, not protocol pain. Media over QUIC (MoQ) is designed to fix the broadcast case, by fanning out through cacheable relay infrastructure instead of stateful per-participant forwarding. That reasoning is sound. It is also unbenchmarked: as of August 2026 no neutral study compares MoQ and WebRTC cost at equivalent production scale, and nobody is paying a production price for MoQ at all.

Key takeaways

• WebRTC’s real cost ceiling is narrow and specific: large one-to-many broadcast, where SFU cascade and per-viewer egress compound. Our own pragmatic dividing line, from the MoQ vs WebRTC comparison: under ~1,000 concurrent viewers per stream, SFU tuning is the answer, not a protocol switch.
• Most “WebRTC is too expensive” complaints are a billing diagnosis problem, not a protocol problem — unused TURN relay, no simulcast, bad regional placement, or managed per-participant rates past the point where self-hosting is cheaper.
• MoQ’s cost thesis is that one encode fans out through shared, cacheable relays instead of a stateful SFU forwarding to each participant individually — the same economics that already make CDN-based HLS cheaper than WebRTC at broadcast scale.
• You cannot put MoQ in a budget yet, because nobody is charging a production price for it. Cloudflare’s MoQ relays are in tech preview and free to use at any scale. The only price signal anywhere is Cloudflare’s stated expectation that general-availability self-serve pricing will be 5 cents/GB outbound (stated August 2025).
• The same vendor charges $0.05/GB egress for its WebRTC SFU and TURN today. If the expected MoQ GA rate holds, MoQ’s advantage cannot come from a cheaper byte — it has to come from moving fewer billable bytes. Note this is one vendor’s own numbers, not an industry rate; it is also the only real price signal that exists anywhere.
• No independent MoQ-vs-WebRTC cost benchmark exists as of August 2026. One vendor has self-published commercial performance data; that is a signal of real commercial interest, not a neutral benchmark.
• Trembit’s verdict: MoQ should bend the broadcast cost curve architecturally, but it is not yet a cost plan. Fix real WebRTC cost problems now with SFU tuning or a WebRTC + LL-HLS hybrid; treat a MoQ pilot as a scoped, non-critical bet on future economics.

If you’re here for the budget decision rather than the protocol detail, skip to “So — does MoQ fix WebRTC’s scaling cost problem?” — the comparison table there maps each cost problem to the answer available today.

Is WebRTC actually too expensive to scale, or is that the wrong question?

For most products, it’s the wrong question. The bill is real, but the protocol usually isn’t the reason.

WebRTC’s cost is driven by a handful of components: TURN relay traffic, SFU compute, egress on every outbound stream, signaling, recording, and the engineering time to keep all of it running. We broke that stack down component by component, with the vendor pricing comparison and the self-hosted-versus-managed crossover, in what CTOs actually pay for WebRTC in 2026. This piece deliberately doesn’t re-derive it.

What matters here is the diagnosis. The “WebRTC is too expensive” complaint usually resolves into one of four findings, none of which is a protocol ceiling:

• A TURN relay ratio far higher than it should be — TURN is the fallback that relays media when a direct connection can’t be established, and it’s billed traffic. When too much of your session volume is going through it, you’re paying relay prices for connections that could have gone direct.
• No simulcast or SVC — two techniques for sending multiple quality layers, so each participant receives one matched to what they’re actually displaying. Without them, the server pushes full-resolution streams to people rendering them in a 180-pixel tile.
• Regional placement nobody revisited since launch, so media crosses oceans it doesn’t need to cross.
• Managed per-participant pricing well past the crossover point. Our own baseline figure: self-hosted becomes cost-competitive with managed cloud somewhere between 500K and 1M participant-minutes per month. Plenty of teams are two or three times past that and have never re-run the comparison.

This is not a WebRTC-specific pattern. The same misdiagnosis shows up in voice, where relay and inference costs get blamed on the transport — see our breakdown of what it costs to run a voice AI platform.

The practical test is simple: if your cost per participant-minute has been climbing while your architecture hasn’t changed, that’s a configuration or contract problem. A protocol ceiling doesn’t creep. It arrives when your audience shape changes.

Where does WebRTC’s cost curve genuinely break down?

At large one-to-many broadcast — tens of thousands of concurrent viewers on a single stream — the cost curve stops being linear-and-manageable for four compounding reasons.

Every viewer costs a fresh outbound stream. An SFU forwards media; it doesn’t cache it. Viewer 10,000 costs the same egress as viewer 10, and nothing upstream is ever reused — every copy is produced and paid for again from the same server. Worth being precise about the limit of this, though: no protocol dissolves last-mile egress. Delivering live video to N simultaneous viewers means N unicast streams whether you run WebRTC, HLS, or MoQ. What differs is everything behind that last hop.

Cascading bills the same bytes more than once. Serving a global audience means regional SFUs, and media has to reach them. The origin-to-regional hop is billable traffic that produces zero viewer-facing value; it exists purely so the fan-out can happen closer to the edge. The more regions, the more times you pay to move the same seconds of video.

Stateful capacity has to be provisioned for peak, not average. An SFU holds a live connection per participant. You size the fleet for the biggest concurrent moment you expect — the product launch, the earnings call, the volatile market session — and you pay for that headroom during every quiet hour in between.

And broadcast products almost always need VOD too. WebRTC was never built for time-shifted delivery. The moment the product needs replay, catch-up, or a searchable archive, you bolt on a second pipeline: packaging, transcoding, storage, CDN. Now you are funding two delivery stacks to serve one piece of content. In our experience this is the cost line teams underestimate most, because it doesn’t appear in any WebRTC pricing calculator.

Point four is the one that separates a broadcast cost problem from a broadcast scale problem. Scale you can engineer around. Two parallel delivery stacks is a structural tax you pay every month.

This is also the regime where CDN economics visibly win. Our teardown of what it costs to run Twitch-scale streaming infrastructure shows the same pattern from the other side: past a certain audience size, delivery cost is a CDN egress conversation, and everything else is rounding.

What is MoQ’s cost thesis, and does the reasoning hold up?

How does MoQ’s relay model differ from WebRTC’s SFU model, cost-wise?

MoQ is a publish-subscribe transport running over QUIC, standardized in the IETF’s MoQ working group — the transport specification is at draft-ietf-moq-transport-19, dated 6 July 2026, with the working group targeting publication request in December 2026.

The cost-relevant difference is what sits between publisher and subscriber. WebRTC puts an SFU there: a stateful server that terminates a connection per participant and forwards media to each one individually. MoQ puts a relay there: a node that receives named objects and serves them to whoever has subscribed, the way a CDN serves a cached asset — cache once at the edge, then serve from there.

Be precise about what that actually saves, because this is where MoQ marketing tends to overreach. It does not reduce the bytes delivered to each viewer; that volume is structurally the same for unicast delivery no matter the protocol. What it removes is the interior cost: repeated origin fetches, the cross-region cascade hop you currently pay for twice, and the stateful capacity an operator has to hold ready for peak. Those are real and they are exactly the three items listed in the section above.

That is the whole thesis, and it isn’t novel — it’s why CDN-based HLS and LL-HLS are already cheap at broadcast scale today. MoQ’s contribution is trying to get those economics at latency close to WebRTC’s, in one protocol, instead of forcing the architecture choice.

One practical note, since the protocol detail decides whether any of this ships in a browser: JavaScript has no raw QUIC socket, so a browser reaches MoQ through WebTransport. That dependency is part of the readiness question, not a cost question — but it’s the first thing to check before scoping a pilot.

Is there any real pricing data for MoQ yet?

No. And that is the most useful thing a CTO can know about MoQ’s economics right now.

Cloudflare has turned every server in its network, across more than 330 cities, into a MoQ relay, and says it runs them “at Cloudflare’s full scale, like we do every production service.” As of 31 July 2026 it also ships a provisioning API for isolated relays. Both products are explicitly labeled preview/beta, and the current pricing is stated plainly: “They are completely free to use during beta”, free at any scale.

The only number that exists anywhere is forward-looking. In the August 2025 announcement, Cloudflare wrote that “in general availability, self-serve customers should expect to pay 5 cents/GB outbound with no cost for traffic sent towards Cloudflare.” That is a stated expectation for a product that hasn’t reached general availability. It is not a rate in force, not an SLA-backed commitment, and not something to model a 2027 budget against.

Here is the contrast worth drawing, and it is our analysis rather than Cloudflare’s claim. Cloudflare’s own WebRTC products — Realtime SFU and TURN — cost $0.05 per GB of egress today, with the first 1,000 GB free. The expected MoQ GA rate is the same 5 cents per gigabyte outbound. Same vendor, same expected unit price for the byte.

Two caveats before drawing a conclusion from that. This is one vendor’s own numbers, not an industry rate — it happens to be the only real price signal that exists anywhere, which is precisely the problem. And both products bill purely on outbound traffic: inbound is free, and neither carries a separate compute or per-server line item.

That second point matters, because it narrows the claim usefully. If the rates hold, MoQ’s cost advantage cannot come from a cheaper byte — on a managed platform like this one, it has to come from moving fewer billable bytes: no cascade hop paid for twice, no second packaging-and-CDN pipeline serving the same content as VOD. That is our own inference from two published rates — Cloudflare draws no MoQ-vs-WebRTC cost comparison anywhere.

The other saving people reach for — not provisioning an SFU fleet for peak concurrency — is real, but it belongs to a different bill. It shows up in a self-hosted operator’s own infrastructure spend, not on a managed vendor’s invoice, because that vendor isn’t charging you for servers on either product today. Worth separating the two, because the argument only stays honest if you keep the actors straight.

Either way it is a plausible, meaningful saving, and a completely different claim from “MoQ is cheaper per gigabyte,” which is what most of the marketing implies.

Is MoQ cheaper than LL-HLS, or just cheaper than WebRTC?

This is the nuance MoQ marketing skips, and it changes the business case.

LL-HLS is already CDN-cheap. If your comparison is “MoQ versus HLS on cost,” there is no obvious win available — both ride the same edge-caching economics, and HLS has a decade of operational maturity behind it.

MoQ’s real economic pitch, if the architecture pays off, is not “cheaper than HLS.” It is HLS-like cost at WebRTC-like latency, from one delivery stack instead of two. For a product that today runs WebRTC for the interactive core and a separate HLS pipeline for the audience and the replay archive, the saving isn’t a lower per-gigabyte rate — it’s deleting an entire pipeline, its transcoding, and the engineering time that keeps two stacks in sync.

That’s a real prize. It is also unproven. No neutral, independent benchmark compares MoQ with WebRTC or with LL-HLS at equivalent production scale as of August 2026. Cloudflare’s production-capacity relay network is genuine evidence the architecture works operationally; it is not evidence of the cost claim. One vendor, nanocosmos, has self-published what it calls the first commercial performance data for Media over QUIC — treat that as a real signal that commercial deployments exist, and not as an independent benchmark, because it is the vendor reporting on itself.

If you’re weighing a MoQ pilot against an SFU optimization sprint this quarter, that’s a two-hour conversation, not a research project — our WebRTC architecture reviews exist to answer exactly that.

What can you do about WebRTC scaling cost today, without waiting for MoQ?

Three things, all proven, all available now.

Tune the SFU before you touch the protocol. Typical lift: days to a couple of weeks, mostly configuration. This means working through the four findings above — relay ratio, simulcast or SVC, regional placement — plus moving 1:1 sessions to peer-to-peer where the compliance posture allows it. It is the cheapest option on this list by a wide margin, and in most reviews it recovers more than a protocol migration would. If the question underneath is which media server you should be running at all, LiveKit vs mediasoup covers that decision directly.

Adopt the hybrid pattern if you’re genuinely at broadcast scale. Typical lift: a quarter of engineering, and a permanent second stack to maintain. WebRTC for the interactive core — hosts, guests, anyone whose reaction has to be immediate — and CDN-based HLS or LL-HLS for fan-out to the passive audience. Running two stacks is exactly the cost MoQ hopes to eliminate, so go in clear-eyed: you are accepting a known, ongoing tax in exchange for something deployable now on infrastructure priced for volume.

Re-run the crossover math with your current numbers. Typical lift: an afternoon to answer, one to two quarters to act on if the answer is “migrate.” Somewhere between 500K and 1M participant-minutes per month, self-hosted infrastructure typically overtakes managed per-participant pricing.  Below it, a managed provider plus good configuration is usually right. Above it, the savings can be large enough that the protocol question stops being the interesting one.

None of this requires MoQ. It’s available, proven engineering, and for most teams it closes the gap that sent them looking at new protocols in the first place.

So — does MoQ fix WebRTC’s scaling cost problem?

Architecturally, yes — for the narrow broadcast slice where WebRTC’s cost ceiling is real. Practically, not yet, because there is no benchmark to bank a budget on and no production price to put in it.

It’s worth being clear about what the “wait for MoQ” position actually costs you, because WebRTC broadcast at real concurrency is solved engineering today, not a research problem. Trembit built Bullpit, a Twitch-style live-streaming platform for financial communities: sub-second WebRTC-based broadcast (via Millicast) to thousands of concurrent viewers, load-tested for the spiky, unpredictable traffic of volatile market sessions, with a dual-backend architecture that scales real-time services independently from community and content services. Sub-second delivery at that concurrency wasn’t the hard part. Designing every interaction on the assumption of sub-second sync was.

That’s the reference point to hold MoQ against. Not “can WebRTC do broadcast” — it demonstrably can — but “will MoQ do it for materially less, and can anyone prove it yet.” Right now the answer to the second half is no.

Where this leaves a roadmap decision. If your cost problem is real and it’s now, fix it with tuning or a hybrid. If you want optionality, run a MoQ pilot on a non-critical surface while it’s free — that’s genuinely the cheapest time to learn the protocol. Just don’t book the savings.

Talk it through with an engineer

Whether your WebRTC bill is a protocol ceiling or a configuration problem is usually answerable in an hour, and getting it wrong costs a quarter of roadmap. Trembit runs WebRTC architecture reviews that map your actual cost drivers — relay ratio, cascade topology, crossover point, where a second delivery stack is quietly duplicating spend — against your real traffic shape, not a vendor’s pricing page. We don’t sell MoQ tooling or media-server licenses, so the read has no side.

Book a free 30-minute call and bring the specific decision: the SFU bill that’s outgrowing revenue, the broadcast feature your board just approved, or the MoQ pilot you’re not sure is worth an engineer’s quarter. We’ll pressure-test it. No deck, no pitch. If your platform is already in trouble rather than just expensive, our WebRTC rescue playbook is the better starting point.