Table of Contents
For a data historian per-tag pricing is a model in which the customer is charged by the number of signals, or tags, it stores. The model made sense when every sensor was expensive, but now that sensors are cheap and plentiful, it turns each new signal into a licensing decision.
What does “tag” mean in a data historian?
In many legacy data historians, a tag is a single measured point: one stream of values from one source, such as a compressor’s temperature or a motor’s current. Each tag is a unique time series, and per-tag licensing counts them.
The same word means something else in many time series databases. In InfluxDB 3 Enterprise, tags are key-value metadata that describe a series, such as the site, line, or asset a reading came from. They add context for filtering and grouping; they aren’t separate measured points.
| Historian tag | InfluxDB tag | |
|---|---|---|
| What it represents | One measured point (a data stream) | Metadata describing a series |
| Example | Compressor 12 discharge temperature | site=Plant A, asset=Compressor 12 |
| What it's used for | Holding the values themselves | Filtering, grouping, and comparing values |
Why were data historians priced per tag?
Historians emerged in the 1980s, when every layer of industrial telemetry was expensive. Sensors cost more to buy, install, and maintain, and they captured fewer readings at lower resolution. Storage and compute were scarce, and historians ran on fixed, on-site hardware. Each additional signal carried real hardware, integration, storage, and compute cost, so teams chose carefully which time series to track, and vendors priced around that choice.
Those economics have since reversed. Microsoft’s 2019 manufacturing trends report puts the average sensor cost at $0.44 in 2018, down from $1.30 in 2004. Bosch reports that microelectromechanical systems (MEMS) sensors have shrunk by a factor of 50 while their power consumption fell by a factor of 100. MQTT, Sparkplug, and cloud pipelines standardized collection. Many historians are still licensed by tag.
How does per-tag pricing shape what teams collect?
Per-tag pricing turns telemetry expansion into a budgeting exercise. Before connecting every built-in sensor on a machine or adding another asset, a team has to decide whether each new signal justifies another licensed tag. In practice, sensors may be installed but left unconnected, diagnostic streams may need extra justification, and data may be filtered before anyone knows what detail will matter later. The question shifts from “What should we monitor?” to “What can we afford to collect?”.
That matters most for machine learning, where models look for predictive signals nobody knew to watch. Workload-based pricing takes a different approach: it ties cost to what a platform actually does, such as ingesting, storing, querying, and moving data. Cost becomes a data engineering decision about sampling rates, retention, and queries.
Per-tag and workload-based pricing compared
| Per-tag pricing | Workload-based pricing | |
|---|---|---|
| Cost driver | Number of tags (measured points) | Data ingested, stored, queried, and moved |
| Adding a sensor | Adds a licensed tag | Adds ingest and storage |
| Main cost lever | Which signals to collect | Sampling rate, retention, query patterns |
InfluxDB prices by capacity or usage rather than tag count: InfluxDB 3 Enterprise is priced by CPU configuration, and InfluxDB Cloud Serverless bills on data in, query count, storage, and data out (InfluxDB pricing).
