Polythings and Azure IoT Hub: what's different
IoT Hub connects devices very well, and leaves the rest to other services. Where we think one platform does better, and where IoT Hub is ahead.
Azure IoT Hub is one of the most common foundations for connected equipment. Pump makers, machinery builders and HVAC companies run their fleets on it, and it does its job well: it connects devices securely, at very large scale. This post is about everything around that job, where we think a single platform does better, and where IoT Hub is ahead.
Polythings isn't available yet. Everything we say about it below is our plan; everything we say about IoT Hub is from Microsoft's documentation, checked on 18 October 2026.
What IoT Hub is
IoT Hub is a connectivity service. Devices connect over MQTT, AMQP or HTTPS; each has an identity, a device twin for desired and reported state, direct methods, and cloud-to-device messages. Messages are routed onward to other Azure services. It is billed in units per hub, each with a daily message quota: the S1 tier allows 400,000 messages per day per unit, and the free tier 8,000 messages per day for up to 500 devices (IoT Hub tiers, pricing).
What you assemble around it
A complete product needs more than connectivity, and on Azure each piece is its own service, with its own setup, pricing and limits:
| You need | On Azure | In Polythings (planned) |
|---|---|---|
| Provisioning | Device Provisioning Service | Included |
| Device certificates | Bring your own CA; Microsoft-managed certificates are in public preview, not recommended for production, and need Azure Device Registry and DPS (overview, status) | Included: managed, under your root, or your own CA |
| Over-the-air updates | Device Update for IoT Hub, priced per device (pricing) | Included, with health gates and rollback |
| Storage and queries | Route to a database or analytics service and run it | Included: open Iceberg tables, SQL, an API |
| Assets and alarms | Build them from other services | Included: assets with time-bound bindings, alarms with an ISA-18.2 lifecycle |
| Predictive maintenance | Build it | Included: health scores and remaining useful life |
None of these is hard on its own. Together they are a platform team: someone has to wire the services, keep them in step, pay for each, and own the result. That is the work Polythings is meant to remove.
Where we think we'll be better
- One product instead of six. One API, one console, one bill, one place to look when a device goes quiet.
- The machine, not the device ID. Devices are bound to the assets they measure, so a pump's history survives a sensor swap. Alarms, metrics and dashboards are written against assets, not device IDs.
- Certificates that look after themselves. Short-lived certificates renewed automatically, issued at the factory, and an inventory that warns you before one expires.
- Your data, in open formats. Telemetry, events and alarms are Apache Iceberg tables that DuckDB, Spark and Snowflake read directly, in a bucket you can own. Leaving doesn't mean exporting.
- Any cloud. Polythings runs in our cloud or yours; you're not tied to one provider's regions and roadmap.
Where IoT Hub is ahead
- It exists. IoT Hub is generally available, backed by Microsoft, and proven with very large fleets. Polythings is in design.
- Azure integration. If your company runs on Azure, with its identity, networking, support and compliance, IoT Hub fits into all of it.
- The edge ecosystem. IoT Edge modules and partners have years of head start.
If you're all-in on Azure and have a team to assemble the pieces, IoT Hub is a sound choice. If you'd rather have the pieces assembled, and keep your data in formats you control, that's what we're building.
Moving from IoT Hub
We're designing endpoints that speak IoT Hub's device protocol, so existing firmware connects without changes, plus a bridge mode to run both side by side. The migration guide shows each step, and the benchmarks page shows what we've measured so far.