The word cardinality covers two different costs that arrive on different schedules, which is most of why this failure catches people out. One is the count of distinct series, the product of the distinct values across every dimension the engine indexes [2]. The other, in Postgres, is the physical index, and a composite B-tree stores one entry per row rather than one per distinct combination, so its size tracks rows multiplied by entry width, where that width is the indexed column widths plus per-entry overhead [8].
Take the post's own fleet. Ten thousand assets with a hundred sensors each is a million series, and adding a firmware dimension with ten revisions multiplies that to ten million, so one column created nine million series and not one new row [13]. The same column also widened every index entry on every row already in the table [8]. The nine million is what the planner has to estimate over, and it is why ingest slows before anyone thinks to look at disk. The notation makes the shape plain: (tag_id, value, timestamp) identifies a series by one dimension, while (tag_id, device, location, unit, firmware, value, timestamp) identifies it by five [11].
The post is careful where vendor posts usually are not. It concedes that whether one indexed column really costs more than a million rows depends on the baseline, since the per-row cost scales with the rows you already have [9], and the text available stops mid-sentence at "on a small enough table" without naming the crossover [c9b]. It also frames its remedies as things you can do without leaving Postgres [10], which is a convenient place for a Postgres vendor to land. The mechanism travels anyway, to tags in InfluxDB line protocol and labels in Prometheus, because all three treat each unique combination of indexed attributes as a series of its own [4].
The review approved a column, but what teams actually added was a dimension, and dimensions multiply [3]. The wide table is not the mistake; it stays correct for its whole life when the indexed attribute set is fixed and known up front, which holds for a product with a defined metric set and fails for an industrial fleet where every integration brings a descriptor someone wants to filter on [5].
Two axes will sort most proposed columns before they ship: bounded or unbounded, and filtered-on or display-only. Bounded and filtered belongs on the reading, which is the wide table working as designed [4]. Bounded and display-only belongs in a metadata table. Unbounded and filtered is the expensive quadrant, and it wants bucketing before it wants an index, since a continuously valued tag such as a GPS coordinate has no ceiling at all [6]. Unbounded and display-only should never be indexed at all. The same grid catches the linear case that gets waved through, where a sensor that moves from reporting 0 or 1 to reporting 0 through 100 has taken its dimension from two values to a hundred [12].
The line worth adding to the schema review template asks two things of every new column: how many distinct values it will ever hold, and whether anything filters on it. That is cheaper than an on-call engineer reading EXPLAIN output to work out when the planner stopped using the index [1].
