Stop Watching Your Metrics Explode: High Cardinality Without the Rewrite
InfluxDB v1 crawls when cardinality hits the roof. HyperbyteDB handles it with columnar storage and ClickHouse—same InfluxQL, no rewrite, no OOM. Here's how.
Every new device, user, session, or container adds tags. That's what telemetry does—it's supposed to tell you who and what is generating each data point. But InfluxDB v1 slows to a crawl when those tag values grow beyond what the aggregation engine can handle. At some point, your dashboards start timing out. Then your writes queue up. Then someone's pager goes off at 2 AM.
High cardinality is not a bug in your setup. It is an architectural limit of the database, and it is one of the most common reasons teams start looking at alternatives.
What cardinality actually means for your monitoring
Cardinality is the number of unique tag-value combinations in your database. If you're monitoring 10,000 containers and each one has a unique container_id tag, your cardinality is at least 10,000—just from that one tag. Add pod_name, service_name, region, and host, and you're quickly into millions of unique tag sets.
InfluxDB v1 was designed for lower-cardinality workloads. As your tag cardinality grows, the inverted index that maps tag values to series explodes. Query performance degrades. Memory usage spikes. Writes back up.
How HyperbyteDB handles it differently
HyperbyteDB doesn't use InfluxDB's TSM storage.Under the hood, it's built on ClickHouse with columnar MergeTree storage and RocksDB for WAL and metadata. That matters for cardinality because columnar databases handle high-dimensional data fundamentally differently.
Columnar storage means queries only read the columns they need. When you're filtering by container_id, ClickHouse reads that column directly—no inverted index traversal, no series scan. Columnar compression means you're not paying the storage cost you'd expect.
You're not limited to low-cardinality tags. Your existing InfluxQL—WHERE container_id = 'abc123', GROUP BY pod_name—just works. The query engine processes those filters through ClickHouse's distributed execution, which handles wide WHERE clauses without the series explosion that kills InfluxDB v1 performance.
What you keep, what changes
If you're running Telegraf or any client that speaks InfluxDB line protocol, you're already speaking HyperbyteDB's language. The /write endpoint accepts the same payload format. Your /query endpoint runs InfluxQL. There is no schema redesign required.
What changes is the ceiling. Your device_id, user_id, session_id, pod_name, container_id tags—keep them all. Tag everything you need to tag. The query engine underneath is built for this.
Two paths
If you're running InfluxDB v1 and feeling the cardinality pressure, you have two paths:
- Rewrite your schema, collapse high-cardinality tags into lower-cardinality dimensions, and hope future queries don't need the granularity you stripped out.
- Point your existing Telegraf configs at HyperbyteDB, keep every tag you've got, and query them with the same InfluxQL you've already written.
The second path doesn't require a migration project. It requires a URL change.
Related reading
Austin
AustinAustin
Running InfluxDB v1 and hitting its limits? HyperbyteDB takes the same line protocol and the same InfluxQL — you change a URL. It’s open source and free to self-host, or HyperbyteDB Cloud runs it for you. See pricing, or request early access.