Every IoT platform comparison runs into the same wall. Nobody publishes a price, the pricing pages say “contact us”, and the one vendor who does publish numbers prices a different thing from everyone else.

This is not evasion, or not only evasion. The same device count can differ by an order of magnitude depending on how often it reports and how long you keep the data. A published number would be wrong for almost every reader.

What you can compare is the model. Here is what actually drives the cost, and which shape of fleet each model suits.

The variables that set the bill

Device count. The obvious one, and rarely the dominant one.

Report frequency. Usually the dominant one, and consistently underestimated. A device reporting every fifteen minutes produces roughly ninety-six times the data of one reporting daily, from identical hardware. On any consumption-based model this is the term that decides the bill, which means collection frequency is a commercial decision as much as an engineering one.

Payload shape. One controller carrying four sensors on four ports produces a quarter of the message count of four single-sensor devices reporting the same parameters. Consolidation at the edge is a cost lever, not just a wiring convenience.

Retention. How long history stays queryable at full resolution, and what happens at the boundary. Many platforms downsample or archive after a window, and the cost of keeping raw data beyond it is where a quote and a renewal diverge.

Seats. How many people log in, and whether read-only viewers count the same as operators. On a fleet with thousands of devices and four users, this term is trivial. On a fleet with two hundred devices and two hundred users at customer sites, it is the whole bill.

Connectivity. Cellular data is a real cost and it belongs in the comparison whether or not the platform includes it. A platform that excludes it is not cheaper, it is quoting a different scope.

Control. Read-only telemetry and two-way control are different commercial products almost everywhere, because control carries different reliability and support obligations.

The four models, and who each one suits

Per device. A fixed charge per connected unit per period. Predictable, easy to forecast, and it stops punishing you for reporting often. It suits fleets that report frequently or carry many sensors per unit. It is the worst fit for a very large fleet of devices that wake once a day, because you pay full freight for a device that generates almost nothing.

Per message. Charges by volume of data ingested. This is how cloud primitives price, and it is excellent for large sparse fleets. It becomes hostile the moment somebody increases collection frequency to debug a problem, and it makes the bill a function of a setting rather than of the estate. If you choose this model, treat report frequency as a change-controlled parameter.

Per seat. Charges by user. Suits an internal deployment with a small operations team and no customer-facing access. It falls apart the moment you give end customers logins, which is exactly what happens when a connected product starts being sold to more than one organisation.

Tiered or bundled. Bands of devices, messages and retention sold together. Easiest to compare across vendors and easiest to be wrong about, because the tier boundary is where the price steps. Ask what happens on the day you cross it, not just what the band costs.

What sits outside the headline number

These are not hidden, but they sit outside the unit being quoted, and they are what reverse a comparison at scale:

How to compare honestly

Take your actual fleet and describe it in one paragraph: how many units, how many sensors on each, how often they report, how long you need the history, how many people log in, and whether you need to send commands as well as read data. Then ask every vendor to quote that same paragraph.

The comparison becomes possible immediately, and the exercise usually reveals something more useful than the price. Most fleets discover that reporting frequency was chosen by default rather than by need, and that a controller collecting hourly and transmitting once a day satisfies the same operational requirement at a fraction of the volume. On battery power that is also the design that lasts years instead of days.

The other thing worth asking, and it costs nothing: what does this cost at three times the size. A model that fits today and breaks at the next tier boundary is a migration you will pay for twice.

Where OmnIoT fits

We quote against the deployment rather than forcing every customer into one model, because a handful of controllers reporting constantly and a few thousand reporting daily are not the same commercial shape and should not pretend to be. OmniCloud models products, subscriptions, rate plans and usage records per account, so what a customer is entitled to and what they have consumed are both answerable from the platform rather than reconstructed at the end of a quarter.

If you are building the comparison, our post on IoT platform versus AWS IoT Core covers what the cloud primitives give you and what they leave you to build, which is the part that dominates total cost far more than the platform line item does.

Write the paragraph describing your fleet and talk to us. We will price that, and tell you where a different model would serve you better.