Welcome to the February edition of What’s New in ClickStack.

Each month, we share the latest updates across ClickStack, from platform enhancements to new features designed to make observability faster, simpler, and more powerful. February brings major improvements to both Cloud and open source, including new query workflows, enhanced metrics exploration, performance optimizations, and expanded alerting options.

A big thank you to our open source contributors, as well as to our users whose feedback helps shape these features and make ClickStack better for everyone.

## New contributors {#new-contributors}

As always, a huge thank you to our open source contributors, including those who jumped in for the first time this month to help improve ClickStack for everyone.

[AdityaPimpalkar](https://github.com/AdityaPimpalkar) [Rajin9601](https://github.com/Rajin9601)[mlsalcedo](https://github.com/mlsalcedo) [themavik](https://github.com/themavik) [Misfits09](https://github.com/Misfits09) [Bre77](https://github.com/Bre77) [alex-clickhouse](https://github.com/alex-clickhouse) [adri](https://github.com/adri) [mxmCherry](https://github.com/mxmCherry) 

If code contributions are not your thing, we welcome documentation improvements, ideas, feature suggestions, bug reports, and general feedback. Every contribution, big or small, helps make the stack better for the entire community.


Interested in seeing how ClickHouse works on your data? Get started with ClickHouse Cloud in minutes and receive $300 in free credits.

Get started today

## External API for ClickHouse Cloud {#external-api-for-clickhouse-cloud}

For many teams, configuration as code is a hard requirement. The [ClickStack API](https://clickhouse.com/docs/use-cases/observability/clickstack/api-reference) has been available in open source for some time, and it has quickly become essential for enterprises that need to manage dashboards and alerts at any scale. This month, we are excited to bring that same capability to ClickHouse Cloud.

With ClickStack resources now available in the ClickHouse Cloud OpenAPI, you can manage dashboards, alerts, sources, and webhooks directly through the Cloud API. Observability configuration can live alongside your application code, flow through CI and CD pipelines, and remain consistent across development, staging, and production environments.

For example, listing all dashboards for a service is now as simple as:

<pre><code type='click-ui' language='bash'>
curl -X GET \
  'https://api.clickhouse.cloud/v1/organizations/{organizationId}/services/{serviceId}/clickstack/dashboards' \
  --user '&lt;keyId&gt;:&lt;keySecret&gt;' \
  -H 'Content-Type: application/json'
</code></pre>

No separate credentials are required. Existing ClickHouse Cloud API keys with the appropriate permissions work out of the box.

This is the first step toward fully automated, production-grade observability workflows in ClickStack. We continue to expand resource coverage and Terraform support is planned. For full details and examples, see the [dedicated announcement](https://clickhouse.com/blog/clickstack-api) and [API reference](https://clickhouse.com/docs/use-cases/observability/clickstack/api-reference).

## ClickStack embedded in ClickHouse {#clickstack-embedded-in-clickhouse}

This month, we made getting started with ClickStack easier than ever. With ClickHouse 26.2, the ClickStack UI is embedded directly in the ClickHouse binary. Download ClickHouse or start a Docker container, open http://localhost:8123/clickstack, and you are ready to explore.

<iframe width="768" height="432" src="https://www.youtube.com/embed/s1MGNcVNvNg?si=KpqkwsVHtU_-1py-" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

This embedded version is designed for local development, learning, and experimentation. It gives you a simple way to visualize your own observability data or even inspect ClickHouse itself using its internal logs and system tables. 

![](/uploads/clickstack_feb2026_image1_3ef1e34fb9.png)

While it is not intended for production deployments, it is a powerful way to understand query performance, diagnose local issues, and explore how your instance behaves, all from a built-in UI that ships with ClickHouse out of the box.

If you are curious how we package the UI directly into the ClickHouse binary without significantly increasing its size, adding only around 4.1 MB, while integrating cleanly into the ClickHouse build system, we recommend reading the full [announcement blog post](https://clickhouse.com/blog/clickstack-embedded-clickhouse).

## Raw SQL tables {#raw-sql-tables}

One of the most consistent pieces of feedback we hear is simple: “I just want to write SQL and chart it.”

From day one, ClickStack has focused on making visualizations easy to build. Line and bar chart builders, number tiles, pie charts (see below), search views, markdown, and guided workflows are all designed to help users create powerful dashboards without needing to write SQL. But every wizard has limits. Simplification makes common tasks fast, yet it can also hide some of the underlying power.

Because ClickStack is powered by ClickHouse, it sits on top of a fully featured, SQL compliant engine with a rich set of [analytical and aggregation functions](https://clickhouse.com/docs/sql-reference/aggregate-functions). That flexibility is one of its biggest strengths. Over the coming months, we will begin exposing native SQL across visualization types, giving users the choice between the builder for convenience and raw SQL for full control.

We are starting with tables. In the table visualization, users can now switch between the default Builder mode and a new SQL mode. From there, you can write a native SQL query directly, including referencing built-in time range parameters for start and end timestamps. 

<blockquote>
<p style="font-size: 15px">
When the chart is added to a dashboard, the time variables are automatically injected, so your query stays dynamic and aligned with the selected time window.
</p>
</blockquote>

This unlocks far more than simply writing longer or more complex queries than the table builder allows. The builder is intentionally opinionated. For tables, it focuses on grouping by a column and calculating metrics across the remaining fields. That works well for common workflows, but it cannot express more advanced analytical patterns.

With raw SQL, users can now join across datasets, correlate signals, and compute derived metrics that span multiple tables. For example, you might join logs to traces to compare total log volume, error counts, and average latency in a single result set.

<pre><code type='click-ui' language='sql'>
WITH
  Traces AS (
    SELECT
      ServiceName,
      avg(Duration) AS avg_duration,
      quantile(0.99)(Duration) AS p99_duration
    FROM otel_v2.otel_traces
    WHERE
      Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
      AND Timestamp < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
    GROUP BY ServiceName
  ),
  Errors AS (
    SELECT
      ServiceName,
      countIf(SeverityText = 'error') AS error_log_count
    FROM otel_v2.otel_logs
    WHERE
      TimestampTime >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
      AND TimestampTime <= fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
      AND SeverityText = 'error'
    GROUP BY ServiceName
  )
SELECT
  coalesce(Traces.ServiceName, Errors.ServiceName) AS ServiceName,
  avg_duration,
  p99_duration,
  error_log_count
FROM Traces
FULL OUTER JOIN Errors
  ON Traces.ServiceName = Errors.ServiceName
ORDER BY ServiceName
LIMIT 200;
</code></pre>

![](/uploads/clickstack_feb2026_image4_27bbe951f5.png)

<blockquote>
<p style="font-size: 15px">
In raw SQL mode, users select just a connection. There's no need to specify a data source, unlike the Query Builder, with users free to query across multiple data sources at once.
</p>
</blockquote>

Or consider a lightweight service map style view. A self JOIN on spans can show request counts between service pairs, total errors, and percentage error rates (also available visually within [our service map feature](https://clickhouse.com/blog/whats-new-in-clickstack-november-2025#service-maps)). This kind of relationship analysis would be extremely difficult to model coherently in a visual builder, but is straightforward in SQL:

<pre><code type='click-ui' language='sql'>
WITH
  ServerSpans AS (
    SELECT TraceId AS traceId,
           SpanId AS spanId,
           ServiceName AS serviceName,
           ParentSpanId AS parentSpanId,
           StatusCode AS statusCode
    FROM otel_v2.otel_traces
    WHERE SpanKind IN ('Server', 'Consumer', 'SPAN_KIND_SERVER', 'SPAN_KIND_CONSUMER') AND
     Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
      AND Timestamp < fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
  ),
  ClientSpans AS (
    SELECT TraceId AS traceId,
           SpanId AS spanId,
           ServiceName AS serviceName,
           ParentSpanId AS parentSpanId,
           StatusCode AS statusCode
    FROM otel_v2.otel_traces
    WHERE SpanKind IN ('Client', 'Producer', 'SPAN_KIND_CLIENT', 'SPAN_KIND_PRODUCER') AND 
    Timestamp >= fromUnixTimestamp64Milli({startDateMilliseconds:Int64})
      AND Timestamp <= fromUnixTimestamp64Milli({endDateMilliseconds:Int64})
  )
SELECT
  ServerSpans.serviceName AS serverServiceName,
  ClientSpans.serviceName AS clientServiceName,
  count(*) * 10 AS requestCount,
  countIf(ServerSpans.statusCode = 'Error') AS error_count,
  round(error_count / requestCount, 3) AS `% error count`
FROM ServerSpans
LEFT JOIN ClientSpans
  ON ServerSpans.traceId = ClientSpans.traceId
  AND ServerSpans.parentSpanId = ClientSpans.spanId
WHERE ClientSpans.serviceName IS NULL
   OR ServerSpans.serviceName != ClientSpans.serviceName
GROUP BY serverServiceName, clientServiceName
ORDER BY serverServiceName, clientServiceName;
</code></pre>

![](/uploads/clickstack_feb2026_image6_5a88b2c3c7.png)

This is the first step toward combining the simplicity of guided builders with the full expressiveness of SQL, giving advanced users the freedom to unlock everything ClickHouse can do. Stay tuned over the following months to see SQL being exposed in other visualizations.

## Metric Attribute Explorer {#metric-attribute-explorer}

ClickStack has long supported OpenTelemetry metrics (similar to Prometheus in concept), stored as separate tables per data type, such as gauges and counters. While this model is flexible and powerful, discovering how to work with metrics and their associated labels has often required a degree of trial and error.

In this release, we have made metric discovery more intuitive. Users typically know which metric they want to plot and can select it using autocomplete as before. Now, once a metric is selected, they can expand an associated attributes panel that displays the labels available for that specific metric. Instead of guessing which labels exist, users can immediately see and select them.


metrics_explorer.mp4


In the example above, we first plot an average of the `k8s.pod.memory.working_set (Gauge)` metric. We're immediately told this has 44 associated attributes. We expand the attributes panel and select the `k8s.deployment.name` label. From there, the label can either be applied as a filter to narrow the chart or added as a group to break the metric down by Kubernetes deployment. In this case, we group by deployment to compare working set size across services.

This streamlined flow removes much of the guesswork from metrics exploration. Users no longer need to manually experiment to discover which labels are available for grouping or filtering. Charting OpenTelemetry metrics becomes a more direct, visual process, focused on insight rather than label discovery.

## Pie charts {#pie-charts}

One of the most frequent requests we receive is for a broader set of visualization types. Expanding charting capabilities has been on our backlog for some time, and over the coming months we will continue closing those gaps, prioritizing the visualizations users ask for most.

Pie charts are one of the more [controversial chart types in analytics](https://www.ataccama.com/blog/why-pie-charts-are-evil), yet they remain a popular choice in observability. While they are not suited to every scenario, they can still be effective for showing proportional breakdowns, such as status codes, error categories, or request distribution across services.

Pie charts are now available in the latest version of ClickStack. To build one, users simply select a metric to define the slice size and then choose a group by field to determine how the slices are segmented. The distinct values of that field form each slice of the chart. As with other visualizations, filters can be applied to narrow the dataset before rendering.

![](/uploads/clickstack_feb2026_image3_c4dfca64e0.png)

Pie charts are supported across traces, logs, and OpenTelemetry metrics, and they benefit from the same [accelerated materialized view support](https://clickhouse.com/docs/use-cases/observability/clickstack/materialized_views) introduced earlier this year. This ensures that even high-volume breakdowns remain responsive and performant.

## Settings for even faster querying {#settings-for-even-faster-querying}

We are constantly looking for ways to improve query performance in ClickStack. Sometimes that means leveraging the [right access patterns](https://clickhouse.com/blog/whats-new-in-clickstack-september-2025#chunking-time-windows) or ensuring users can [exploit features such as materialized views](https://clickhouse.com/docs/use-cases/observability/clickstack/materialized_views). Often, however, it just comes down to ensuring the correct query settings and optimizations are applied when appropriate.

The ClickHouse core team ships performance improvements and new optimizations in every release. Tracking these changes and ensuring ClickStack takes advantage of them is an ongoing priority. Recent updates in ClickHouse have unlocked meaningful performance gains, and we now enable several of these optimizations when appropriate and when they are supported by the underlying ClickHouse version.

The following optimizations are now automatically applied where appropriate.

### Top N Queries {#top-n-queries}

Top N queries are everywhere in observability. “Show me the latest logs.” “Give me the top error messages.” “List the slowest requests.” These patterns typically look like `ORDER BY … LIMIT N`, and they are especially common in log search and ranking-style dashboards.

ClickHouse has recently introduced powerful optimizations that treat Top-N as a first-class query pattern. In 25.12, support for skip-index-driven Top-K filtering was added via the `use_skip_indexes_for_top_k` setting. This allows ClickHouse to use min/max metadata from data skipping indexes to eliminate entire granules before any rows are read. Instead of scanning a full table and then sorting, the engine can prune large portions of data up front. In benchmarks for ClickStack, this has delivered 2x to 3x improvements for typical log search style queries, and in some cases much more.

<iframe width="768" height="432" src="https://www.youtube.com/embed/SyayPSrsAhI?si=bfzOoxai7rGHPZqB" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

ClickStack now enables `use_skip_indexes_for_top_k = 1` by default when supported, along with `query_plan_max_limit_for_top_k_optimization` (set to `100000`) to allow the optimization to kick in for sufficiently large result scans. When the `ORDER BY` aligns with the table’s ordering key, pruning is highly effective because granules can be skipped purely based on metadata.

<blockquote>
<p style="font-size: 15px">
When the sort column is not part of the ordering key, ClickHouse can still apply a dynamic Top-N threshold during execution, skipping granules that cannot improve the result set via <code>use_top_k_dynamic_filtering = 1</code>, delivering up to 2x improvements in some real-world log searches depending on data distribution and predicates; however, this is <strong>not yet enabled</strong> globally in ClickStack because features such as Event Patterns rely on functions like <code>rand()</code> that are incompatible with the optimization. We plan to enable it selectively in the near future.
</p>
</blockquote>

These settings turn many Top-N queries into a metadata pruning problem rather than a full table scan. As datasets grow and cold cache scenarios become more common, avoiding unnecessary reads at the granule level becomes increasingly impactful, and ClickStack now takes advantage of this automatically.

For a deep dive on these features, we recommend our [dedicated blog post.](https://clickhouse.com/blog/clickhouse-top-n-queries-granule-level-data-skipping)

### Faster skip indices {#faster-skip-indices}

ClickStack already relies heavily on ClickHouse [data skipping indexes](https://clickhouse.com/docs/optimize/skipping-indexes/examples) to accelerate common observability workloads. Bloom filter indexes power fast text search across logs. Minmax indexes are widely used to accelerate numeric range queries, especially on timestamps and other high cardinality fields. Users are [encouraged to exploit these indices](https://clickhouse.com/docs/use-cases/observability/clickstack/performance_tuning#adding-skip-indices) if they need to perform schema optimization.

Before ClickHouse 25.9, skip indexes such as minmax, set, bloom filter, vector, and more [recently text](https://clickhouse.com/blog/full-text-search-ga-release) were evaluated up front, before any table data was read. This sequential approach had a few important drawbacks. Queries with LIMIT still had to scan the entire index before execution could begin. There was an initial startup delay while index analysis completed. In some cases, scanning the index itself could cost more than processing the data.

ClickHouse 25.9 introduced streaming evaluation of secondary indexes. Instead of scanning the entire index first, ClickHouse now interleaves index checks with data reads. When the engine is about to read a granule, it first consults the corresponding index entry. If the index shows the granule can be skipped, it is never read. If not, the granule is processed while index evaluation continues for subsequent granules. For LIMIT queries, execution stops as soon as enough rows are found, and both index checks and data reads halt immediately.

This change removes startup delays and avoids unnecessary work. In testing on a 1 billion row table with a bloom filter index larger than 2 GiB, a simple LIMIT 1 query ran more than 4x faster with streaming indexes enabled, dropping from around 10 seconds to roughly 2.4 seconds.

This feature is controlled by the `use_skip_indexes_on_data_read` setting (defaults to 1 from 25.12) but enforced by ClickStack from 25.9.

Read the [full deep-dive on streaming support for skip indices](https://clickhouse.com/blog/clickhouse-release-25-09#streaming-for-secondary-indices).

### Using skip indices for disjunctions {#using-skip-indices-for-disjunctions}

Prior to 25.12, skip indexes were applied primarily to simple predicates or conjunctions such as AND clauses, allowing ClickHouse to prune granules and reduce unnecessary data reads. Disjunctions, such as OR conditions, did not benefit from index pruning. With newer releases, skip indexes can now also be applied to disjunctive queries, enabling pruning even when queries contain OR logic. 

This behavior is controlled by `use_skip_indexes_for_disjunctions`, which is enabled by default. As a result, ClickStack automatically benefits from improved pruning and reduced data scans for a wider range of real-world query patterns.

### Lazy materializations {#lazy-materializations}

ClickHouse has long relied on layered I/O optimizations such as columnar storage, primary and secondary indexes, projections, and PREWHERE to reduce the amount of data read from disk. Traditionally, once rows passed the WHERE clause, all referenced columns for those rows would be loaded before operations such as sorting, aggregation, or LIMIT were applied. In many analytical queries, especially Top-N patterns, this meant reading large columns that were ultimately unnecessary for producing the final result.

Lazy materialization, introduced in ClickHouse 25.4 and enabled by default, changes this behavior. Instead of eagerly loading all selected columns, ClickHouse defers reading columns until they are actually required by the execution plan. For example, when a query performs an `ORDER BY … LIMIT`, the engine can first determine the top rows using only the ordering column, and only then read the remaining columns for those final rows. This reduces I/O, memory usage, and latency, particularly for wide tables or queries returning a small number of rows from very large datasets. If you're curious as to the internals and looking for a deep dive, we recommend the excellent blog post [“ClickHouse gets lazier (and faster): Introducing lazy materialization”](https://clickhouse.com/blog/clickhouse-gets-lazier-and-faster-introducing-lazy-materialization#speed-without-filters-lazy-materialization-in-isolation).

Since this optimization was default since 25.4, users have been enjoying this for some time. However, this optimization is only applied if the limit is below a specified threshold [`query_plan_max_limit_for_lazy_materialization`](https://clickhouse.com/docs/operations/settings/settings#query_plan_max_limit_for_lazy_materialization). By default, this has a value of 10,000. 

In our own testing against typical ClickStack access patterns for log and trace search, we observed that result sets up to 100,000 rows still benefit significantly from lazy materialization - in large part to [recent changes which make further optimizations to this feature](https://clickhouse.com/blog/clickhouse-release-25-12#what-changed-in-2512). As a result, in the latest version of ClickStack, we increase this threshold to 100,000 to extend the performance gains to a broader range of real-world queries.

## Alerts on number charts {#alerts-on-number-charts}

We continue to expand alerting capabilities in ClickStack. Last year, we introduced [alerts on saved searches and charts](https://clickhouse.com/docs/use-cases/observability/clickstack/alerts). In the latest release, users can now create alerts directly on number charts as well.

This is ideal for simple, static threshold-based alerting. For example, if a number tile represents an error rate, request volume, latency, or any other key metric, you can now trigger an alert when it crosses a defined threshold. The workflow is consistent with existing alerting, making it straightforward to apply to existing dashboards.

metric_alerting.mp4

This is a small but practical addition, and part of a broader effort to make alerting more flexible and powerful. Expect more advanced alerting capabilities in upcoming releases.


Februarys' ClickStack update brings major improvements to both Cloud and open source, including new query workflows, enhanced metrics exploration, performance optimizations, and expanded alerting options.

large_clickstack_feb2026_image2.png

medium_clickstack_feb2026_image2.png

small_clickstack_feb2026_image2.png

thumbnail_clickstack_feb2026_image2.png

clickstack_feb2026_image2.png

What's new in ClickStack. February '26.

## TLDR; {#tldr}

With 26.2, we are introducing a new distribution method: ClickStack UI embedded in ClickHouse. The ClickStack UI is now distributed and embedded directly in the ClickHouse binary, making it easy to experiment with observability on your local instance, explore your own datasets, and even inspect ClickHouse itself.  Simply navigate to https://localhost:8123, select "ClickStack", and start exploring.

## Introduction {#introduction}

Historically, ClickStack has been available through Docker-based distributions. You can run the [full stack in a single container](https://clickhouse.com/docs/use-cases/observability/clickstack/deployment/all-in-one) for testing and experimentation, or deploy [each component independently](https://clickhouse.com/docs/use-cases/observability/clickstack/deployment/hyperdx-only) when moving to production - running the UI, collector, and ClickHouse separately using [tools such as Helm](https://clickhouse.com/docs/use-cases/observability/clickstack/deployment/helm).

More recently, [we introduced a managed ClickStack offering](https://clickhouse.com/blog/introducing-managed-clickstack-beta) in ClickHouse Cloud, where we host both the UI and ClickHouse. Users benefit from integrated authentication along with ClickHouse Cloud's separation of storage and compute - enabling both long-term data retention in object storage while allowing independent scaling of compute to minimize the cost per GB.

**From 26.2, we are adding a 3rd option.**

The ClickStack UI now comes embedded in the ClickHouse binary itself. At first glance, embedding a web application into a high-performance C++ database might sound like it would significantly increase the binary size. In practice, we have kept the additional footprint under 4.1 MB, ensuring installation remains lightweight and fast.

This means that installing ClickHouse now gives you ClickStack out of the box. Whether you use Docker, download the binary, or install via your favorite package manager, ClickStack is immediately available. Simply install ClickHouse, navigate to [http://localhost:8123](http://localhost:8123), and select ClickStack from the menu. Within seconds, you can begin exploring your logs, traces, and metrics.

<iframe width="768" height="432" src="https://www.youtube.com/embed/s1MGNcVNvNg?si=vO78XutzyvwGbHZM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

## Built for Exploration and Local Development {#built-for-exploration-and-local-development}

The embedded version of the ClickStack UI  is designed for local exploration, learning, and exploring your own ClickHouse data with an observability UI. It is not intended for production deployments.

This distribution makes it easy to experiment with observability on your local ClickHouse instance, explore your own datasets, and even inspect ClickHouse itself. ClickHouse already exposes rich internal logs and metrics that are invaluable for diagnosing and optimizing performance. The ClickStack UI provides convenient ways to visualize this data and better understand how your instance behaves.

large_clickstack_mar2026_image4.png

medium_clickstack_mar2026_image4.png

small_clickstack_mar2026_image4.png

thumbnail_clickstack_mar2026_image4.png

clickstack_mar2026_image4.png

large_clickstack_mar2026_image7.png

medium_clickstack_mar2026_image7.png

small_clickstack_mar2026_image7.png

thumbnail_clickstack_mar2026_image7.png

clickstack_mar2026_image7.png

large_clickstack_mar2026_image1.png

medium_clickstack_mar2026_image1.png

small_clickstack_mar2026_image1.png

thumbnail_clickstack_mar2026_image1.png

clickstack_mar2026_image1.png

large_clickstack_mar2026_image9.png

medium_clickstack_mar2026_image9.png

small_clickstack_mar2026_image9.png

thumbnail_clickstack_mar2026_image9.png

clickstack_mar2026_image9.png

> The ClickHouse preset dashboard can be useful for diagnosing local issues and performance problems. Users can also search their local logs and build visualizations over system metric tables.

For larger or production deployments, we always recommend running ClickStack components separately.

The embedded version also intentionally omits certain capabilities to keep the distribution size small and the experience simple. There is no persistent state storage so alerting is disabled, as well as dashboard and querying persistence. [Event pattern](https://clickhouse.com/docs/use-cases/observability/clickstack/event_patterns) functionality is also not included to keep the size small as this requires [a WASM Python runtime](https://clickhouse.com/blog/event-patterns-clickstack#how-clickstack-implements-event-patterns).

Some of these limitations may be addressed in the future using approaches such as browser based storage, but for now the focus is simplicity and approachability.

If you plan to operate ClickStack at scale, or require alerting and persistence, the [open source docker versions](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/oss) or [managed cloud](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/managed) offering remain the recommended path.

## The technical challenges {#the-technical-challenges}

For the curious reader, embedding a full web application inside a C++ database binary involved some interesting engineering decisions.

### Assumptions {#assumptions}

Embedding ClickStack inside ClickHouse meant working within a strict set of conditions defined by the core team, reflecting the engineering standards expected of the ClickHouse binary:

1. Adding a [Node.js](http://node.js) dependency to ClickHouse is a non-starter
2. Files must be embedded in the binary, not lingering somewhere in the file system
3. ClickStack should not significantly inflate the binary size

### The Next.js parts {#the-nextjs-parts}

The UI that powers ClickStack, HyperDX, is a Next.js application. For those familiar, Next.js is a full-stack framework that renders pages on the server before serving, meaning that both the frontend and the backend are bundled into an application. It allows you to serve both static pages and dynamic HTML. However, serving dynamic pages without introducing a Node.js dependency would mean rewriting a lot of the Next.js internals. This meant serving dynamic pages was off the table. Luckily, ClickStack heavily uses static pages. There is still React running in the browser, but very little dynamic server-side rendering ever occurs.

ClickHouse has some existing HTML pages,  such as `play.html` for running queries in a WebUI, and `dashboards.html` for some extremely helpful dashboards to see the health of your ClickHouse instance. The `dashboards.html` page even loads some JavaScript!

However, both are a far cry from the complexity of serving a webpack output from a modern full-featured website like ClickStack. I'll get to that complexity in the [Bundling into ClickHouse](/blog/clickstack-embedded-clickhouse#bundling-into-clickhouse) section, but the existing web pages meant we could add an additional handler with just a little custom functionality.

### ClickStack existing variations and connecting to ClickHouse {#clickstack-existing-variations-and-connecting-to-clickhouse}

ClickStack already has a few  dependencies on which it relies for core functionality. The standard application includes Next.js, Express, and MongoDB. Express and MongoDB are primarily used for the CRUD persistence layer for saved searches, dashboards, and sources. The Express server also serves as a proxy for ClickHouse,  while also handling authentication to ensure DB credentials are not leaked to the frontend. It was safe to assume that the Express backend, MongoDB, and a proxy layer would not be available when embedding ClickStack in ClickHouse.

However, there already existed a [demo site](http://play-clickstack.clickhouse.com) with most capabilities we needed; connections stored in session storage, sources persisted in local storage, and ability to query ClickHouse directly without a proxy layer. The only modifications needed would be to adjust all links with the prefix "/clickstack". With this mechanism, we could attempt bundling into ClickHouse.

> We also decided to remove `pyodide`, a WASM Python runtime for the browser used for ClickStack's "Event Patterns" feature, purely because its size would inflate the ClickHouse binary size by more than we are comfortable with.

### Bundling into ClickHouse {#bundling-into-clickhouse}

ClickHouse uses many 3rd-party libraries and manages them via git submodules. This means that updating a version of a dependency is as simple as checking out a specific commit and rerunning the ClickHouse build. This provides us with the basic foundation to ensure that upgrading to a newer ClickStack version is potentially easy if we can provide it as a usable sub-module.

Building ClickHouse requires many dependent tools such as `cmake`, `ccache`, `ninja`, and many more. But NOT Node.js. For the purpose of reducing friction in local development as well as build times, this meant adding a new dependency with rather large implications like [node.js](http://node.js) was not an option. A good alternative is to generate a static bundle upon release and included directly in a git submodule. As we didn't want to clutter the ClickStack repo, this meant creating a new repo that can reproducibly check out a ClickStack version, build the static output, and update the bundle - ideally all automated upon the release of a new ClickStack version.

But we still have an issue - the files are now present in a ClickHouse build, but how can they be embedded?

C++ does have an #embed macro that allows embedding known files as raw bytes rather than as a file. Unfortunately, a feature of [Next.js](http://next.js) is that it outputs seemingly randomized file names, and lots of them. To handle this, we  generate a C++ file on the fly using some `cmake` magic. It does the following:

1. Creates a new file with some static definitions, specifically a struct definition that includes the file name, bytes, and MIME type
2. Find all files in contrib/clickstack/out
3. Sort by name
4. For each file
   1. Gzip the file (to reduce binary size + bytes shipped to browser)
   2. Generate an entry in an array

The generated file is then simply #included. Then, when a request is made to the `/clickstack` HTTP handler, there is a binary search for the file. If it is found, the file is returned with the appropriate MIME type. In the browser, the user must supply some username and password credentials to authenticate against ClickHouse - these are then used to directly query  ClickHouse over HTTP.

![](/uploads/clickstack_mar2026_image3_ab1eabc337.png)

The result is a very lean addition, around 4.2mb embedded directly into the actual binary itself.

## Getting Started {#getting-started}

To try ClickStack embedded in ClickHouse, install ClickHouse as you normally would. You can use the one-line installer:

<pre><code type='click-ui' language='bash'>
curl https://clickhouse.com/ | sh
</code></pre>

Or see the Open Source Quick Start [guide](https://clickhouse.com/docs/getting-started/quick-start/oss) for alternatives.

For this example, we will enable internal logs so you can explore your own ClickHouse instance, including executed queries and resource usage.

After downloading the binary, move to the directory where you want ClickHouse to store its data. Then create a configuration snippet that enables the query and metric logs:

<pre><code type='click-ui' language='bash'>
mkdir -p config.d && echo "&lt;clickhouse&gt;&lt;query_log&gt;&lt;database&gt;system&lt;/database&gt;&lt;table&gt;query_log&lt;/table&gt;&lt;/query_log&gt;&lt;query_thread_log&gt;&lt;database&gt;system&lt;/database&gt;&lt;table&gt;query_thread_log&lt;/table&gt;&lt;/query_thread_log&gt;&lt;query_views_log&gt;&lt;database&gt;system&lt;/database&gt;&lt;table&gt;query_views_log&lt;/table&gt;&lt;/query_views_log&gt;&lt;metric_log&gt;&lt;database&gt;system&lt;/database&gt;&lt;table&gt;metric_log&lt;/table&gt;&lt;/metric_log&gt;&lt;asynchronous_metric_log&gt;&lt;database&gt;system&lt;/database&gt;&lt;table&gt;asynchronous_metric_log&lt;/table&gt;&lt;/asynchronous_metric_log&gt;&lt;/clickhouse&gt;" | sudo tee ./config.d/query_logs.xml &gt; /dev/null
</code></pre>


This appends to the default configuration and enables system log tables.

Start the server and open your browser at [http://localhost:8123/clickstack](http://localhost:8123/clickstack)

<pre><code type='click-ui' language='bash'>
./clickhouse server
</code></pre>

A connection to the local instance is created automatically. If you already have OpenTelemetry data loaded, ClickStack will detect it and create sources automatically. On a fresh installation, you will be prompted to create a source. For this example, create a new **Log Source** that points to `system.query_log`.

![](/uploads/clickstack_mar2026_image8_3e2b3fa28f.png)

> Config: `Name: Query Logs`
> 
> `Database: system`
> 
> `Table: query_log`
> 
> `Timestamp Column: event_time`
> 
> `Default Select: event_time, query_kind, query, databases, tables, initial_user, projections, memory_usage, written_rows, read_rows, query_duration_ms`.*

Save the source. You will be redirected to the search view, where query logs should immediately begin appearing.

At this point, you are observing your own ClickHouse instance.

![](/uploads/clickstack_mar2026_image5_4ac157885b.png)

Feel free to open the play UI at [http://localhost:8213/play](http://localhost:8213/play), run a few queries and watch them appear in ClickStack. With the default selection you can view the execution time, the memory usage and other useful metadata such as the projections used.

We also include a built-in ClickHouse preset dashboard, available from the left navigation menu. It provides insights into query latency and slow queries, highlights the most time consuming query patterns, shows query counts per table, and surfaces key system metrics such as CPU usage, memory consumption, S3 requests, and insert activity. Together, these views give you immediate observability into your ClickHouse instance, powered entirely by the embedded ClickStack UI.

![](/uploads/clickstack_mar2026_image2_42373b1362.png)

To continue exploring ClickStack and learning its features, we recommend trying it with one of our [sample datasets](https://clickhouse.com/docs/use-cases/observability/clickstack/sample-datasets). These include sample [observability data](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/sample-data) from the [OpenTelemetry demo](https://github.com/ClickHouse/opentelemetry-demo), along with examples for [exploring session replay functionality](https://clickhouse.com/docs/use-cases/observability/clickstack/example-datasets/session-replay-demo) and monitoring your [local infrastructure and ClickHouse instance](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started/local-data).

## Conclusion {#conclusion}

With ClickStack now embedded directly in ClickHouse, getting started with observability is as simple as installing the database itself. There is no additional setup, no separate services to run, and no external UI to deploy. Within seconds, you can begin exploring logs, traces, metrics, and even ClickHouse's own internal behavior.

Our hope is that this distribution lowers the barrier to entry and makes it easier to discover the value of ClickStack using your own local datasets. It provides a practical environment for learning the product, running demos, training teams, experimenting with queries, and understanding how ClickHouse behaves during development.

We look forward to seeing how the community uses it, and contributes to its evolution.


With ClickHouse 26.2, the ClickStack observability UI is embedded directly in the binary. Install ClickHouse, open localhost:8123, and start exploring your logs, traces, and metrics - no extra setup required.

large_clickstack_mar2026_image6.png

medium_clickstack_mar2026_image6.png

small_clickstack_mar2026_image6.png

thumbnail_clickstack_mar2026_image6.png

clickstack_mar2026_image6.png

Introducing ClickStack embedded in ClickHouse

Sign up for the newsletter above for updates, and hop on to our #olly-clickstack Slack channel  to ask questions, share feedback, or help shape what we build next.


Welcome to the January edition of What’s New in ClickStack, the open source observability stack built for ClickHouse. Each month, we highlight the latest ClickStack improvements that help teams explore their observability data with more speed, clarity, and confidence.
January was a busy month for ClickStack. We shipped a mix of high-impact improvements that unlock entirely new workloads, alongside smaller changes that are just plain fun to use. As always, we aim to cover the full spectrum. A big thank you to our users for the constant feedback that helps shape these features and make ClickStack better for everyone.

## New contributors

Building ClickStack in the open means it is shaped by the people who use it every day. We are thankful for the continued momentum from the community, and especially for the new contributors who jumped in this month. Your ideas, code, and feedback directly influence where ClickStack goes next and help make it stronger for everyone.

[motsc](https://github.com/motsc), [yeldiRium](https://github.com/yeldiRium), [gyancr7](https://github.com/gyancr7), [gingerwizard](https://github.com/gingerwizard), [adri](https://github.com/adri), [akalitenya](https://github.com/akalitenya)

## Managed ClickStack

Early this month we [announced Managed ClickStack](https://clickhouse.com/blog/introducing-managed-clickstack-beta). Managed ClickStack is our fully managed observability offering built on ClickHouse Cloud, designed for teams that want ClickStack’s performance and scale without operating the underlying infrastructure. This delivers the same fast queries across logs, metrics, traces, and session data that our open source users enjoy, while fundamentally changing the cost model for observability. 

By pricing on just compute and storage, rather than events, hosts, or users, Managed ClickStack lets teams ingest and retain full-fidelity, high-cardinality data at massive scale, with total costs measured in cents per gigabyte per month. Separation of storage and compute means ingest and query workloads scale independently, so you only pay for the resources you actually use.

![managed_clickstack.png](/uploads/managed_clickstack_6a0350499a.png)

More importantly, Managed ClickStack reflects where we believe observability is headed. By running ClickStack on ClickHouse Cloud, we can unlock long-term retention on low-cost object storage, elastic compute for investigations and alerts, and a foundation for consolidating observability with analytics and other workloads. 

![clickstack-architecture.png](/uploads/clickstack_architecture_b0aea63687.png)

This aligns with our broader view that observability is ultimately a data problem, and one best solved on a platform built for large-scale analytical workloads. If you want to go deeper on the vision and economics behind Managed ClickStack, check out our [launch post introducing the beta](https://clickhouse.com/blog/introducing-managed-clickstack-beta).


Interested in seeing how Managed ClickStack works for your observability data? Get started in minutes and receive $300 in free credits.

## Better index support

In ClickStack, we are constantly looking for ways to better leverage ClickHouse features, whether they are newly introduced or long-standing capabilities that can be used more effectively. This month is a great example of that approach, with focused investments in improving index support to significantly accelerate query performance on large datasets.

### Improving bloom filter support

Users running ClickStack for logs and traces are already familiar with how heavily we use Bloom filters to accelerate text search. Bloom filters provide a lightweight skipping index for keyword queries, allowing ClickHouse to avoid scanning large portions of data. 

<blockquote style="font-size: 15px;">
<p>In ClickHouse, Bloom filters are used as skip indices to quickly rule out data blocks that cannot possibly match a query. When data is written, values or derived tokens are hashed and stored in a compact probabilistic structure at the granule level. At query time, ClickHouse checks the Bloom filter before reading a granule. If the filter indicates a value is not present, that granule is skipped entirely. Bloom filters guarantee no false negatives, meaning matching data is never missed, but they may produce false positives, which results in additional granules being scanned. This tradeoff allows ClickHouse to significantly reduce IO and CPU for text and high cardinality searches while keeping index size relatively small.</p>
</blockquote>

Until now, ClickStack used the [tokenbf_v1 index](https://clickhouse.com/docs/optimize/skipping-indexes/examples#token-bloom-filter-tokenbf-v1-for-word-based-search) for log body searches. This index pre-tokenizes text by splitting on non-alphanumeric characters and stores the resulting tokens in a Bloom filter. While convenient, it exposed several tuning parameters that were difficult to reason about in practice. Users had to choose the filter size, number of hash functions, random seed, and granularity. Although a granularity of 8 generally worked well, the other parameters often required trial-and-error or direct assistance from ClickHouse experts.

In this release, we have now also support the simpler [`bloom_filter`](https://clickhouse.com/docs/optimize/skipping-indexes/examples#generic-bloom-filter-scalar) index combined with explicit tokenization using the [`tokens`](https://clickhouse.com/docs/sql-reference/functions/splitting-merging-functions#tokens) function. This index takes a single optional parameter: the acceptable false positive rate between 0 and 1, with a default of 0.01. Tokenization is handled separately, using the same non alphanumeric splitting behavior by default, but now with the flexibility to adjust tokenization explicitly if needed (this opens some interesting opportunities we plan to explore!).

This change dramatically reduces the tuning surface area. Instead of juggling multiple low level parameters, users now only need to think about granularity and false positive rate. We still recommend a granularity of 8 for log body searches, and for most workloads the default false positive rate is sufficient. When tuning is needed, it becomes much simpler to evaluate values slightly above or below the default and observe the impact on query performance.

<blockquote style="font-size: 15px;">
<p>Note that lowering the false positive rate too aggressively, with the aim of skipping more granules, is not always beneficial. Doing so increases the filter size, which can slow evaluation and increase load times - although this is mitigated somewhat with [recent changes to stream skip indices](https://clickhouse.com/blog/streaming-secondary-indices). Allowing slightly higher false positives can actually improve performance by reducing index overhead. The easiest approach is to experiment with values near the default, sticking with the default if no clear improvement emerges.</p>
</blockquote>

The new approach delivers other meaningful gains. At a granularity of 8, index sizes are typically around 15% smaller. Index analysis can be up to 50% faster, and in some datasets pruning selectivity improves by as much as 7x, although this varies significantly with data characteristics. The net result is searches up to 5x faster with far simpler tuning.

As an example, consider the simple example using our playground OpenTelemetry demo dataset, where we search for “Failed to place”:


The above shows an improvement in query performance of around 50%, with pruning more than 4x more effective (1.76m vs 10.66m rows processed) for the `bloom_filter` index. However, note how performance is appreciably better for both vs  using no indexes. 

An astute reader will notice the query syntax has also changed. 

To ensure the index is used, we have updated how text search queries are generated in the ClickStack UI. Previously, ClickStack UI lowercased the log body and query text (we prefer case-insensitive search for logs), relying on implicit tokenization in the Bloom filter.  The UI would also tokenize the query, using `hasToken` function with conjunctions relying on boolean logic e.g. `(((hasToken(lower(Body), lower('Failed'))) AND (hasToken(lower(Body), lower('to'))) AND (hasToken(lower(Body), lower('place')))))`

With the new filter, queries use the `tokens` and `lower` functions at query time, deferring tokenization to ClickHouse, with the `hasAll` function used to check token presence i.e. `hasAll(tokens(lower(Body)), tokens(lower('Failed to place')))`. This ensures the index is used correctly while preserving existing search behavior. 

<blockquote style="font-size: 15px;">
<p>ClickStack automatically checks the index type in use and uses the correct querying approach.</p>
</blockquote>

### Supporting text indices

Bloom filters are still a powerful tool, but they are not without limitations. False positives are unavoidable, and even simplified tuning introduces tradeoffs. For some workloads, especially large-scale log search, inverted indices can offer compelling advantages (although with tradeoffs).

ClickHouse’s inverted text index has undergone significant rework and is now available in beta. Recent improvements have focused on making it viable at large scale, particularly in ClickHouse Cloud on object storage. Internally, the implementation still uses Bloom filters as a lightweight existence check, allowing ClickHouse to skip expensive index evaluation when a term is guaranteed not to be present in a granule.

Our benchmarking on logging datasets has been especially encouraging, with inverted indices outperforming Bloom filters in both selectivity and query latency. 

As a result, ClickStack now supports this index type directly in the UI. Enabling this required further updates to our Lucene-to-SQL compilation pipeline so that `hasAllTokens` is used when a text index is present. Note that the index is responsible for tokenization as well as pre-processing - expressions defined on index creation. For ClickStack, we use the `splitByNonAlpha` function for the tokenizer and `lower` for the pre-processor - thus replicating current search behavior.

```text
INDEX idx_body Body TYPE text(tokenizer = 'splitByNonAlpha', preprocessor = lower(Body))
```

There are a few constraints to be aware of. The [`hasAllTokens`](https://clickhouse.com/docs/sql-reference/functions/string-search-functions#hasAllTokens) function supports a maximum of 64 tokens per call, so longer search terms are split into batches and combined with substring matching. It also requires [`enable_full_text_index`](https://clickhouse.com/docs/operations/settings/settings#enable_full_text_index) to be enabled, which is only available in ClickHouse v25.12 and newer. For this reason, users running OSS deployments need to explicitly enable this setting in their ClickHouse user profile.

Currently, we only support the [`splitByNonAlpha`](https://clickhouse.com/docs/sql-reference/functions/splitting-merging-functions#splitByNonAlpha) tokenizer. If a text index is created with a different tokenizer, ClickStack will fall back to existing search behavior. Exploring additional tokenizers for log search is an area we are actively interested in - such as [`sparseGrams`](https://clickhouse.com/jp/videos/sparsegrams), which has shown [potential for improving text search speed](https://clickhouse.com/blog/clickhouse-release-26-01#text-index-improvements).

As an example, consider our earlier search. Note that we now use the `hasAllTokens` deferring tokenization and lower case to the index:




The query performance is almost 9x faster than the bloom filter for this example, with the volume of data read over 100x less. We would encourage the curious reader to read about the [direct-read optimisations made to achieve this](https://clickhouse.com/docs/engines/table-engines/mergetree-family/textindexes#direct-read), as well as the [caching options on offer for tuning text indices](https://clickhouse.com/docs/engines/table-engines/mergetree-family/textindexes#caching).

Next, we will be benchmarking inverted indices across a wider range of scales and workloads and publishing guidance in our [new performance tuning documentation](https://clickhouse.com/docs/use-cases/observability/clickstack/performance_tuning). While inverted indices can be extremely powerful, they come with additional storage and resource costs, and they may not be the right choice for every workload.

Stay tuned. We will be sharing more data and insights soon as we continue to answer a key question for observability at scale: when do inverted indices make sense?

## Alerts use materialized views

Alerts now benefit directly from materialized views in ClickStack. Last month, we introduced [support for materialized views in ClickStack](https://clickhouse.com/blog/whats-new-in-clickstack-december-2025#materialized-views-arrive-in-clickstack). Any materialized view created in ClickHouse and registered with a source in the ClickStack UI, HyperDX, is automatically used to accelerate aggregation queries throughout the product - including charts, search histograms, and preset experiences. In this release, alerting has been fully integrated into the same query path, allowing alerts to take advantage of those same optimizations.

Materialized views represent a natural fit to power alerting. Alerts almost always query recent data, while materialized views perform aggregations at insert time, shifting work from query execution to ingestion. As data is inserted, aggregate states are computed and stored in a much smaller target table, making subsequent aggregation queries dramatically faster. By exploiting materialized views, alert evaluations become lightweight and efficient, even at high alert volumes.

![accelerated_clickstack.png](/uploads/accelerated_clickstack_f899326c47.png)

The result is that users can safely run hundreds or even thousands of alerts with minimal impact on overall cluster performance. The cost is paid incrementally at insert time and amortized across all incoming data, keeping per-insert overhead low. When building an alert visualization in HyperDX, users can tell if their alert will be accelerated with an icon showing that a materialized view will be used automatically.

## Some smaller things

Alongside these larger wins around index usage, we continue to ship a steady stream of smaller improvements that make ClickStack easier to use day to day. These changes focus on usability, smoother workflows, and simpler deployment, helping teams get value faster while steadily improving the overall experience.

### Filtering tables with HAVING

Users with a data analytics background will immediately recognize the value of the SQL `HAVING` clause for querying observability data. Unlike `WHERE`, which filters rows before aggregation, `HAVING` allows result sets to be filtered based on aggregate values computed during the query. For example, you might calculate the average latency and 99th percentile per service, then return only those services whose average latency exceeds 100 milliseconds. This pattern is especially useful for reducing large result sets down to something more meaningful and actionable.


The latest version of ClickStack now supports `HAVING` when querying tables in the UI. This allows users to filter results using any aggregate expression, not just raw columns. In practice, this means you can filter by an alias such as `avg_duration > 100`, or define an entirely new aggregate in the filter itself, for example `median(Duration) > 100`, giving you far more flexibility when exploring and refining aggregated results.

![having_table_clickstack.png](/uploads/having_table_clickstack_21e0b63ee7.png)

### Legend filtering

Legend filtering for charts represents a small and thoughtful quality of life improvement for charts. You can now filter time series directly from the chart legend. Clicking a legend item instantly isolates that series in the chart, making it easy to focus on a single signal without touching the query. Click it again, and the chart resets to show everything.


series_filtering.mp4

We added a bit of extra polish here too. By holding Shift, you can select multiple series at once and compare them side by side. All legend entries remain visible, with clear visual cues showing what is selected and what is temporarily dimmed, and the Y axis automatically rescales to fit only the visible data. It is a small feature, but one that makes exploring charts faster, more interactive, and a little more satisfying to use.

### Collector improvements

ClickStack is designed to make getting started with observability as simple as possible. It ships with a pre-configured OpenTelemetry Collector that just works with ClickHouse, with sensible defaults for batching, custom processing, and schema enforcement already in place. 

By default, the collector is orchestrated using OpAMP, which secures the OTLP ingestion endpoint with an ingestion key exposed directly in the UI. Users can copy this key and send data to the collector with the appropriate authorization header, providing a secure and frictionless onboarding experience from the very first event.

As ClickStack has grown, and with the emergence of the managed offering, more users want to run the OpenTelemetry Collector independently of the UI while still benefiting from the ClickStack distribution and its ongoing improvements. To support this, ingestion can now be decoupled from the UI. If the `OPAMP_SERVER_URL` environment variable is omitted or set to an empty value, communication with the OpAmp server is disabled. The collector will continue to run independently, without relying on the UI for configuration.

To secure ingestion in this mode, users can provide an `OTLP_AUTH_TOKEN`. When set, this token is required for all data sent to its OTLP endpoint. This change makes it easier to get started with Managed ClickStack, while also enabling advanced users to operate their own collectors and still take advantage of ClickStack’s standardized processing and schema enforcement.

```sh
# Example command for running the ClickStack OpenTelemetry collector
docker run -e CLICKHOUSE_ENDPOINT=https://myhost:8443 -e CLICKHOUSE_USER="default" - e CLICKHOUSE_PASSWORD="<password>" -p 4317 -p 4318 -e OTLP_AUTH_TOKEN "a_secure_string_value" clickhouse/clickhouse-otel-collector:latest
```

## And finally, a new theme

Users reading the post above regarding Managed ClickStack may have noticed that the HyperDX interface looks a little different! 
With the launch of Managed ClickStack, we took the opportunity to introduce an alternative ClickStack theme. Since ClickStack’s launch, there has been occasional confusion around whether HyperDX is the product or the UI - the UI’s HyperDX branding not helping with this. 
You will increasingly see us refer to the UI as just the “ClickStack UI” - while still acknowledging its original identity as HyperDX. 


new_theme.mp4

The new ClickStack theme, which is used by default in our managed offering, aligns more closely with the broader ClickHouse branding - emphasizing the familiar white, yellow and blacks used across our products. 
Open source users can switch to this theme through user preferences, or keep the original HyperDX look if green is more your style. No hard feelings. Both themes are available in light and dark variants, so you can choose what works best for you.

## Conclusion

That wraps up January for ClickStack. We have some exciting updates coming over the next few weeks, with APIs and RBAC firmly at the top of our roadmap as we continue to focus on making ClickStack easier to integrate and operate at scale. As always, we would love to hear what you want to see next. 


Stay informed on ClickStack feature releases, product roadmap, support, and cloud offerings!

Subscribe to our observability newsletter

January’s ClickStack update brings Managed ClickStack, dramatically faster text search with new indexing options, materialized view powered alerts, and a wave of usability upgrades across the stack.

large_whats-new-clickstack-jan-2026.png

medium_whats-new-clickstack-jan-2026.png

small_whats-new-clickstack-jan-2026.png

thumbnail_whats-new-clickstack-jan-2026.png

whats-new-clickstack-jan-2026.png

What's new in ClickStack. January '26.

We're excited to announce the availability of Managed ClickStack for ClickHouse Cloud in beta. 

Managed ClickStack makes it easier than ever to take advantage of ClickHouse for observability, delivering fast queries and powerful analytics across logs, metrics, traces, and session replays without the overhead of running infrastructure. 

<iframe width="768" height="432" src="https://www.youtube.com/embed/pa_dyNdAHC4?si=GpTwP7UlycCFL_Vp" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>

With market-leading cost efficiency at its core, Managed ClickStack provides a simple path to production-grade observability at any scale - whether you're already using ClickHouse Cloud for real-time analytics or warehousing, coming from [ClickStack Open Source](https://clickhouse.com/clickstack) or just starting to explore the benefits of ClickHouse for observability.

Built on ClickHouse Cloud, Managed ClickStack is priced on infrastructure, not events. Store full-fidelity, high-cardinality OpenTelemetry data indefinitely **for less than three cents per gigabyte per month, with no per-user, per-host, or other extraneous fees**. Scale your logs, metrics and traces without reduced retention periods, sampling or rollups. Scale ingest and query independently, pay only for what you use, and get ClickHouse Cloud reliability out of the box. The result is a managed observability platform that completely changes the economics of observability, while readying users for emerging agentic workloads and consolidating observability with other use cases where it belongs.

![clickstack-ui.png](/uploads/clickstack_ui_cd5b5e7259.png)

<blockquote style="font-size: 15px;">
<p>We remain fully committed to ClickStack Open Source and will continue to invest in new features, performance improvements, and tooling for the community. Users who choose to run ClickStack self-managed will continue to have full access to the same open source foundation that powers Managed ClickStack.</p>
</blockquote>

## Getting started with Managed ClickStack

To get started with Managed ClickStack, new users can begin with a ClickHouse Cloud trial, which includes $300 of credits - enough for about ~10TB of OTel data based on our recommended sizing. Create a service, select ‘ClickStack’ and you’ll be guided through loading your data, with step-by-step instructions provided as part of the onboarding flow.

![clickstack-managed.png](/uploads/clickstack_managed_356c59dc4f.png)

In this initial beta release, Managed ClickStack includes guided ingestion for **OpenTelemetry** and **Vector**, with more options to follow. Users are also free to use any of the supported ClickHouse Cloud ingestion methods. While ClickStack is optimized for OpenTelemetry schemas and provides the fastest path to value out of the box, it is not limited to them. Any event-based data with a timestamp can be ingested and explored in the ClickStack UI (HyperDX). Existing ClickHouse Cloud users can enable ClickStack on new or existing services and follow the same process to start using Managed ClickStack immediately.

## Why we built managed ClickStack

When we [launched ClickStack last year](https://clickhouse.com/blog/clickstack-a-high-performance-oss-observability-stack-on-clickhouse), we did so with the goal of democratizing access to ClickHouse for observability. ClickHouse had already proven itself as an almost de facto store for observability data, showing that columnar databases are a natural fit for the workload - as demonstrated by users already running [observability on ClickHouse at unprecedented scale](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era).

ClickStack set out to make this accessible to everyone by providing a more opinionated, OpenTelemetry-based observability stack with the ClickStack UI (HyperDX) built in. By standardizing on OpenTelemetry and pairing them with a purpose-built UI, ClickStack made it dramatically easier to adopt ClickHouse for logs, metrics, traces, and session replays, and to benefit from the performance and cost advantages of a columnar store without building everything from scratch.

Teams have begun running ClickStack at larger and larger scales, retaining more data, increasing cardinality, and moving away from the sampling and short retention windows that had become the norm in observability. For many users, this shift was transformational, changing the economics of their observability. Meanwhile, we've been busy adding new features and making sure that ClickStack scales better than ever, bringing improved cost efficiency and performance by adding support for [features like materialized views](https://clickhouse.com/blog/whats-new-in-clickstack-december-2025#materialized-views-arrive-in-clickstack).

![clickstack_feb_2026_timeline.png](/uploads/clickstack_feb_2026_timeline_f8a108ea4b.png)

As usage has grown, so has the demand for a managed experience. Many teams want the benefits of ClickStack and ClickHouse without operating the underlying infrastructure themselves. Others are already using ClickHouse Cloud for analytics, warehousing, or AI workloads and wanted to **consolidate observability into the same platform, avoiding data silos and duplication **while unlocking deeper correlation across their datasets - aligning with our vision that **observability is really just another data problem**.

Managed ClickStack is the natural next step in this journey. By running ClickStack on ClickHouse Cloud, we can deliver the same open source foundation with a simpler operational model, and access to capabilities like separation of storage and compute, low-cost object storage for long-term retention, and enterprise-grade reliability and security out of the box. 

While "separation of storage and compute" and "object storage" might seem like implementation details for many, they change the cost economics of observability.

## Changing the cost economics of observability

Most managed observability platforms price around constraints. Some charge per gigabyte ingested. Others rely on more punitive user-based or host-based pricing. In practice, this forces teams to constantly decide what they can afford to monitor, how long they can retain data, and where they need to sample or drop signals to stay within budget. Cost becomes a limiting factor on observability itself.

ClickHouse has [already shown](https://clickhouse.com/user-stories?useCase=2) that this does not need to be the case. With columnar storage and aggressive compression, it is common to achieve 10–15x compression on observability data, while still supporting fast aggregations and high-cardinality queries. This alone fundamentally improves the economics of storing logs, metrics, and traces over long periods of time.

Managed ClickStack takes this a step further. Building on ClickHouse Cloud’s separation of storage and compute changes the pricing model entirely. Observability data is stored in low-cost object storage, with intelligent local and distributed caching handled automatically by ClickHouse Cloud. There are no hot or cold tiers, and no artificial boundaries based on data age. Data is treated consistently regardless of how old it is. What gets cached and queried efficiently is **driven purely by access patterns, not by retention policies**.

![managed_clickstack_architecture.png](/uploads/managed_clickstack_architecture_6a1b359914.png)

This means **retention effectively stops being a meaningful cost dimension**. High-cardinality OpenTelemetry data can be retained for years at **less than a cent per gigabyte per month**, without sampling, rollups, or forced data expiration. Frequently accessed data is cached automatically and queried at low latency. Less frequently accessed data remains fully queryable, with predictable performance and cost.

### Efficient and tunable compute

With storage and retention no longer a cost constraint, the remaining variable becomes compute -  you still need resources to ingest and query data. Here users further benefit from the separation of storage and compute, as ingest and query workloads are fully isolated and can be scaled independently. 

Ingest compute runs continuously to deliver consistent throughput, with each core capable of sustaining up to 20MB/s of writes in our benchmarks. In practice, this translates to users paying less than 1 cent per GB per month for ingest compute.

Meanwhile, independent query compute can be shaped to match how observability data is used. Small, always-on pools can power dashboards and alerts over recent data. Larger pools can be spun up on demand for investigations or historical analysis, then scaled down or idled when no longer needed. Because compute is isolated and elastic, users only pay for query **resources they use** - a concept users coming from cloud data warehousing will be familiar with.

![managed_clickstack_compute_pools.png](/uploads/managed_clickstack_compute_pools_4c2fdab30d.png)

The result is you no longer need to choose between cost, retention, or visibility. You can ingest everything, retain everything, and query everything, while keeping costs transparent and predictable.

## Unifying datastores and unlocking agentic workloads

While cost efficiency is a critical driver for observability, it is only one part of a much larger shift. ClickHouse already powers real-time application analytics and business intelligence workloads at scale. Over time, we believe these datasets will increasingly converge, and that the systems used to store and analyze them will consolidate as well. ClickHouse is uniquely positioned to support this shift.

The ability to correlate observability data with business and application data unlocks powerful new questions. Teams can go beyond detecting incidents to understanding their real impact, such as attributing outages to revenue loss, user churn, or degraded customer experience. Even simpler correlations, joining logs or traces with application or product data, become easier and more efficient when everything lives in a single database.

![clickstack_multiple_usecases.png](/uploads/clickstack_multiple_usecases_e3508350e0.png)

<blockquote style="font-size: 15px;">
<p>In the above, <strong>compute pools are used to service different use cases</strong>, rather than individual query types. For example, you might have a dedicated compute pool for observability and ClickStack workloads, another for real-time analytics, and a separate data warehousing pool that remains idle until needed. Additional workloads can be supported by introducing new compute pools as required. Within each use case, it is also common for multiple compute pools to emerge, each sized and tuned for different workload characteristics. All compute pools can access all of the data for correlation provided access policies permit.</p>
</blockquote>

Separation of storage and compute is also essential in delivering this use case consolidation effectively. Multiple workloads can safely query the same underlying data while using isolated compute resources tuned for their specific needs. Observability, analytics, BI, and investigation workloads no longer need separate systems or duplicated data, reducing both operational complexity and cost.
Historically, asking these complex questions required deep cross-domain knowledge, strong SQL experience and familiarity with multiple datasets - a rare persona for many businesses. However, with the emergence of agentic workloads and AI-driven data interaction, natural language interfaces make it far easier to ask sophisticated cross-domain questions across unified datasets.


hero-1920.mp4

SQL plays a central role here. Large language models already have a strong built-in understanding of SQL and can generate efficient queries with minimal context. SQL remains the most expressive and precise language for querying structured data, making it a natural foundation for [agentic analytics](https://clickhouse.com/blog/agent-facing-analytics). As query volumes increase and latency expectations tighten, ClickHouse’s performance characteristics become even more important.

Looking ahead, we believe this convergence of observability, analytics, and agentic interaction represents a major shift in how teams work with data. As we explore agentic capabilities across ClickStack and the broader ClickHouse Cloud platform, users who consolidate their data and workloads on ClickHouse will be well positioned to take advantage of what comes next. Stay tuned for more announcements in 2026 as we expand our [Agentic Data Stack](https://clickhouse.com/ai) across both ClickHouse Cloud and ClickStack.

## Conclusion


New users can sign up for ClickHouse Cloud, create a service, and connect their telemetry source to their ClickHouse instance, with ClickStack available directly in the console. Existing users can open ClickStack straight from their console immediately on any service.

This beta is the first step toward making Managed ClickStack broadly available. Over the coming months, we’ll expand capabilities, refine defaults, and roll out additional tooling as the offering matures.

We’d love to hear from you as we build. Join the ClickHouse Slack and hop into the [#olly-clickstack channel ](https://clickhouse.com/slack) to share feedback, ask questions, or follow along with updates about anything ClickStack related.


Announcing Managed ClickStack, a fully managed observability platform on ClickHouse Cloud that lets you ingest, retain, and query full-fidelity logs, metrics, and traces at massive scale for a fraction of the cost.

large_managed-clickstack-banner.png

medium_managed-clickstack-banner.png

small_managed-clickstack-banner.png

thumbnail_managed-clickstack-banner.png

managed-clickstack-banner.png

Introducing Managed ClickStack and redefining the economics of observability

When your mission-critical workflows span days, weeks, or even months, every data observability data point counts. That's why we're excited to announce the integration between [ClickStack](https://clickhouse.com/use-cases/observability) and [Temporal Cloud's OpenMetrics endpoint](https://docs.temporal.io/cloud/metrics/openmetrics/), bringing high performance observability to your durable execution platform.

![temporal_dashboard.png](/uploads/temporal_dashboard_ed1d16163e.png)

## What is Temporal?

Temporal is a durable execution platform that helps developers build reliable applications. Temporal lets you focus on business logic rather than writing complex error handling, retry logic, and state management code to survive failures.
Your business logic runs as a Temporal Workflow, whether that means processing payments, orchestrating agents, or managing long-running shopping cart experiences. If a server crashes, the network fails, or a service goes down, Temporal automatically recovers and resumes execution exactly where it left off. No lost progress, no orphaned processes.

### What is ClickStack?

[ClickStack](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started) is a cloud-native observability stack built on ClickHouse for high-performance storage and querying of logs, metrics, and traces. It’s designed for teams dealing with large volumes of telemetry and high-cardinality data, where traditional observability platforms either fall over or become cost-prohibitive.

ClickStack focuses on horizontal scalability, efficient compression, and predictable query performance, even as data volumes grow into the petabyte range. It’s commonly used for log analytics, operational monitoring, and deep investigation of production systems where ingestion rate and retention really matter.

Explore the ClickHouse-powered open source observability stack built for OpenTelemetry at scale.

Get started with ClickStack

ClickStack consists of:

* **HyperDX UI**, a purpose-built frontend for exploring and visualizing observability data
* **A custom-built OpenTelemetry Collector**, with an opinionated schema for logs, metrics, and traces
* **ClickHouse**, the high-performance analytical database at the core of the stack


## Why ClickStack and Temporal Cloud belong together

Running Temporal at scale means managing potentially thousands of concurrent workflows, each with its own activities, timers, and state transitions. When something goes wrong, or when you need to optimize performance, you need to be able to navigate the wealth of observability information coming out of the system.

This is where ClickStack helps. Built on ClickHouse, ClickStack handles the high cardinality metrics that Temporal generates with ease. ClickStack processes queries across Task Queues, Workflow Types, and Namespaces in milliseconds, so you can get to the needle in the haystack quickly.

For teams already running ClickStack, adding Temporal metrics means unified observability. Alternatively, for users running Temporal, ClickStack offers an out-of-box open-source observability solution that users can [get started with in minutes](https://clickhouse.com/docs/use-cases/observability/clickstack/getting-started). Understand how the health of a database affects Task processing backlogs. Track how deployment changes affect Workflow latency. Build dashboards that show the complete picture of your system's health.

## Getting started: Connecting Temporal Cloud to ClickStack

The integration uses the [OpenTelemetry Collector's Prometheus receiver](https://opentelemetry.io/docs/collector/configuration/#receivers) to scrape metrics from Temporal Cloud. [Full instructions on how to set up the integration are available](https://clickhouse.com/docs/use-cases/observability/clickstack/integrations/temporal-metrics), but the gist is once you have a Temporal Cloud API Key that has permission to read metrics, you create the configuration file in the OpenTelemetry Collector like this:


Once deployed, open the ClickStack UI, HyperDX, and navigate to the Metrics explorer. Search for metrics starting with `temporal_cloud` to confirm data is flowing. You can import the [pre-built Temporal dashboard](https://clickhouse.com/docs/use-cases/observability/clickstack/integrations/temporal-metrics#dashboards) and immediately visualize Workflow success rates, Actions consumption against your limits, and Task Queue backlogs.

## What's Next

With Temporal metrics flowing into ClickStack, you can set up alerts on critical thresholds, build custom dashboards for your specific workflow patterns, and correlate workflow performance with the rest of your observability data.

For full configuration details and troubleshooting guidance, check out the[ complete documentation](https://clickhouse.com/docs/use-cases/observability/clickstack/integrations/temporal-metrics).

Your durable workflows deserve scalable observability. With ClickStack and [Temporal Cloud](https://temporal.io/cloud) working together, you get both.


Learn how ClickStack integrates with Temporal Cloud to deliver fast, scalable observability for high-cardinality metrics, helping you spot bottlenecks, debug failures, and understand workflow health in minutes.

large_temporal_clickhouse.png

medium_temporal_clickhouse.png

small_temporal_clickhouse.png

thumbnail_temporal_clickhouse.png

temporal_clickhouse.png

Monitoring Temporal Cloud with ClickStack

## 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\.

The ClickStack Team

Blog posts by The ClickStack Team

What's new in ClickStack. February '26.

Introducing ClickStack embedded in ClickHouse

What's new in ClickStack. January '26.

Introducing Managed ClickStack and redefining the economics of observability

Monitoring Temporal Cloud with ClickStack

ClickStack: A (half) year in review