## Introduction

It’s hard to believe that ClickStack only [launched in late May last year](https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse). The pace since then has felt more like a full year of product evolution than 7 months. ClickStack has gained [native JSON support](#july:-json-support-arrives), [dashboards import/export](#september:-dashboard-import/export,-custom-collector-config,-and-smarter-queries), [support for Materialized Views](#december:-materialized-views-unlock-new-scalability-limits), performance wins across every layer, [a full alerting system](#october:-alerting,-flexible-event-deltas,-and-dashboard-filters), and the arrival of [features like Service Maps](#november:-what’s-new---service-maps-and-attribute-highlighting).

Alongside the monthly releases, we also [brought ClickStack into ClickHouse Cloud](https://clickhouse.com/blog/announcing-clickstack-in-clickhouse-cloud), marking the first step toward a unified environment where observability and analytics live side by side. And we’re nowhere near done. 2026 will raise the ceiling again with deeper Cloud integration, a fully managed ClickStack experience, AI powered notebooks, anomaly detection, out-of-the-box integrations and even more opinionated defaults that let teams adopt observability with almost no operational effort.   

![image2.png](/uploads/image2_5a6614eac7.png)

This post looks back on our journey from May through December: the **key features** introduced each month as the stack has matured into something far more capable than the version we first announced. This list is in no way exhaustive, rather focusing on those features we’re most proud of.  We’ll close with a look ahead at where we’re investing next and what users can expect from ClickStack in 2026\.

## May: ClickStack is launched

ClickStack began as a response to a clear pattern we had seen for years. Teams at scale such as [Netflix](https://clickhouse.com/blog/netflix-petabyte-scale-logging) and [Anthropic](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era), were already using ClickHouse as the foundation for their observability systems, taking advantage of its ability to store and query wide events with high cardinality and deep context. What they lacked was an opinionated, end to end experience. HyperDX changed that trajectory. When the project open sourced its next generation UI in late 2024, it gave us a modern workflow layer built specifically around ClickHouse strengths: fast search, fast aggregations, and a UI that understands how to construct efficient queries without hiding the power of SQL. Bringing HyperDX and ClickHouse together created an opportunity to offer something the ecosystem had been missing, a complete open source observability stack that embraced OpenTelemetry and delivered logs, metrics, traces, and session replay in one place.  

![image6.png](/uploads/image6_29c07a439b.png)

That vision became real in May with the [launch of ClickStack](https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse). This first release bundled an opinionated OpenTelemetry collector, and a ClickHouse native UI through HyperDX. It delivered a turnkey workflow for ingestion, search, dashboards, and debugging while still giving advanced users full access to SQL and the ability to customize schemas as needed. What started as an integration of proven building blocks quickly became a cohesive product, built around the idea that observability is a data problem best solved by a column store and an experience tailored for it.

Most importantly, ClickStack democratized access to the advantages that only large engineering teams had previously enjoyed. Until now, the full potential of ClickHouse for observability was reserved for organizations that could afford to build custom ingestion paths, schemas, and UI layers. Open-source ClickStack removed that barrier. It delivered a unified experience where the UI, schema, and engine work together by design, offering an observability workflow that finally takes full advantage of ClickHouse performance while remaining open, accessible, and effortless to adopt.

## July: JSON support arrives

Just weeks after launch, July brought [the arrival of native JSON type support](https://clickhouse.com/blog/whats-new-clickstack-july-2025#clickstack-supports-the-json-type-for-faster-queries). JSON had been evolving inside ClickHouse for several release cycles, gradually maturing into a high performance, column aware format that preserves structure and types while enabling sub column pruning. By July, the feature was ready for production workloads, and ClickStack became one of the first large scale use cases to adopt it. Moving from Map based attribute storage to native JSON can unlock dramatic improvements for **some workloads**, including far less I/O, and the ability to work with deeply nested observability data without flattening or manual preprocessing.

![image8.png](/uploads/image8_3716078ef5.png)

Introducing JSON early in ClickStack’s lifetime promises faster queries, more expressive schemas, and an ingestion model that better reflects modern OpenTelemetry data. But the work isn’t done. We **continue to study when JSON is the right choice,** how to pair it with indexing strategies, and how it behaves under high volume observability workloads. **Expect more guidance and benchmarking in the months ahead** as we refine best practices and explore how far JSON can be pushed for real time, high cardinality telemetry at scale.

## August: ClickStack meets ClickHouse Cloud

August marked a major milestone for ClickStack, the debut of the [HyperDX powered UI directly inside ClickHouse Cloud](https://clickhouse.com/blog/announcing-clickstack-in-clickhouse-cloud). This wasn’t just about convenience. It represented the moment ClickStack moved from a self hosted open source experience to a first class, Cloud integrated product. For the first time, users could launch ClickStack with no infrastructure, no separate authentication, and no operational surface area, instantly pairing observability workflows with the same real time warehouse they already relied on for analytics. It opened ClickStack to three key groups: existing ClickStack users running on Cloud who now had one less component to manage, companies migrating large workloads from proprietary observability vendors who needed a cost efficient alternative that didn’t compromise on performance, and application teams already using ClickHouse Cloud for analytics who could now add observability with a single click.

This Cloud integration also made our broader vision tangible, unified observability and analytics in one system. Instead of treating telemetry as a separate silo, ClickStack in Cloud allows teams to join traces, logs, and metrics directly with application data, product events, and operational KPIs. It shifts observability from after the fact diagnosis to a fully correlated analytical workflow where business impact, performance regressions, and customer behavior can all be understood through one engine. At the core of this belief is the principle we’ve stated throughout the year:

**We believe observability is just another data problem.** And that it belongs in the same database as your business-critical analytics. With ClickHouse Cloud, you get the performance of a real-time warehouse, the scale and flexibility of object storage, and now the visibility of a modern observability UI \- all in one stack.

![image9.png](/uploads/image9_3cb6c255b8.png)

Since launching in Cloud, we’ve continued onboarding customers steadily and have gathered feedback from some of the largest organizations using ClickHouse for observability today. These include deeply scaled teams such as [Anthropic](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era) and [character.AI](http://character.AI), whose input has shaped how the UI behaves under high volume, high cardinality workloads. Their use cases have pushed the product further, influencing everything from performance optimizations to workflow simplifications. August wasn’t just a feature release, it was the start of a new chapter where ClickStack became a native part of ClickHouse Cloud and a foundation for the unified observability experience we’ll continue building in 2026\.

Alongside this, we added further [performance improvements](https://clickhouse.com/blog/whats-new-in-clickstack-august#improved-query-efficiency-for-time-based-primary-keys) for scale as well as [early support](https://clickhouse.com/blog/whats-new-in-clickstack-august#inverted-indices-support) for ClickHouse’s [new inverted index](https://clickhouse.com/blog/clickhouse-full-text-search) \-  an effort aimed at improving full text search over log bodies. While still experimental, it’s an area we’re actively still evaluating, and it will remain a focus as we move into January 2026\.

## September: Dashboard import/export, custom collector config, and smarter queries

September introduced one of the most meaningful initial quality of experience improvements in ClickStack: [dashboard import and export](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#importexport-dashboards). This feature gives teams a faster path to value by allowing them to share dashboards internally, version them alongside code, and quickly spin up known good views when onboarding new services or teams. More importantly, it lays the groundwork for a community driven ecosystem of shared dashboards. Throughout the year we’ve been [expanding our documentation with out of the box dashboards for common integrations](https://clickhouse.com/docs/use-cases/observability/clickstack/integration-guides) and getting started scenarios, and we expect import/export to make it easier for users to contribute their own patterns back to the broader ClickStack community. Our hope is simple, dashboards should be as portable and composable as the SQL behind them.

![export_dashboard.gif](/uploads/export_dashboard_e066be3f13.gif)

September also introduced a powerful capability for extending ingestion workflows: [custom OpenTelemetry collector configuration](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#custom-collector-configuration). Users can now layer their own pipelines and receivers on top of ClickStack’s default distribution, which is essential when consuming logs from sources such as Kafka, tailing host files, or adding custom processors. This change not only enables more complex production deployments, it also [underpins the richer integration guides](https://clickhouse.com/docs/use-cases/observability/clickstack/integration-guides) we’ve been publishing, making ClickStack easier to adopt across a variety of environments. 

Alongside ingestion improvements came a major step forward in query performance. We implemented [time window chunking for search](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#chunking-time-windows), allowing ClickStack to fetch recent data first and stop early once enough results are returned. This optimization has since become a foundation for other performance wins, including faster chart rendering and more responsive histogram queries. It’s a clear example of how incremental improvements in September ultimately shaped the performance story of the entire stack.

![5_clickstack_september2025.gif](/uploads/5_clickstack_september2025_a95d9a36de.gif)

Finally, September added support for [custom aggregations](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#custom-aggregations) in the UI, letting users tap directly into the full power of ClickHouse’s aggregation engine. 

## October: Alerting, flexible Event Deltas, and dashboard filters

October marked another major milestone with the introduction of [threshold based alerting in ClickHouse Cloud](https://clickhouse.com/blog/whats-new-in-clickstack-october-2025#alerting-for-clickhouse-cloud). Users can now create alerts directly from either searches or charts, allowing them to monitor latency, error rates, throughput, or any SQL derived metric. The initial release also added built in integrations with PagerDuty and Incident.io along with generic webhooks for custom pipelines. More importantly, this laid the architectural foundation for alerting at serious scale. Alert workloads can run on [dedicated compute through ClickHouse Cloud’s read-write](https://clickhouse.com/docs/cloud/reference/warehouses) separation and compute pool model, which ensures that ingest and analytical queries remain unaffected. It opens the door to thousands of alerts running reliably and independently, with future updates planned to expand to anomaly detection logic with new out-of-the-box destinations.

![image3.png](/uploads/image3_d2a83c9abb.png)

Another highlight of October was the evolution of Event Deltas. Event Deltas have become one of the most distinctive features in ClickStack. At their core, they allow users to select a subset of slow spans, compare them against a baseline population, and automatically surface the attributes and values most associated with the regression. This [offers a lightweight form of anomaly detection at query time](https://clickhouse.com/blog/%20faster-root-cause-for-slow-traces-with-clickstack-event-deltas), rooted in actual distributions rather than heuristics. In October, we made [Event Deltas fully configurable](https://clickhouse.com/blog/whats-new-in-clickstack-october-2025#configurable-event-deltas). Instead of being limited to span duration, users can now build deltas on any numeric field, such as database latency or queue delay. This makes the feature far more flexible and unlocks entirely new investigative workflows.

![image11.png](/uploads/image11_67dbecacf2.png)

We also introduced [dashboard filters](https://clickhouse.com/blog/whats-new-in-clickstack-october-2025#dashboard-filtering), a usability improvement that immediately resonated with users - before users had to type filters. Some observability tools require predefined variables to make filters work, adding friction and setup overhead. In ClickStack, dashboard filtering is as simple as choosing a column. The UI automatically determines the correct filter type and renders it inline. The filter then applies to every visualization on the dashboard that shares the same data source. This allows users to slice and refine dashboards naturally, without configuration work or template engineering. October in many ways embodied the ClickStack approach: powerful features, simple workflows, and an experience that keeps getting faster and more intuitive.Finally, September added support for [custom aggregations](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#custom-aggregations) in the UI, letting users tap directly into the full power of ClickHouse’s aggregation engine. 


clickstack-oct-2025-dashboard_filtering (1).mp4


## November: What’s New - Service Maps and attribute highlighting

November introduced one of the most anticipated features in ClickStack: [Service Maps, now available in beta](https://clickhouse.com/blog/whats-new-in-clickstack-november-2025#service-maps). Service Maps transform trace data into a visual representation of how services interact, allowing teams to understand traffic flows, dependencies, and failure patterns at a glance. Crucially, ClickStack exposes them not only as a dedicated view but also in context. When users inspect an individual trace, a focused service map appears alongside the waterfall, showing the precise path that request took through the system. While the current beta already delivers valuable insight, we plan to accelerate performance and scalability in early 2026. This includes exploring internal ClickHouse capabilities such as refreshable materialized views to support high volume, real time graph construction.

![image7.png](/uploads/image7_c629312677.png)

We also introduced configurable [attribute highlighting](https://clickhouse.com/blog/whats-new-in-clickstack-november-2025#attribute-highlighting), a lightweight but powerful feature for both logs and traces. Users can now define specific fields to surface automatically when inspecting a span or log entry. These appear immediately in the side panel or trace header, making important identifiers, labels, or metadata visible without searching through full attribute payloads. Highlighted attributes can define custom search expressions and can include automatically detected clickable links. This helps teams build opinionated, domain specific debugging workflows that reflect the unique structure of their telemetry.

![image6](/uploads/image6_c99e85f911.png)

Finally, we [added line chart comparison](https://clickhouse.com/blog/whats-new-in-clickstack-november-2025#line-chart-comparisons), a small feature that quickly became a community favorite. With a single toggle, users can overlay the previous period on any time series chart, making regressions or improvements immediately visible without building separate dashboards or calculating offsets manually. It is a simple addition that dramatically improves exploratory analysis and reinforces our focus on delivering fast, intuitive tooling that shortens the path from data to understanding.



Spin up the world's fastest and most scalable open source observability stack, in seconds.

Get started with ClickStack 

line-chart-comparisons.mp4

## December: Materialized views unlock new scalability limits 

December closed the year with the biggest performance leap yet, the [arrival of fully integrated Materialized Views inside ClickStack](https://clickhouse.com/blog/whats-new-in-clickstack-december-2025). While ClickStack had previously allowed users to materialize individual charts, the approach was limited. Any filter or change in grouping pushed the query back to the base table, making performance gains inconsistent. The new design changes everything. Users can now create Incremental Materialized Views directly in ClickHouse, register them with a source, and let ClickStack’s query layer automatically select the most efficient view for each query. The system understands each view’s time granularity, available dimensions, and exposed metrics. At query time, it uses ClickHouse’s `EXPLAIN ESTIMATE` to determine which candidate view scans the fewest granules. This **allows any query in HyperDX - searches, dashboards, histogram views, and charts - to be accelerated** at scale with no additional work from the user.

hyperdx_mv.mp4

This is more than a performance enhancement. It represents a new scalability tier for ClickStack. Incremental Materialized Views compute only changes as data arrives, shifting small amounts of work to ingestion while drastically reducing query depth for downstream workflows. As a result, deployments can maintain near real time responsiveness even at very large volumes. This feature remains in beta, and we plan to refine it through early 2026, including smarter view selection and future support for automatically generated views based on user access patterns. Ending the year with Materialized Views sets the foundation for a new class of performance optimization across the stack, and one of the clearest demonstrations of how ClickStack continues to evolve by using the full power of ClickHouse’s engine.

## Looking ahead to 2026

As we look ahead to 2026, we are focused on making ClickStack the de facto open-source stack for teams operating OpenTelemetry at scale. Many of this year’s foundations from JSON support to Materialized Views will continue to unlock new performance and workflow improvements across the stack. In early 2026, we plan to build directly on these capabilities to deliver even faster dashboards, searches, and histograms for high volume environments.

Two of the most requested features from customers, **RBAC and audit logging**, are also on the way. RBAC will allow administrators to create and manage roles directly inside ClickStack, bringing enterprise grade access control to the full observability workflow. Audit logs will bring better visibility into usage and change tracking, a key requirement for regulated environments and organizations operating at scale.

We are also investing heavily in new analysis experiences. An **AI powered notebook** experience will likely be released in private preview with select users and will offer a streamlined way to explore data, generate queries, and combine observability and analytics in the same workspace. **Anomaly detection** for alerts remains a major priority with the aim to augment threshold based alerting with statistical based models that reduce noise and help teams catch regressions earlier.

Integration work will continue to accelerate. You can expect a growing catalog of pre-built dashboards, tighter getting started guides, and simplified ingestion paths for common environments. We are particularly focused on **CSP integrations**, such as CloudWatch, and making it easier than ever to pull data from Kafka with minimal configuration. Longer term, we plan to improve our support for **Prometheus style metrics**, including the upcoming developments in **PromQL inside ClickHouse**.

But the most significant milestone on the horizon is the shift toward **a fully managed ClickStack offering in ClickHouse Cloud**. Teams will simply send telemetry and get a complete, continuously optimized observability experience powered by ClickStack. It is an ambitious step, but it represents the natural evolution of the platform and the culmination of the vision we started in May \-  observability that is fast, scalable, open, and effortless to adopt. 

Finally, happy new year to all our readers and we look forward to meeting you in events and online in 2026\.

A look back at the later half of 2025 in the world of ClickStack.

large_image12.png

medium_image12.png

small_image12.png

thumbnail_image12.png

image12.png

ClickStack: A (half) year in review

Welcome to the December edition of What’s New in ClickStack, the open-source observability stack built for ClickHouse. Each month, we showcase the latest ClickHouse capabilities and HyperDX UI improvements that help teams explore their data with greater speed, clarity, and confidence.

This release focuses on a single feature that deserves the spotlight: smarter use of Materialized Views throughout the HyperDX UI. While December included many usability refinements, this addition stands apart as a major step forward for performance and scale. Materialized Views can now be created in ClickHouse, linked to a source, and used automatically by the Query Layer to accelerate charts, searches, and dashboards for users at any scale.

## New contributors

Building an open-source observability stack is a collaborative effort, and we are grateful for the continued energy from the community. Thank you to all new contributors this month. Your work helps move ClickStack forward for everyone.

[sgarfinkel](https://github.com/sgarfinkel) [alok87](https://github.com/alok87) [daniellockyer](https://github.com/daniellockyer) [PzaThief](https://github.com/PzaThief)

## Materialized Views arrive in ClickStack

**TLDR;** ClickStack now accelerates visualizations by using ClickHouse Materialized Views, with an intelligent layer that selects the most efficient view automatically for each query issued by the HyperDX UI.

Historically, ClickStack allowed users to materialize a chart. This created a Materialized View behind the scenes, and future queries for that chart would run against the view. In practice, the feature had limited adoption because any applied filter forced the query back to the base table. For most workloads, this meant the performance gain was inconsistent.

Users can now create Materialized Views directly in ClickHouse and register them with a source inside HyperDX. Once a view is attributed to a source, HyperDX understands the views  grouping interval, its available dimensions, and the aggregation metrics it exposes. All views must group data by a time interval such as one minute. Column groupings and metrics are inferred automatically when the view is marked as usable in the source.

![config_mv.png](/uploads/config_mv_2b8da75a05.png)



After an administrator assigns a view to a source, the view becomes available throughout the HyperDX application whenever it can accelerate a query. Multiple views can be attached to a single source, requiring only a small ingestion cost to maintain these Incremental Materialized Views. The application selects views intelligently at query time, giving large deployments a significant query-time performance boost. 

Getting started with the ClickHouse-powered open source observability stack built for OpenTelemetry at scale.


Get started with ClickStack

This feature is currently in Beta. There are a few improvements we’d like to consider before making this feature GA, as well as considering feedback from the community as it's adopted and used in real-world workloads.

> If you're new to ClickStack and aren't aware of ClickHouse’s Incremental Materialized Views, we strongly recommend watching [this short introductory video](https://clickhouse.com/docs/materialized-views).

### How ClickStack chooses the best view

A natural question is how the system chooses between the base table and multiple eligible views. To address this, ClickStack uses the `EXPLAIN ESTIMATE` clause in ClickHouse. When a query is issued, the system asks ClickHouse to estimate the number of granules and the volume of data that would be scanned for each candidate. The view that scans the fewest granules is selected. While this heuristic may not be perfect, it reliably reduces the amount of data scanned and delivers consistently fast responses across a wide range of workloads.

Views remain effective even when charts have filters or when searches include constraints. They can also power histograms, dashboard charts, and filtered visualizations as long as the required dimensions exist within the view.

### A concrete example

Consider two Materialized Views created against our public OpenTelemetry demo data in [sql.clickhouse.com](sql.clickhouse.com) for the traces source. The first `otel_traces_1m` groups by minute `toStartOfMinute(Timestamp)`, `ServiceName`, and `StatusCode`, computing a count of rows as well as the metrics `avg(Duration)` and `max(Duration)`. The second `otel_traces_1m_v2` groups by `toStartOfMinute(Timestamp)`, `ServiceName`, `StatusCode`, and `SpanName`, and computes the same metrics in addition to `quantileTDigest(Duration)`. The latter is larger because it contains more grouping keys and therefore produces more rows.



If a user builds a visualization that shows average duration per service over time by hour, both views are technically valid. ClickStack issues an `EXPLAIN ESTIMATE` query to determine granule counts (and thus less data to scan). The smaller view that groups only by minute, ServiceName, and SeverityText is sufficient, so it is selected. As shown below, the smaller view provides faster performance for the SQL query used to compute the chart. Note how both queries are faster than querying the base table:

> The absolute timing differences here are small, 0.009 seconds for `otel_traces_1m` versus 0.015 seconds for `otel_traces_1m_v2`, and at the scale shown, a few hundred million rows, even the base table query completes in around half a second. At petabyte scale and trillions of rows, however, these seemingly minor gaps compound and become materially significant.

When we actually configure this chart in ClickHouse, you’ll see an acceleration icon indicating the use of a Materialized View. Clicking this shows the view used as well as some useful information, such as the granularity and metrics available, as well as the views that were considered (and discounted). 

On dashboards, you'll also see a small acceleration icon appear on the chart to indicate the use of a view.

![clickstack_accelerated_dashboard.png](/uploads/clickstack_accelerated_dashboard_8fb2ac7fbc.png)

If the dashboard is filtered by `StatusCode`, the same view continues to be used. However, adding a filter on `SpanName` requires the additional dimension, so the second view becomes the required match. The system, however, switches seamlessly with no user intervention.


hyperdx_multiple_mvs.mp4

If the user adds a second metric to the chart (p99), the latter view will also be used. Currently, charts are rendered with a single query, so an accelerating view must satisfy all metrics. In the future, we may make this more intelligent, where specific metrics are handled by different views. Additionally, views are assessed for each query; there is currently no caching layer that determines which views are effective for which queries. For now, we recommend keeping view counts moderate (<10) while in Beta pending the addition of further intelligence and/or caching.



hyperdx_multiple_metrics.mp4

> Note: Views are used across the entire HyperDX application where possible, with view assessment occurring at the query layer. For example, users can use the same capability to accelerate the histogram on the search view for common workflows.

### Why this matters

This feature represents a major milestone for ClickStack. Users now have a flexible mechanism to build performance optimizations that match their workloads. Everything works in open source; users only need to create views and link them to their sources.

It's important to remember that Incremental Materialized Views in ClickHouse compute only the changes to the view as data arrives. This shifts computation to insert time. Since ClickHouse is highly optimized for ingestion, the incremental cost applied to each block is very low compared to the savings at query time. The result is lower operational cost with near real-time performance gains for every downstream chart, search, and workflow - even at petabyte scale.

> This approach is very different from systems that recompute the entire view on each update or schedule periodic updates. For a deep dive into Materialized Views, how they work and how to create them we recommend [this guide](https://clickhouse.com/docs/materialized-view/incremental-materialized-view).

We are excited to build on this foundation throughout 2026. For example, in ClickHouse Cloud, we plan to extend this capability with an intelligence layer that creates views automatically based on user access patterns. 

## Conclusion

As we close out the year and ship our final release of December, we would like to thank all our users and contributors and wish you a happy and successful new year. 

Acceleration with Materialized Views concludes the year, marking a significant step forward for ClickStack and introducing a new level of performance and configurability that enables users to optimize their own workflows. The feature is available today in open source, where teams can define and tune their own views to target the parts of their system that matter most to them. 

While currently in beta, we will publish practical guidance in our documentation shortly to help teams get the most value from it. Looking ahead, in ClickStack and ClickHouse Cloud, we plan to automate the creation of many of these views based on how users actually work, further accelerating everyday experiences with no manual effort. Thank you for being part of the ClickStack community. Here's to an exciting year ahead.



ClickStack’s December update introduces the intelligent use of Materialized Views that automatically accelerate charts and dashboards, delivering faster insights at scale with zero user effort.

large_Whats new in ClickStack December 2031.jpg

medium_Whats new in ClickStack December 2031.jpg

small_Whats new in ClickStack December 2031.jpg

thumbnail_Whats new in ClickStack December 2031.jpg

Whats new in ClickStack December 2031.jpg

What's new in ClickStack. December '25.

Welcome to the October edition of What’s New in ClickStack - the open-source observability stack for ClickHouse. Each month, we combine new ClickHouse capabilities with HyperDX UI enhancements to make observability faster, more intuitive, and more powerful than ever.

This release introduces alerting in ClickHouse Cloud, customizable Event Deltas for greater flexibility, multiline search support, and new dashboard filters for faster investigation. We’ve also enhanced filtering across the HyperDX UI, made Kubernetes dashboards configurable, and delivered another round of performance improvements to keep ClickStack and HyperDX responsive at true petabyte scale.

## New contributors

Building an open-source observability stack is a team sport - and our community makes it possible. A big thank you to this month's new contributors! Every contribution, big or small, helps make ClickStack better for everyone.

>[@datnguyennnx](https://github.com/@datnguyennnx) [@ruudk](https://github.com/ruudk) [@abdussamadbello](https://github.com/abdussamadbello) [@jjh5887](https://github.com/jjh5887)

## Alerting for ClickHouse Cloud

Earlier this week, we announced the arrival of alerting in ClickStack for ClickHouse Cloud, marking a major milestone toward full feature parity with the open-source version. [You can read the full announcement here](https://clickhouse.com/blog/alerting-arrives-in-clickstack-for-clickhouse-cloud), but in summary, alerting is now available directly in the HyperDX UI, enabling teams to create and manage real-time alerts across logs, metrics, and traces without any custom setup or infrastructure management.


![clickstack-oct-2025_0.png](/uploads/clickstack_oct_2025_0_d1c4772fd5.png)

This release brings seamless integrations with Slack, PagerDuty, and webhooks, so teams can be notified instantly about spikes in latency, error rates, or other KPIs stored in ClickHouse. Alerts can be configured as either search-based, using SQL or Lucene queries with thresholds over a defined window, or chart-based, built directly from dashboards with full SQL aggregation support. Together, these options make it easy to go from visualization to proactive monitoring in a few clicks.

Looking ahead, we’re expanding alerting capabilities with additional integrations (including email) and advanced detection logic like anomaly-based alerts. Dedicated compute pools for alert processing are also in exploration, leveraging ClickHouse warehouses to isolate alert workloads at scale.

## Dashboard filtering

The biggest feature this month is a simple but long-awaited one - dashboard filters. This has been one of the most requested capabilities from ClickStack users, and it’s finally here.

While users could always search within dashboards using SQL or Lucene filters, there hasn’t been an easy way to add custom filters for quick, interactive exploration. We wanted to change that, without introducing the complexity found in other observability tools.

Our goal was to make filtering effortless. No variables, no multi-step setup - just select the column you want to filter by, and ClickStack automatically detects the filter type and creates an intuitive widget on the dashboard. At most, you can give it a label.

The result is a smooth, lightweight experience that hides the complexity behind the scenes. As shown below, adding a filter is trivial. Consider the example dashboard below, displaying errors and latency by service name. 

![clickstack-oct-2025-1.png](/uploads/clickstack_oct_2025_1_158d5e97af.png)

An obvious filter for this dashboard is probably the service name. Adding a filter is simple as we show:

## Configurable Event Deltas

Event Deltas are a unique ClickStack feature that automatically surfaces the reason why certain traces are slower than others. Instead of manually filtering, grouping, and comparing spans to find what’s driving latency, Event Deltas dynamically contrast fast and slow traces to reveal which attributes correlate most strongly with performance regressions.

This helps SREs quickly pinpoint the root cause of outliers - whether it’s a new deployment, endpoint, or user segment. This capability is part of the data exploratory workflows of ClickStack, in contrast to approaches that rely on offline analysis with machine learning models and static alerting.

By default, Event Deltas visualize span durations over time using a density heatmap. The x-axis represents time, the y-axis shows duration, and the color intensity indicates the number of spans in each bucket. High-density regions (often yellow or orange) show where spans cluster most tightly, indicating stable performance, while higher bands of sparse color reveal slower spans or performance outliers. Selecting one of these outlier regions automatically triggers a comparison against the baseline dataset, surfacing the attributes most associated with the slower spans -  for example, a specific endpoint, version, or user segment.

![clickstack-oct-2025-2.png](/uploads/clickstack_oct_2025_2_cea5943552.png)

Until now, Event Deltas were limited to analyzing span duration on the y-axis, with color intensity fixed to count. In this release, we’ve added full configurability: users can now choose which field to plot on the y-axis and which metric determines color intensity. This enables far more advanced analyses. For example, exploring relationships between database response times and overall request latency, or visualizing error rates, CPU time, or payload sizes as density drivers.

For example, our public [**ClickPy**](https://clickpy.clickhouse.com) demo, which allows users to analyze Python package downloads, is instrumented with OpenTelemetry. Each chart in the application issues multiple queries to ClickHouse. While the overall request duration is captured in the duration column, we are often more interested in the ClickHouse response time itself. High response times might indicate temporary load on the system, but they could also highlight specific queries that consistently run slower.

The field `db.response_time_ms` within the `SpanAttributes` map stores the query response time. We can now adjust the `value` column for Event Deltas directly by modifying the expression above the density heatmap. To analyze this String value we cast it to a UInt64, allowing Event Deltas to analyze response time instead of span duration.

![clickstack-oct-2025-3.png](/uploads/clickstack_oct_2025_3_04aa304db7.png)

In the resulting visualization, we can clearly see periodic clusters of higher latencies. As before, we can select these regions to perform an Event Delta's analysis and identify which attributes are contributing to this pattern.

![clickstack-oct-2025-4.png](/uploads/clickstack_oct_2025_4_a925659a73.png)

From our analysis we can clearly see it's one specific type of query that is causing these high latencies connected to the visual `getPackageRanking` - this computes how a package ranks within the Python ecosystem for total downloads.

## Filter percentages

Facets in ClickStack show the values available for filtering on each column. Understanding how data is distributed across a facet column is key to fast and intuitive exploration. 

The new **Filter Percentages** feature gives users an immediate sense of how values are distributed for a column within a result set, helping guide analysis and focus attention where it matters most.

Users can now view approximate percentages for each value in a facet, showing how much of the filtered dataset each represents. These percentages are derived from a representative 100,000-row sample using the same efficient sampling method as ClickStack’s log pattern analysis. To keep performance snappy, ClickStack retrieves only the 100 most common values in the sample, assuming the remaining values together make up less than 1% of the data.

clickstack-oct-2025-facet_filters (1).mp4

The result is a lightweight, high-signal view that helps users build intuition about their data before diving deeper. Whether you’re exploring logs by service name, endpoint, or region, filter percentages make it clear where the largest concentrations of activity or anomalies lie - all within the filtering panel.

## Multi-line search

Little things matter. Sometimes, you just need a bit more space. With this update, ClickStack now supports multiline queries - a small but meaningful improvement that makes writing and editing SQL far more comfortable.

While multiline input isn’t common in Lucene search, ClickStack exposes the full power of SQL, where queries often span several lines. Until now, users had to squeeze everything onto a single line, making complex statements harder to read and edit. This simple enhancement removes that frustration and delivers a smoother, more natural query experience.

![clickstack-oct-2025-5.png](/uploads/clickstack_oct_2025_5_7c08000135.png)

## Configurable Kubernetes dashboards

ClickStack has long offered an out-of-the-box Kubernetes experience - making it easy to monitor pods, nodes, and namespaces, and to explore related logs and events. With this release, we’re adding more flexibility by allowing users to configure which log and metric sources power their Kubernetes dashboards.

Previously, the dashboard was tied to the default sources within a connection. Now, users can select any log source, and if a correlated metric source is defined in the configuration, ClickStack will automatically detect and apply it. This enhancement makes it simple to analyze different subsets of Kubernetes data. For example, users often use separate sources and underlying tables for different clusters - whether it be by environment or workload.

![clickstack-oct-2025-6.png](/uploads/clickstack_oct_2025_6_ca5b81bcdd.png)

## Performance improvements

Each month, we continue to refine ClickStack’s performance as usage grows across increasingly large-scale environments. With feedback from users running ClickStack at massive OpenTelemetry volumes, we focus on eliminating bottlenecks and improving responsiveness across queries, charts, and dashboards.

Last month, we introduced request chunking for searches. This breaks long time-range queries into smaller segments that execute from the most recent period first, returning results faster and exiting once enough data is available. 

![ClickStack](https://clickhouse.com/uploads/5_clickstack_september2025_a95d9a36de.gif)

This month, we’ve extended the same concept to **chart rendering**, with impressive gains. Charts now progressively load as data becomes available, reusing cached query chunks across overlapping time ranges. In testing, this reduced total chart-load latency by **up to 25%**, while **average memory usage per query dropped between 18% and 80%**. Most importantly, the time to display initial data (the moment you as a user first sees results), has **improved by up to 95%**, dramatically enhancing perceived responsiveness. These improvements are now available for log and trace charts, with OpenTelemetry metrics support coming soon.

To illustrate this, notice how the chart below incrementally loads once we ask for the visualization over a long 7 day time period.

clickstack-oct-2025-chart_chunking_hyperdx (1).mp4

We also optimized timestamp filtering for data sources that use expressions such as toStartOfDay(Timestamp) in their primary keys. HyperDX now automatically filters on both toStartOfDay(Timestamp) and Timestamp, fully leveraging the primary index. In tests, this change reduced latency by **around 25%**, with potential for even larger gains in complex filter scenarios. The same function is applied to the right-hand side of timestamp comparisons, ensuring precise filtering across narrow time windows. Together, these improvements deliver more consistent query performance and remove the need for manual timestamp configuration in most setups.

Discover the world’s fastest and most scalable open source observability stack, in seconds.

Discover what’s new in ClickStack this month, including event deltas, multiline search, enhanced filtering, and more! 

large_What’s new. October ‘25 (1).jpg

medium_What’s new. October ‘25 (1).jpg

small_What’s new. October ‘25 (1).jpg

thumbnail_What’s new. October ‘25 (1).jpg

What’s new. October ‘25 (1).jpg

What's new in ClickStack. October '25.

Welcome to the September edition of What's New in ClickStack - the open-source observability stack for ClickHouse. Each month, we highlight the latest updates across the stack, combining new ClickHouse capabilities with HyperDX UI enhancements to unlock fresh workflows, smarter visualizations, and a smoother experience.

This release introduces dashboard import/export, support for custom aggregations, and the ability to extend the configuration for the OTel collector. We’ve also delivered several performance improvements, including time-window chunking and better support for gauge metrics with the delta function.

## New contributors

Building an open-source observability stack is a team sport - and our community makes it possible. A big thank you to this month's new contributors! Every contribution, big or small, helps make ClickStack better for everyone.

[@elizabetdev](https://github.com/elizabetdev) [@brandon-pereira](https://github.com/brandon-pereira) [@pulpdrew](https://github.com/pulpdrew)

## Import/export dashboards

One of the most requested features from the community has arrived: you can now import and export dashboards in HyperDX. This makes it easier than ever to share dashboards with teammates or contribute them back to the wider community.

Dashboards can be exported as **versioned JSON files**, ensuring compatibility today while giving us the flexibility to evolve the format and add new functionality in the future. 

Consider the following simple dashboard showing analytics on our [public demo ClickPy](https://clickhouse.com/blog/instrumenting-your-app-with-otel-clickstack). Exporting requires a simple click, producing a JSON file users can share.

![export_dashboard.gif](/uploads/export_dashboard_e066be3f13.gif)


Importing is equally simple. Users can simply create a new saved dashboard and import the JSON file. To ensure portability, when importing a dashboard you’ll need to map its data sources (logs, traces, or metrics) to those already defined in HyperDX, so all visualizations connect correctly.  

![import_dashboard.gif](/uploads/import_dashboard_167dea8e12.gif)

Looking ahead, we believe this feature opens the door to **out-of-the-box experiences**. Expect to see official, ready-to-use dashboards (for example, monitoring NGINX, Kafka, Redis etc) that can be imported directly into your environment. Stay tuned as we begin developing these out in the coming months!


<div class="my-6"><div class="rounded-lg bg-white/10 p-4"><h3 class="text-inherit undefined Typography_suiTitleh3__JlLe2  group/mdHeader toc-ignore" id="test">Get started with ClickStack
</h3><p>Ready to explore the world's fastest and most scalable open source observability stack? Start locally in seconds.</p><a class=" w-full" target="_self" href="https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started?loc=blog-o11y-global-cta&amp;utm_source=clickhouse&amp;utm_medium=web&amp;utm_campaign=blog"><button class="styles_button__3smpn mt-6 w-full font-medium" data-type="primary"><span class="flex items-center whitespace-nowrap">Start exploring</span></button></a></div></div>


## Custom collector configuration

September introduces the ability to **modify the OpenTelemetry Collector configuration** distributed with ClickStack.

ClickStack is built from three core components: **HyperDX** as the visualization layer, **ClickHouse** as the analytics engine that stores and supports querying of observability data efficiently, and an opinionated distribution of the **OTel Collector**. The collector configuration is managed through HyperDX using OpAmp to ensure ingestion remains secure - by requiring the ingestion API key that HyperDX provides in the UI. While this model guarantees security and configuration consistency, it has historically made customization difficult for users.

To extend the configuration, users can now supply their own OTel Collector Yaml, which is merged with the base configuration delivered via OPAMP. The custom file should be mounted into the container at `/etc/otelcol-contrib/custom.config.yaml`.

For example, if you’re deploying ClickStack locally and want to monitor host system metrics or local log files, you previously had to run a second OTel Collector with the right configuration and forward data into ClickStack’s ingestion endpoint provided by its packaged collector. 

With the new extension mechanism, you can simply define the extra receivers you need and mount the file into the container - enabling host metrics and logs to flow into your local deployment with a single command.

A receiver configuration for local monitoring would typically look something like the following. 

> Note that we also need to ensure we have the required pipelines to route the data from our receivers to the clickhouse exporter defined in the base configuration:

<pre><code type='click-ui' language='yaml'>
# local-monitoring.yaml
receivers:
  filelog:
    include:
      - /var/host/log/**/*.log # Linux
      - /var/host/log/syslog
      - /var/host/log/messages
      - /private/var/log/*.log # macOS
      - /tmp/all_events.log # macos - see below
    start_at: beginning # modify to collect new files only

  hostmetrics:
    collection_interval: 1s
    scrapers:
      cpu:
        metrics:
          system.cpu.time:
            enabled: true
          system.cpu.utilization:
            enabled: true
      memory:
        metrics:
          system.memory.usage:
            enabled: true
          system.memory.utilization:
            enabled: true
      filesystem:
        metrics:
          system.filesystem.usage:
            enabled: true
          system.filesystem.utilization:
            enabled: true
      paging:
        metrics:
          system.paging.usage:
            enabled: true
          system.paging.utilization:
            enabled: true
          system.paging.faults:
            enabled: true
      disk:
      load:
      network:
      processes:

service:
  pipelines:
    logs/host:
      exporters:
        - clickhouse
      processors:
        - memory_limiter
        - transform
        - batch
      receivers: [filelog]
    metrics/host:
      exporters:
        - clickhouse
      processors:
        - memory_limiter
        - batch
      receivers: [hostmetrics]
</code></pre>


To include this in the OTel collector, we simply need to mount this file into our container when deploying ClickStack:

<pre><code type='click-ui' language='bash'>
docker run --name clickstack-o11y \
  -p 8080:8080 -p 4317:4317 -p 4318:4318 \
  -v "$(pwd)/local-monitoring.yaml:/etc/otelcol-contrib/custom.config.yaml:ro" \
  -v /var/log:/var/host/log:ro \
  -v /private/var/log:/private/var/log:ro \
  --user 0:0 \
  docker.hyperdx.io/hyperdx/hyperdx-all-in-one
</code></pre>  


> In this example, we also mount paths from our local file system to ensure the collector can read our host log files. This is an **example only** and should not be used in production, as it grants the container root access to read our system metrics and log files.

When we log into HyperDX, we should immediately see our local logs and be able to explore metrics as shown in [our local monitoring guide](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/local-data):

![custom_collector.png](/uploads/custom_collector_c6c3de736a.png)

This simple example highlights how the feature improves the getting-started experience, but the same flexibility is critical at scale. Users may want to pull events from Kafka, open a syslog interface for log ingestion, or configure tail and head sampling for traces. In rare cases, users may even need to adjust the ClickHouse exporter configuration - particularly in high-throughput environments where additional tuning is required.

## Custom aggregations

Historically, HyperDX limited chart building to a small set of common aggregation types. These included min, max, mean, median, and percentiles like the 90th, 95th, and 99th. While they covered most use cases, they constrained more advanced analysis.

With the latest release, users can now unlock the full analytical capabilities of ClickHouse by selecting “none” as the aggregation type. This allows you to directly specify any ClickHouse aggregation function, exposing more than [100 analytical options](https://clickhouse.com/docs/sql-reference/aggregate-functions/reference) for deeper and more flexible exploration of your data.

For example, consider the following visualization, which plots both the average response time and the variance for our ClickPy demo queries. Standard deviation can reveal fluctuations that an average alone might hide. While not exposed as a native option in HyperDX, it can be achieved by selecting “None” and using the [`stddevPop`](https://clickhouse.com/docs/sql-reference/aggregate-functions/reference/stddevpop) function directly as an expression.

![custom_aggregations.png](/uploads/custom_aggregations_fd62b4788f.png)

## Chunking time windows

Previously, HyperDX executed a single query to load search results in the Search view. This was fine for smaller datasets or narrow time ranges, but it became inefficient at scale. Queries scanned the entire time window uniformly, rather than prioritizing resources to the recent data that users typically care about.

With the September release, HyperDX now **chunks query execution by time window**, starting with the most recent data. Subsequent windows are queried only if needed, and once the required number of results is reached, the remaining queries are canceled.

This approach prioritizes resources to deliver the freshest results first, while reducing overall execution time and system load.

![5_clickstack_september2025.gif](/uploads/5_clickstack_september2025_a95d9a36de.gif)

Consider the above query over a four-hour time range. Instead of executing one large query, HyperDX splits it into sub-queries, each covering a smaller window. In this example, each query spans one hour: the first returns three results, the second adds two, and the third adds five. Because the interface only requires ten results, the final query is canceled.

In practice, HyperDX handles much larger time ranges and higher data volumes. By applying this chunking approach to search results, it ensures ClickHouse resources are focused on retrieving the most recent data first.

We are exploring how to apply this technique in other parts of HyperDX. For example, histogram views could be loaded asynchronously in chunks, allowing database resources to deliver quick responses and keep the interface interactive instead of forcing users to wait for results for the entire time range to complete.

## Delta function

The September release also adds support for applying a **delta function to gauge metrics**, matching the behavior of Prometheus’s [`delta()`](https://prometheus.io/docs/prometheus/latest/querying/functions/#delta) function.

A **gauge** is a metric that represents a single numerical value that can move up or down. Typical examples include system temperature, memory usage, or the number of concurrent requests. Unlike counters, which only increase until reset, gauges can fluctuate freely.

The `delta()` function basically aims to show you how much a gauge has changed over a given time window, adjusted so each window is comparable no matter when the samples landed.

The `delta()` function calculates the difference between the first and last value of a gauge within a time range window (the bucket or lookback range) e.g.  `[1m]`. A new bucket is created at each evaluation step, covering the preceding range. 

> Note that the raw difference will be extrapolated to represent the full duration of the bucket, ensuring consistent comparisons across time windows. For example, if a one-minute bucket contains two points 30 seconds apart with a difference of 10, the result is scaled to 20 to represent the full minute.

Since each bucket may contain multiple series (distinguished by attributes such as host or service), multiple delta values can exist per bucket. The aggregation function (such as min, max, or avg) specified by the user is then applied across the deltas to produce the value displayed.

Examples of using `delta()` include tracking changes in pod memory usage. A positive delta consistently above zero indicates a pod’s memory footprint is steadily increasing, which can be an early sign of a memory leak and worth alerting on.

![delta_function_v2.gif](/uploads/delta_function_v2_b3e10f1179.gif)

Consider the metric `k8s.pod.memory.working_set` above for the ClickHouse pod. Plotting the raw gauge value shows the absolute memory usage of a pod. By applying` delta`, you can instead visualize how much memory usage has changed within each interval. A sustained positive delta highlights the pod is steadily consuming more memory over time, while negative deltas indicate memory being released.

<div class="my-6"><div class="rounded-lg bg-white/10 p-4"><h3 class="text-inherit undefined Typography_suiTitleh3__JlLe2  group/mdHeader toc-ignore" id="test">Get started with ClickStack</h3><p>Discover the world’s fastest and most scalable open source observability stack, in seconds.</p><a class=" w-full" target="_self" href="https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started?loc=blog-o11y-global-cta&amp;utm_source=clickhouse&amp;utm_medium=web&amp;utm_campaign=blog"><button class="styles_button__3smpn mt-6 w-full font-medium" data-type="primary"><span class="flex items-center whitespace-nowrap">Try now</span></button></a></div></div>



Discover what’s new in ClickStack this month, including importing and exporting dashboards, custom aggregations, chunking time windows, and more!

large_0_clickstack_september2025.png

medium_0_clickstack_september2025.png

small_0_clickstack_september2025.png

thumbnail_0_clickstack_september2025.png

0_clickstack_september2025.png

What's new in ClickStack. September '25.

July 2025 – ClickStack just got a major upgrade with native JSON support, delivering upto 9x faster queries, type preservation, and effortless handling of deeply nested observability data.

The ClickStack team

Blog posts by The ClickStack team

ClickStack: A (half) year in review

What's new in ClickStack. December '25.

What's new in ClickStack. October '25.

What's new in ClickStack. September '25.

What's new in ClickStack. July '25.