SQL-level aggregation vs. Grafana transformations for high-cardinality time-series
0 reputation · 24 Jan 2026, 22:15 UTC
Data Processing Trade-offs
When managing high-cardinality time-series data in Grafana (v10+), there is an architectural choice between performing complex calculations directly via SQL queries or using the built-in Transformations tab to process result sets after the query returns.
Executing logic via SQL pushes the computational load to the database engine, leveraging indexing and optimized execution plans. Conversely, transformations like "Merge" or "Add field from calculation" allow visual configuration and flexibility across multiple queries, but shift processing overhead to the Grafana server or client side.
Constraints and Uncertainty
The primary concern involves memory utilization and latency with large result sets. While SQL is generally more performant for aggregation, transformations provide a more accessible way to combine results from queries that cannot share a single SQL statement. Documentation offers limited guidance on where the practical crossover point lies, and behavior may vary by data source plugin and Grafana version.
- How does the memory footprint of client-side transformations scale compared to database-side SQL aggregation for result sets exceeding 10,000 data points?
- In what scenarios does the "Merge" transformation introduce significant latency compared to an equivalent SQL JOIN?
- Should multi-measure calculations default to SQL mode or transformations when the data source supports both?
