Time series analytics has changed dramatically. What used to be simple metric tracking has evolved into event-driven analytics at massive scale, where every data point carries rich context: device IDs, users, tenants, locations, versions, features, and more.
This shift has exposed a hard truth: cardinality and dimensionality, not raw data volume, are the real challenges of modern time series analytics.
A high cardinality database is designed to handle this reality. In this article, we explore what high-cardinality time series really means, why many systems struggle with it, and how CrateDB is purpose-built to handle high and continuously growing cardinality using SQL, without pre-aggregation or architectural complexity.
A high cardinality database is designed to efficiently store and query data with millions or billions of unique values across one or more dimensions.
Low-cardinality dimensions include values such as:
High-cardinality dimensions include:
In real-world systems, cardinality is not static. It grows continuously as new users, devices, tenants, and events are added. A true high cardinality database maintains predictable query performance even as this growth accelerates.
Traditional time series databases were designed for scenarios like infrastructure monitoring:
Modern applications look very different. Today’s time series data often represents events, not just metrics:
Each new dimension multiplies the number of unique combinations that must be indexed, filtered, and aggregated. This is where cardinality explodes.
Some platforms claim "unlimited cardinality". In practice, this is neither accurate nor helpful.
Every system has physical limits, and experienced engineers know this. Over-promising here reduces credibility.
That's why we say CrateDB is designed for very high and continuously growing cardinality, without requiring pre-aggregation, rigid schemas, or query redesign.
What matters is not whether cardinality is theoretically unlimited, but whether:
This is where CrateDB differentiates itself.
Many time series systems are optimized for:
This works well for infrastructure monitoring, but fails for:
In these use cases:
CrateDB treats time series as fully dimensional data, not as a specialized metrics format.
CrateDB exposes time series data through standard SQL, allowing:
Dimensions can be strings, numbers, geo types, or nested JSON attributes. All are first-class query citizens.
There is no custom query language and no need to reshape data to fit a metrics model.
Many systems rely on:
These approaches reduce flexibility and increase operational complexity. CrateDB ingests raw events and makes them queryable in near real time, enabling:
High-cardinality systems are useless if fresh data is slow to analyze.
CrateDB is designed for:
New data is typically available for analytics within milliseconds, even at scale. This makes it suitable for real-time dashboards, alerts, and operational decision-making.
High cardinality stresses:
CrateDB distributes data, indexes, and query execution across nodes automatically. Scaling cardinality follows the same model as scaling volume: add nodes, not complexity. No manual sharding strategies. No application-side routing.
High-cardinality dimensions like tenant_id or customer_id are common in SaaS and platform use cases.
CrateDB supports:
This enables customer-facing analytics where each new tenant adds both data volume and cardinality without breaking the system.
CrateDB is particularly strong in scenarios where dimensions grow continuously and queries are unpredictable:
In all of these cases, questions evolve faster than schemas.
High-cardinality time series analytics is no longer a niche requirement. It is the norm for modern, data-driven platforms.
CrateDB was built for this reality: rich dimensions, continuous growth, real-time queries, and full analytical flexibility using SQL.
If your analytics workload is constrained not by how much data you store, but by how many questions you can ask, CrateDB offers a fundamentally different approach.
Read more about CrateDB for time series data >