A time-series database can usually swallow an enormous number of data points without complaint, because points are cheap - they append to the end of a series and compress well. What it struggles with is a large number of distinct series, and that count is called cardinality. A historian that runs beautifully at a million points per second can be brought to its knees by a labeling choice that quietly multiplies the number of series it has to track, and understanding cardinality is the key to seeing that trap before you fall into it.
Series Cardinality in one line: Series cardinality is the number of unique time series a database is tracking, where each series is defined by a distinct combination of its measurement name and its label or tag values. It matters because the cost of a time-series database is driven far more by how many distinct series exist than by how many data points they hold, since each series needs its own index entry and in-memory state. High cardinality - often caused by attaching labels with many possible values, like unique IDs or timestamps - explodes the index and memory footprint, slowing ingestion and queries and, in the worst case, exhausting the database's resources.
In a time-series database a single series is not just a tag name; it is a tag name together with the full set of label or dimension values attached to it. A measurement called temperature is one thing, but temperature with site equal to well-12 and unit equal to celsius is a distinct series, and temperature with site equal to well-13 is another. Every unique combination of the measurement and its labels is its own series with its own identity, its own place in the index, and its own stream of points. Cardinality is simply the total count of those unique combinations across the whole database, and it is the number that most directly governs how much the database has to remember.
The reason cardinality dominates cost is structural. Data points are stored sequentially and compress heavily, so adding more points to an existing series is close to free. But each distinct series needs an entry in the index that maps its label combination to where its data lives, and typically some in-memory state to accept incoming writes. That per-series overhead does not compress away and does not shrink with clever encoding - it scales with the number of series, full stop. A database holding a modest number of points spread across a huge number of series can therefore use far more memory and index space than one holding vastly more points concentrated in few series.
This is why the mental model of a historian as 'a big pile of points' is misleading in the way that matters most for scaling. The points are the easy part. The hard part is the map that lets the database find, among all its series, the ones a query is asking for, and that map grows with cardinality. When people say a time-series database has a scaling problem, they almost always mean a cardinality problem, because that is the dimension where the costs stop being cheap.
A cardinality explosion happens when a label is attached whose set of possible values is large or unbounded, because cardinality multiplies across labels. If a measurement has a site label with 500 values and a unit label with 3 values, that is up to 1,500 series - manageable. Add a label whose value is a unique request ID, a raw timestamp, a customer email, or a full precision coordinate, and each of those labels can take thousands, millions, or effectively unlimited distinct values. The total series count is the product of the per-label cardinalities, so one high-cardinality label does not add to the count, it multiplies it, and the number can jump by orders of magnitude from a single well-intentioned addition.
The most common ways this goes wrong are putting identifiers or continuously varying data into labels. Labels are meant for dimensions you group and filter by - which site, which unit, which measurement type - values that repeat across many data points. When someone instead labels points with something unique per point, like a transaction ID or a high-resolution timestamp, every point spawns its own series, and cardinality equals the number of points, which is the pathological worst case. Embedding free-form or user-generated strings in labels has the same effect, because there is no ceiling on how many distinct values will appear over time, so cardinality grows without bound as new data arrives.
The symptoms of a cardinality problem are distinctive and, once you know them, unmistakable: memory use that climbs relentlessly even though the point-ingestion rate is steady, index structures that balloon out of proportion to the data volume, ingestion and queries that slow as the number of distinct series grows, and eventually out-of-memory failures or refused writes. The fix is design discipline: keep labels to the low-cardinality dimensions you genuinely need for grouping and filtering, and push high-cardinality identifiers into the point's value or a separate field rather than into its series key. Bounding cardinality up front is far easier than clawing it back after an explosion has already bloated the index.
Cardinality is a live concern for SCADA historians precisely because industrial monitoring naturally involves many tags across many sites, and the way tags are named and labeled decides whether that scales gracefully or explodes. An operator with hundreds of remote sites, each with dozens of instruments, already has a large but well-behaved series count as long as the dimensions stay bounded - site, unit, measurement type. The trouble starts when a labeling scheme quietly encodes something unbounded, such as tagging each reading with a per-event identifier, a batch number that never repeats, or a raw device timestamp, at which point the series count stops tracking the number of instruments and starts tracking the number of events, which grows forever.
A cloud SCADA platform such as Merobix consolidates telemetry from many operators and many remote sites into shared historian infrastructure, which makes cardinality discipline a first-class design question rather than an afterthought. The safe pattern is to model the stable, groupable dimensions - which site, which asset, which measurement - as the series-defining labels, and to keep anything with unbounded or per-event values out of the series key so that adding more sites and more history grows the point count, which is cheap, rather than the series count, which is not. That keeps query and ingestion performance predictable as the fleet grows, instead of degrading every time a new high-cardinality dimension sneaks into the naming.
For field operations the payoff is monitoring that scales with the number of assets rather than blowing up with the number of readings. A query that filters to a particular site or asset stays fast because the series count is proportional to real physical things - instruments and sites - not to the endless stream of events those instruments produce. Getting the tag and label model right at the outset, so cardinality reflects the plant rather than the data volume, is what lets a distributed operation add sites and years of history without the historian's index quietly outgrowing the hardware underneath it.
Data points append sequentially and compress heavily, so adding more points to an existing series is nearly free. Each distinct series, however, needs its own index entry mapping its label combination to its data, plus in-memory state to accept writes, and that per-series overhead does not compress away. So a database with modest point volume spread across a huge number of series can use far more memory and index space than one with vastly more points in few series, which is why cardinality drives cost and scaling.
It is caused by attaching a label whose set of possible values is large or unbounded, because total cardinality is the product of the per-label cardinalities, so one high-cardinality label multiplies the series count rather than adding to it. Common culprits are putting unique identifiers, raw high-resolution timestamps, or free-form user-generated strings into labels, which can make the series count grow as fast as the number of data points. Keeping labels to bounded, groupable dimensions prevents this.
Reserve labels for the low-cardinality dimensions you actually group and filter by, such as site, asset, and measurement type, whose values repeat across many points. Push anything with unbounded or per-event values - identifiers, batch numbers that never repeat, precise timestamps, free-form text - into the point's value or a separate field rather than into its series key. Modeling the series around stable physical things keeps cardinality proportional to your assets rather than to your data volume, so the historian scales predictably as history grows.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.