WebSockets vs polling: the cost of real-time updates

Quick answer

Polling repeatedly requests updates (each poll hitting your backend whether or not data changed), so cost scales with polling frequency times clients. WebSockets maintain a persistent connection and push updates only when they occur, so request cost scales with actual events, but each open connection consumes server (or managed-service) resources continuously. For frequent updates to many clients, WebSockets usually win; for infrequent updates or few clients, simple polling can be cheaper and simpler.

Delivering real-time updates to clients has two main approaches, and they trade off differently on cost. Polling has clients repeatedly ask for updates; WebSockets keep a persistent connection over which the server pushes updates as they happen. Which is cheaper depends on update frequency, client count, and whether you run your own connection servers or a managed service.

Polling: cost scales with frequency times clients

Each poll is a request that hits your backend (load balancer, compute, often a database query) whether or not anything changed. Cost scales with polling frequency times the number of clients: a thousand clients polling every five seconds generate 200 requests per second of mostly-empty checks. Frequent polling for near-real-time updates is expensive in wasted requests, the polling-versus-event-driven problem applied to clients.

WebSockets: pay for connections, not polls

	Polling	WebSockets
Request cost	Scales with frequency times clients	Only on actual events
Connection cost	None (stateless)	Each open connection consumes resources
Latency	Up to the poll interval	Near-immediate push
Best for	Infrequent updates, few clients	Frequent updates, many clients

WebSockets eliminate the wasted polls, pushing updates only when they occur, so request-driven backend cost drops sharply for frequent updates. The tradeoff is that each open connection consumes resources continuously, whether on your own connection servers or a managed service like Web PubSub billed per unit of concurrent connections. So you trade per-poll cost for per-connection cost.

Which is cheaper

For frequent updates to many clients, WebSockets usually win: the per-connection cost is less than the flood of polling requests, and latency is better. For infrequent updates, or few clients, simple polling (or its lighter cousin, long-polling or server-sent events) can be cheaper and simpler, since maintaining persistent connections has overhead that infrequent updates do not justify. The crossover is update frequency and client count.

Choosing for cost

Use WebSockets (or a managed real-time service) for frequent updates to many concurrent clients, where eliminating polling requests outweighs the connection cost and the low latency matters. Use polling, or server-sent events, for infrequent updates or modest client counts where persistent connections are overkill. And whichever you choose, do not poll or push more often than the use case needs, since both approaches scale with update rate.

FAQ

Are WebSockets cheaper than polling?

For frequent updates to many clients, usually yes: WebSockets push updates only when they occur, eliminating the flood of mostly-empty polling requests, and the per-connection cost is typically less than that request flood. For infrequent updates or few clients, simple polling can be cheaper and simpler, since persistent connections have overhead that infrequent updates do not justify.

Why is polling for real-time updates expensive?

Because each poll is a request hitting your backend (load balancer, compute, often a database query) whether or not data changed, so cost scales with polling frequency times client count. A thousand clients polling every five seconds generate 200 requests per second of mostly-empty checks, most of which find nothing.

What is the cost tradeoff with WebSockets?

WebSockets eliminate wasted polls, pushing updates only on actual events, so request-driven backend cost drops. But each open connection consumes resources continuously, whether on your own connection servers or a managed service billed per unit of concurrent connections. So you trade per-poll request cost for per-connection cost.

When should I use polling instead of WebSockets?

For infrequent updates or modest client counts, where maintaining persistent connections is overkill and simple polling (or server-sent events) is cheaper and simpler. Persistent connections have overhead that infrequent updates do not justify, so polling suits low-frequency, low-concurrency real-time needs.

Do WebSocket connections cost money when idle?

Yes, in resources. Each open WebSocket connection consumes memory and capacity on your connection servers, or a unit of a managed service billed by concurrent connections, whether or not messages are flowing. So many idle-but-open connections still cost, which is why WebSockets suit active, frequently-updated clients rather than many idle ones.

Does C3X estimate real-time update cost?

The cost difference between polling and WebSockets is in backend requests versus connection capacity, both usage-driven. C3X prices the surrounding infrastructure (compute, load balancers, managed real-time services), and you model update frequency and client count to compare the approaches for your workload.

What to do next

Compare real-time approaches before you build. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.