PubNub alternative: 4 options for IoT and realtime
5 min readThe Eventeer team
PubNub is a realtime messaging network. Its SDKs cover web, mobile, game engines, chat and embedded and IoT devices, all connecting to the same network. Its docs describe presence (which clients are subscribed to a channel) and message persistence (stored messages you can fetch later). That makes it a broad pub/sub platform for apps where many clients talk to each other.
Last reviewed: November 2026. People look for an alternative for fit reasons, not features on a checklist. Maybe the real job is “get readings from devices and know they arrived”, not “let users chat”. Or the fleet speaks MQTT. Or the data should live in a cloud you already use. This post walks through four options and when each one fits, including when PubNub is still the right call.
What to look for in a PubNub alternative
The questions that decide it:
- Which protocol do your devices speak? A plain WebSocket, MQTT, or HTTPS changes the shortlist more than anything else.
- Is it device-to-cloud or client-to-client? Telemetry and commands are a different shape from chat and presence between users.
- Do you need acknowledgements per message? A device that loses its link needs to know what to resend.
- Do you need history? Stored, filterable events you can replay after a gap.
- Who operates it? A managed broker, a cloud-provider service, or a hosted hub.
- What sits next to it? Metrics, alerts and webhooks, or just the transport.
The alternatives
Eventeer
Eventeer is a hosted event hub. For devices, it gives you a WebSocket endpoint at /in/d/<listener_key>. Each device connects with a device_id, and a token can be bound to one device. The device sends JSON event frames with a ref, and Eventeer answers with an ack carrying the stored event id. The older connection is closed (code 4409) if the same device connects twice. Online status and last_seen_at are available over the API, and your backend can push a message down an open socket with one REST call.
On the way out, clients can subscribe to a stream over WebSocket and pass since to replay stored events after a gap. Events are stored for your plan’s retention. You can also build metrics, dashboards and “quiet for N minutes” alerts on them. See the IoT devices use case for the full flow.
What it does not do:
- It does not speak MQTT. MQTT, TCP and gRPC ingress are listed as out of scope in the product docs.
- It has no channel presence for end users. Online status exists for devices only.
- Downlink is best-effort: an offline device returns
409 device_offline, and messages are not queued. - Live stream frames are at-most-once, and replay is at-least-once, so clients dedupe by event id.
- Payloads are JSON or UTF-8 text up to 256 KB. No binary frames.
It fits when sockets are plumbing and the product is what you do with the data. For a comparison with another realtime service, see Eventeer vs Pusher.
Ably
Ably describes itself as a serverless WebSocket platform for pub/sub, and publishes products on top of it, such as Chat and LiveObjects. Its presence feature tracks which clients are on a channel, with enter, leave, update and present events. It also offers an MQTT protocol adapter that translates between MQTT and Ably’s own protocol, recommended for devices without a native Ably SDK. The adapter has limits: MQTT 3.1.1 only, subscribing at QoS 0 only, no wildcard subscriptions, and no presence, history or push through MQTT.
Ably fits when you want the same shape as PubNub (channels and presence between many clients) with a different vendor, or when some of your devices need an MQTT path into a pub/sub system.
AWS IoT Core
AWS IoT Core is a cloud-provider service that connects devices to other AWS services. Its docs list MQTT, MQTT over WSS, HTTPS and LoRaWAN as supported protocols. The message broker handles publish and subscribe over MQTT, and HTTPS for publishing. AWS also provides Device SDKs, rules and jobs.
It fits when your backend already lives on AWS, your devices speak MQTT, and you want device data to flow into other AWS services. It is a toolbox, not a single hosted endpoint, so expect to assemble the pieces.
HiveMQ Cloud
HiveMQ Cloud is a fully managed MQTT broker for IoT and connected devices. HiveMQ handles provisioning, scaling, security patches and high availability, and the service is described as 100% compliant with the MQTT specification, with TLS and device authentication and authorization.
It fits when MQTT is the requirement and you want just a broker. Storage, metrics and alerts are not part of what the page describes, so plan to add them elsewhere.
Side by side
| Capability | Eventeer | PubNub | Ably | AWS IoT Core | HiveMQ Cloud |
|---|---|---|---|---|---|
| MQTT from devices | No | Not documented | Partly (adapter, with limits) | Yes | Yes |
| Channel presence | Partly (devices only) | Yes | Yes | Not documented | Not documented |
| Stored history | Yes | Yes (enabled per keyset) | Not documented | Not documented | Not documented |
| Per-event ack on a device WebSocket | Yes | Not documented | Not documented | Not documented | Not documented |
| Embedded/IoT device SDKs | No, plain WebSocket and JSON | Yes (C-based) | Via MQTT adapter | Yes | Not documented |
“Not documented” means the pages listed below do not say, not that the feature is missing.
When to stay with PubNub
Stay if your product is client-to-client: chat and live presence between users. PubNub’s Chat SDKs and presence features are built for that, and Eventeer offers no user presence or chat features. Stay if you already use its embedded C SDK on devices, or its message persistence with a retention that suits you. Moving only makes sense if the job has changed, or if the part you use is mostly “devices send events, and we store and watch them”.
Moving to Eventeer
This applies when your PubNub use is device telemetry and server-to-device commands.
- List your channels, the message shapes devices publish, and the commands your backend sends.
- Create a device listener with
POST /api/v1/listeners("type":"device","auth_mode":"token"). - Issue a token per device with
POST /api/v1/listeners/:key/credentialsand{"kind":"device_token","device_id":"pump-17"}. The secret is shown once. - Change the firmware to open a WebSocket to
/in/d/<listener_key>?device_id=...and send{"type":"event","ref":"r1","data":{...}}, keeping each event until its ack arrives. - Replace command publishes with
POST /api/v1/devices/:id/messages, and handle409 device_offline. - Replace subscribers with a stream (
/out/s/<stream_key>) and usesinceto replay after reconnects. - Run both side by side, then remove the PubNub publish calls.
Check pricing against your fleet size first: always-on devices are mostly a connection-minutes question.
Sources
Every statement about PubNub, Ably, AWS IoT Core and HiveMQ Cloud in this post comes from these pages, last reviewed November 2026.