WebSocket hibernation helps connection density and idle-cost behavior, but it does not change the core Durable Object scaling rule. Durable Objects scale by object identity, not by horizontally replicating one object or making it multi-threaded.
room:a -> DO instance A room:b -> DO instance B room:c -> DO instance C
Cloudflare can run these different object identities independently across its platform. This is why many rooms, users, sessions, or tenants scale well.
room:mega -> one DO -> single-threaded -> limited throughput
If one giant room or one giant tenant becomes the hot path, that object remains the bottleneck because the per-object execution model is still single-threaded.
Cloudflare documentation says each individual object is single-threaded and has a soft limit around 1,000 requests per second, lower if the work is heavier. The same docs allow an unlimited number of separate objects in a namespace.
many rooms, users, or tenants = scales well one giant global room = does not scale infinitely
hibernation helps: - idle connection cost - connection density hibernation does not change: - one object stays single-threaded - same object does not become many replicas
So hibernation is not a horizontal scale-out feature for one object. It is a runtime and cost optimization around long-lived mostly idle connections.
Cloudflare's Durable Object State docs say the WebSocket Hibernation API can support up to 32,768 WebSocket connections per Durable Object, though CPU and memory can reduce the practical limit.
That is a connection-capacity statement, not a guarantee of unlimited message throughput through one object.
DO scaling = shard by object identity not scale-out replicas for the same object
If you need more scale, split the problem into more room IDs, tenant IDs, session IDs, document IDs, or other natural object identities.
Durable Objects scale well when your system naturally shards by identity. They do not scale by turning one object into a replicated multi-threaded cluster.