Most of the demos that we publish at RethinkDB use Socket.io or some other similar WebSocket abstraction layer, catering to cases where the user wants to fully

Most of the demos that we publish at RethinkDB use Socket.io or some other similar WebSocket abstraction layer, catering to cases where the user wants to fully host the entire application from end to end. But scaling a Socket.io application is not trivial, there are users who want a hosted solution for realtime streams so that they don't have to worry about their application falling over if they get too many simultaneous connections. Granted, the case in the blog post is perhaps a bit contrived. But consider, for example, a scenario where you take a single page web application, deploy it to a CDN, and have all the realtime traffic that it accommodates routed through PubNub's infrastructure. You could make it so that no traffic is hitting your own servers, and you are just broadcasting updates into the PubNub stream from your RethinkDB-based backend. That would be pretty trivial to scale. And in terms of the speed at which the messages are routed, for the purposes of a liveblog or something of that nature, pushing everything through PubNub isn't noticeably slower than using Socket.io. Of course, nobody's saying that you should always use PubNub. As I said, we often use Socket.io ourselves. But I do think there is legitimate value in presenting it as an available option.