DEV Community: Kanishga Subramani

CH-Ops Scheduled Alerts: Know Before Things Break

Kanishga Subramani — Sat, 03 Oct 2026 16:42:02 +0000

What is CH-Ops

CH-Ops is a browser-based operations platform built for managing ClickHouse® deployments. Instead of relying entirely on the command line or HTTP APIs, it provides a unified interface for executing SQL queries, monitoring clusters, managing users, backups, alerts, dashboards, and much more, all from a single web application.

One of its useful features is Alert Rules, which lets you turn a SQL query into a scheduled check and notify you when a defined condition is met.

In this walkthrough, we'll use Email (SMTP) as the notification channel and create a simple scheduled alert from the CH-Ops interface. Let's see how you can create, test, and manage alerts without building a separate monitoring script.

Introducing CH-Ops Alert Rules

Monitoring a ClickHouse® cluster is not only about looking at dashboards. Some conditions are easier to detect with a simple query.

For example, you may want to know when:

The number of failed operations goes above a threshold.
A particular metric exceeds an expected value.
A query returns an unexpected result.
A cluster condition needs attention.

Instead of manually running the same query again and again, Alert Rules allows you to schedule the query and define what should trigger an alert. Once the rule is enabled, CH-Ops periodically executes the query and checks its result against the configured condition.

Setting up an email notification channel

Before creating an alert, you need a notification channel that CH-Ops can use to deliver the alert.

You can find this under:

Control Panel → Notification Channels

Click New to create a notification channel.

For this walkthrough, select Email (SMTP) as the notification type. The form provides fields for configuring the email connection:

Field	What it's for
Name	A name to identify the notification channel
SMTP Host	The mail server address used to send the alert
SMTP Port	The port that server listens on
SMTP User	The account CH-Ops authenticates as
SMTP Password	That account's password
From	The sender address
To	The recipient address

Fill in the SMTP details provided by your email service and click Create.

Once configured, the channel can be reused by alert rules instead of configuring email details every time you create a new alert.

After creating an Email (SMTP) notification channel, use its Test button to verify that the configured SMTP details can successfully send a test notification. A successful test confirms that the notification channel is ready to be used by alert rules.

Creating an Alert Rule

After configuring the notification channel, go to:

Custom Alerts → Alert Rules

If you haven't created any rules yet, CH-Ops displays an empty state with a New Rule button. Click New Rule to start creating an alert.

The alert rule form brings the main configuration into one place.

Field	What it does
Name	Identifies the rule
Severity	How serious a firing alert is, for example warning
Schedule (cron)	How often the rule runs, for example `/5 * * *` for every five minutes
Operator	How the result is compared to the threshold, for example greater than
Threshold	The value the operator compares against
SQL (single value)	A query that returns one number to check
Description	Context shown when the alert fires (optional), but it is useful for documenting what the alert is checking
Cluster	Which cluster the rule runs against, defaulting to all clusters
Target nodes	Which nodes to run on, left empty to mean all nodes

Before configuring, the Alert Rule also has its own Test button. It executes the configured SQL query and checks the result against the defined condition and threshold.

This lets you verify the alert logic before relying on the scheduled rule.

Once created, the channel shows up as a card with its status, when it was last tested, and Edit, Enable, and Delete actions.

From Query to Notification

Once the alert is created, the workflow becomes straightforward:

1. Run the SQL query
CH-Ops executes the configured query according to the schedule.

2. Check the result
The returned value is evaluated against the configured operator and threshold.

3. Determine whether the condition is met
If the result satisfies the alert condition, the rule is triggered.

4. Send the notification
The configured notification channel is used to deliver the alert. This turns a SQL query into a simple scheduled monitoring mechanism.

A Simple End-to-End Flow

The complete workflow can be summarized as:

SQL Query → Schedule → Condition → Notification

The important idea is that you don't need a separate script or external scheduler just to repeatedly check a SQL-based condition.

CH-Ops brings the query, condition, schedule, and notification configuration together in one interface.

Why This Is Worth Setting Up

The value of an alert is how early it catches a problem. A five-minute schedule can flag an issue long before someone notices it during a manual dashboard check. Keeping the alert rule and notification channel separate also means you can change how you receive alerts without rewriting the alert logic.

Email (SMTP) is available in the open source version and is enough for many setups. CH-Ops Pro adds additional notification channels (Slack, Microsoft Teams, Google Chat, and PagerDuty) for teams that need more immediate delivery.

Explore CH-Ops Pro features:
https://www.ch-ops.io/blog/clickhouse-alerts-in-slack-teams-google-chat-pagerduty

Next in the CHOps series

CH-Ops Access Control and App Data Backups

Search ClickHouse® Logs Without Writing SQL

Kanishga Subramani — Tue, 29 Sep 2026 16:16:04 +0000

When something goes wrong in a ClickHouse® deployment, logs are often the first place to look. But investigating them traditionally means knowing which system table to query, writing SQL, choosing the right time range, and filtering through the results.

CH-Ops provides a visual way to explore these logs without writing SQL.

From the Logs section, you can choose a log type, select a time range, view an overview of the activity, and switch to Search when you need to investigate individual log records.

What Is CH-Ops?

CH-Ops is a browser-based operations platform for ClickHouse® that provides a visual interface for managing and monitoring ClickHouse® deployments.

Instead of relying entirely on the command line or HTTP API, CH-Ops brings common operational tasks into a single web application. It supports capabilities such as SQL querying, cluster monitoring, user management, backups, alerts, dashboards, and log exploration.

In this article, we'll focus on the Logs section and how CH-Ops makes ClickHouse® log investigation easier without requiring SQL for every search.

Exploring ClickHouse® Logs in CH-Ops

The Logs section provides dedicated views for different ClickHouse® system logs:

Crash Log - investigate server crashes
Error Log - understand recurring error types
Text Log - explore server messages across different log levels
Session Log - review login and logout activity

Each log provides two views:

Overview - understand the overall activity for a selected time range.
Search - find specific records using filters relevant to that log.

Quick time ranges such as 1h, 6h, 24h, 48h, 7d, and 30d make it easy to focus on a specific period.

1. Crash Log: Investigating Server Crashes

The Crash Log is based on system.crash_log and is useful when a ClickHouse® process unexpectedly stops or a node restarts.

The Overview provides a quick summary of crash activity, including:

Total crashes
Distinct signals
Affected ClickHouse® versions
Recent crash activity
Crash distribution by signal and version
Crash incidents

Crash Log Overview

Once a crash is identified, the Search view can be used to inspect individual crash records using details such as the event time, signal, query information, and exception trace.

Crash Log Search

This makes it easier to move from “Did a crash happen?” to “What exactly was recorded when it happened?”

An empty Crash Log can also be a good result. If no crashes were recorded during the selected period, there may simply be nothing to investigate.

2. Error Log: Finding Recurring Errors

The Error Log is based on system.error_log and helps identify the types of errors occurring on the server.

The Overview summarizes the selected period through metrics and visualizations such as:

Total errors
Number of error types
Local versus remote errors
Top error types
Latest error

Error Log Overview

The Top Error Types chart provides a quick starting point. If one type accounts for a large portion of the errors, you can investigate that category further.

Searching Error Logs

The Search view lets you investigate error records without writing SQL. You can select a time range, filter by Error Type, search by Error Message, and set the row limit.

Error Log Search

The search results show the matching records along with details such as the event time, error type, error message, and query ID.

3. Text Log: Understanding Server Activity

The Text Log is based on system.text_log and provides a broader view of messages generated by the ClickHouse® server.

Unlike the Error Log, it isn't limited to errors. It includes messages across different log levels, making it useful when something appears unusual but hasn't necessarily resulted in an error.

The Overview provides information such as:

Total log lines
Errors
Warnings
Number of loggers
Recent activity
Log volume by level

Text Log Overview

The Log Volume by Level chart provides a quick picture of server activity across the selected period.

Searching Text Logs

When you need to investigate a particular event, switch to the Search tab.

You can filter logs by time range, log level, and message, and set the number of results to display.

The Search view presents the individual log records, including information such as:

Event time
Log level
Query ID
Logger name
Message
Source file and line

Text Log Search

This lets you quickly narrow down relevant server activity and inspect the underlying records without writing SQL against system.text_log.

4. Session Log: Tracking Login Activity

The Session Log is based on system.session_log and provides visibility into login and logout activity.

The Overview summarizes session activity through:

Total events
Successful logins
Failed logins
Logouts
Distinct users
Recent activity

Session Log Overview

The Login Outcomes chart provides a quick view of successful logins and logouts, while Top Users highlights the accounts generating session activity.

The Search view can be used when you need to investigate specific session activity. You can filter events by event type, user, or failure reason.

This makes it easier to investigate authentication activity directly from CH-Ops without manually querying system.session_log.

From Overview to Search

Across the different log types, CH-Ops follows a simple investigation pattern:

Choose a log → Select a time range → Load the Overview → Identify something interesting → Switch to Search → Investigate the records

The Overview helps you understand the bigger picture, while Search helps you narrow down specific events and investigate the underlying records.

When Should You Use Each Log?

Each log answers a different operational question:

Log	Useful when you want to know
Crash Log	Did the ClickHouse® process crash, and what was recorded?
Error Log	What types of errors are occurring, and how frequently?
Text Log	What has the ClickHouse® server been reporting about its activity?
Session Log	Who has been connecting, and are login attempts succeeding or failing?

The Overview helps identify the problem, while Search helps investigate it.

From Investigation to Alerts

Logs help you investigate what has already happened. For conditions that require proactive attention, CH-Ops Alert Rules can notify you when defined conditions occur.

The workflow becomes:

Monitor → Detect → Alert → Investigate

Use Alerts to be notified about important conditions, and Logs to investigate the details behind them.

Bringing ClickHouse® Log Investigation Into One Interface

ClickHouse® system logs contain valuable information for monitoring and troubleshooting, but accessing them shouldn't always require writing SQL.

With CH-Ops, you can explore Crash Log, Error Log, Text Log, and Session Log from a single Logs section. The Overview gives you the big picture, while the Search view lets you inspect the underlying records.

Instead of starting every investigation with a SQL query, you can follow a simple visual workflow:

Select the log → Choose the time range → Load the data → Understand the overview → Search the records

This makes ClickHouse® log investigation more accessible and helps you move from identifying an issue to finding the relevant details - without writing SQL for every search.

Explore CH-Ops

Want to learn more about CH-Ops and explore its features? Visit the official website and explore the resources below:

CH-Ops Official Website
Getting Started with CH-Ops
CH-Ops Official GitHub Repository
CH-Ops Demo Video

Next in the CHOps series

CH-Ops Scheduled Alerts: Know Before Things Break

Watch your clusters live on CHOps

Kanishga Subramani — Fri, 25 Sep 2026 06:20:52 +0000

Complete Visibility into Your ClickHouse® Infrastructure

Monitor cluster health, analyze performance, track system resources, and gain real-time insights into every ClickHouse® node — all from a single, intuitive interface.

Introduction

ClickHouse® has established itself as a high-performance, real-time analytical database. However, sustaining sub-second query performance at scale requires continuous monitoring of database internals — including background pools, thread scheduling, storage parts, and I/O amplification.

Our custom management platform, CHOps, provides real-time telemetry across every layer of your ClickHouse® nodes, bridging hardware metrics with native database engine states.

Key Features & Dashboard Overview

1. Machine & Node Telemetry

CHOps presents real-time gauge metrics updated dynamically, for example every 5 seconds.

Resource Allocation: CPU utilization, OS Memory, ClickHouse®-specific Memory, and Thread Pool saturation.
Node Summary: Instant visibility into active database versions, total databases, table counts, active queries, running merges, and mutations.

2. Disk & Storage Health Check

Disk Partitioning: Tracks raw space utilization, with the default storage shown at 457.00 GiB and 53.6% used.
Part Formats: Monitors the breakdown between Compact (76.46%) and Wide (23.54%) storage parts to help understand write behavior.
System Health Checks: Automated monitoring across 15+ critical health states, including Delayed inserts, Spilling to disk, Keeper expired, Readonly replicas, and Broken disks.

3. Background Pools & Execution Shaping

Pool Capacity vs. Usage: Real-time histograms for background tasks including Merges, Fetches, Moves, Schedule, Buffer Flush, Distributed operations, and Message Brokers.
Efficiency & Compression Ratios: Live tracking of Read Amplification, Write Amplification, and Read Compression.

For example:

Read Amplification: 566.1 rows/row
Read Compression: 16.0x

4. Query & Time Execution Profiling

"Where the Time Goes": Granular thread-level decomposition showing exact thread usage spent on:

Disk Read
CPU User
Merge Exec
CPU Kernel
Disk Write

In-Flight Metrics: Tracking active query locks, I/O in flight, open read/write operations, memory consumption by mapped files versus server runtime, and thread distribution.

Dashboard Snapshot

Metric	Value
Storage Usage	457 GiB (53.6% Used)
Part Breakdown	Compact: 76.5% / Wide: 23.5%
Read Compression	16.0x
Read Amplification	566.1 rows/row

Advantages of Using CHOps

Early Detection of Bottlenecks

Instantly spot write-amplification spikes or thread pool exhaustion before queries degrade.

Data Compression Optimization

Track part churn and row compression ratios to optimize storage policies and partition schemes.

Simplified Cluster Management

Monitor cluster topology, replica delays, and Keeper/ZooKeeper connections in a single unified dashboard.

ClickHouse® Architecture: Clusters & Nodes Explained

1. What is a ClickHouse® Node?

A Node is a single running instance of the ClickHouse® server process (clickhouse-server) on an isolated physical machine, virtual server, or container.

Role:

A node stores local table parts using engines such as MergeTree, receives SQL queries, parses and compiles them, and processes data using vectorized multi-threaded execution.

In Your Dashboard:

The dashboard highlights individual nodes, such as node-1 (localhost ::1:9000), showing specific runtime metrics such as uptime, active queries, CPU, and RAM allocation.

2. What is a ClickHouse® Cluster?

A Cluster is a logical grouping of multiple ClickHouse® nodes working together to handle large analytical datasets across distributed infrastructure.

Sharding & Replication:

Clusters can split dataset subsets across different nodes through sharding or duplicate data for high availability through replication, using Distributed table engines and ClickHouse® Keeper/ZooKeeper.

Horizontal Scaling:

When data volume or query load grows beyond a single machine's capacity, adding nodes to a cluster expands storage capacity and query execution power in parallel.

Conclusion

As analytical workloads grow in volume and complexity, maintaining deep visibility into database internals becomes a necessity — not a luxury.

CHOps bridges the gap between high-level database administration and low-level engine telemetry, helping keep ClickHouse® clusters resilient, performant, and cost-efficient.

By transforming complex metrics — such as memory footprints, thread pool allocation, write amplification, and part formats — into clear, real-time visual insights, CHOps helps data engineers and DevOps teams identify potential bottlenecks before they impact production.

Why CHOps telemetry is different

Don't confuse general system-level host monitoring, such as standard Prometheus or Grafana OS exporters, with the engine-native telemetry provided by CHOps.

Standard infrastructure tools primarily track raw host metrics.

CHOps explicitly surfaces ClickHouse®-specific engine internals, including:

Background merge queues
Part formats such as Compact vs. Wide
Read/write amplification
Thread pool scheduling
ClickHouse®-specific memory and execution metrics

This blog focuses specifically on deep ClickHouse® database performance optimization using CHOps.

References

CH-OPS Open Source (OSS) Version – GitHub: https://github.com/Quantrail-Data/CH-Ops
CH-OPS Website: https://www.ch-ops.io/
CH-OPS Installation Guide: https://www.ch-ops.io/blog/install-ch-ops-in-10-minutes-docker-binary-or-source
CH-Ops Demo Video: https://www.linkedin.com/posts/quantrail-data_ClickHouse-opensource-dataengineering-activity-7489909665477091328-QOIY/

Next in the CHOps series

Search ClickHouse® Logs Without Writing SQL
https://www.ch-ops.io/blog/search-clickhouse-logs-without-writing-sql

CH-Ops Schema Tools: Visualizer, Indexes & Projections

Kanishga Subramani — Fri, 25 Sep 2026 05:19:00 +0000

A ClickHouse® deployment rarely stays simple. A materialized view gets added to pre-aggregate something, then a second MV reads its output. A dictionary shows up for user lookups, a Distributed table sits in front of a sharded local table — and soon the schema is fully documented in DDL, and still hard to hold in your head.

The questions that come up are relational, not definitional:

What feeds this table, and what does it feed?
What breaks if I drop it?
Which skipping indexes already exist here?
Is there already a projection for this query pattern?
How do I add or remove an index without hand-writing ALTER statements and remembering to backfill?

You can answer all of these by hand — SHOW CREATE TABLE, system.tables, cross-referencing MV definitions. It's just slow, and it gets worse fast once a pipeline crosses databases.

That's the gap Schema Tools in CH-Ops fills.

Four screens — Schema Visualizer, Data Skipping Indexes, Projections, Index Management — read as one workflow: see how the schema connects, check what optimization already exists, weigh whether a projection helps, then manage indexes when the evidence supports it.

It doesn't remove SQL — every index or projection action shows the exact statement before running it. What it removes is the friction around that: manual inspection, hand-written DDL, and the easy-to-miss materialization step.

The running example

Raw request logs land in staging.raw_logs.

An MV parses them into analytics.parsed_logs — sorted by service, then time — which feeds two more MVs rolling requests into hourly metrics and error summaries, plus a Distributed table for sharded reads.

A view in reporting aggregates the metrics for a dashboard.

There's also analytics.users_dict, a dictionary loaded from a users table.

Keep that sort order — service, then time — in mind. It's what decides which queries are already fast.

Schema Visualizer: how is this schema connected?

Reconstructing a pipeline from DDL by hand means reading each MV's source and target and searching for anything downstream, one hop at a time.

Cross-database dependencies are the worst case, since checking one database at a time hides them entirely.

The Schema Visualizer draws the graph instead: tables, MVs, dictionaries, Distributed tables, and views as cards, with lines showing data flow.

It's read-only — nothing here creates, alters, or drops anything.

It doesn't render the whole schema at once, on purpose — that's slow and unreadable.

Pick a database, then a table, and CH-Ops traces every relationship in both directions, draws just that connected subgraph top to bottom, and auto-fits it.

The traversal isn't limited to one database.

Starting at raw_logs pulls in all three databases on one canvas, each node labelled with its full name — the fastest way to find a dependency you didn't know existed.

Node types

Headers are colour-coded:

MergeTree family — stores data
MaterializedView — fires on every insert
Refreshable MV — fires on a schedule
Dictionary
Distributed — routes to shards, stores nothing itself
View — a saved query, recomputed on read
Other

One glance tells you what stores data versus what just moves it.

Navigation

Dropdowns pick what's drawn.

Search matches table and column names, highlighting hits and dimming the rest — handy for questions like "which tables use user_id."

Columns toggle switches between compact and detailed cards.

Fit and Re-layout handle the camera and layout separately.

The sidebar

Click a node and it opens:

Engine
Partition key
Sort order
Primary key, if different
Rows/bytes
What it reads from
What reads from it
Full CREATE statement

Reads and writes are clickable, so you can walk the pipeline hop by hop.

The heatmap

A graph shows how data moves, not what's doing the work.

The optional heatmap covers that for MVs, over the last 1/7/30 days, built from system.query_views_log.

When enabled, it colours and thickens edges by:

View duration
Rows/bytes written or read
Peak memory
Executions

The values are log-scaled, since volumes can span orders of magnitude.

An empty heatmap can mean no MVs fired, log_query_views is off, or the connecting user lacks SELECT on that table.

One hot edge next to cool ones makes the point: MVs at the same level of the graph don't cost the same to run.

Answers: how is my schema connected, and where does data flow?

Data Skipping Indexes: what already exists here?

An index doesn't sort anything.

It summarizes each block — min/max, distinct values, a bloom filter, or text terms — so a filtering query can skip blocks that can't match.

The sort key is what actually orders the data and makes those columns fast already.

Indexes are for the filters the sort key doesn't cover.

On parsed_logs, service is already fast.

user_id, status_code, and message are not.

The Data Skipping Indexes screen is read-only:

Database → table → each index, with type and covered expression, across everything.

The expression next to the type is the useful part — it catches a duplicate before you create it.

Every index costs on every insert, so a duplicate is pure downside.

Four types

minmax

Min/max per block.

Cheap and useful for dates and timestamps that correlate with insertion order.

set

Distinct values per block.

Good for low-cardinality equality filters; useless past its size limit.

bloom_filter

Probabilistic.

It can rule a block out for certain, but a "maybe" still means reading it.

Useful for equality on high-cardinality columns.

text

Indexes terms within a string for searching rather than matching exactly.

Answers: what indexes does this table already have, and what are they indexing?

Projections: a different representation of the same data

A skipping index narrows a query.

A projection changes what it reads from entirely — a second copy of the table, sorted differently or pre-aggregated.

ClickHouse® decides on its own whether to use one.

It's not free, and it's not an index.

Think of it this way:

Index → can I skip this block?

Projection → is there a better-suited copy of this data?

Dashboards on this pipeline repeatedly ask for counts and latency by service and hour, recomputed every time.

A pre-aggregated projection storing exactly that grouping solves it directly.

CH-Ops covers the lifecycle in five tabs:

View — the same tree as the index screen
Add Projection — a form with table, name, select, optional grouping/ordering, cluster-wide and skip-if-exists options
Materialize Projection — builds it for existing rows
Clear Projection — empties data while keeping the definition
Drop Projection — removes it entirely

One quirk: projections don't support SELECT DISTINCT — CH-Ops strips it and tells you.

Grouping and ordering

Grouping and ordering are separate fields.

A projection grouped by day can't serve a query grouped by hour.

Creating isn't the same as filling

Projection definition
        │
        ├── new inserts ──────────► maintained automatically
        │
        └── rows already in table ─► need Materialize Projection

New data is covered automatically.

Existing rows need materializing — real work on a big table, so it can be scoped per-partition to check whether it's worth it before doing the rest.

Clear then rebuild is the fix for a drifted projection.

Drop removes it for good.

Either way, remember the cost: a projection is a second copy of the data, written on every insert whether it's used or not.

Worth it for a query run constantly; not worth adding speculatively.

Answers: can I give ClickHouse® a better-suited representation for an important query pattern?

Index Management: create, materialize, drop

Three tabs — Create, Materialize, Drop.

This one needs admin access, unlike the read-only screens above.

Create

Database → table → column → name → type → granularity.

The column list comes with data types attached, so there's no typing from memory.

Some types add fields:

bloom_filter — false-positive rate
text — tokenizer

Name it for what it does:

idx_user_id, not idx1.

CH-Ops shows the exact statement before running it — a safer way to produce the same DDL, not a black box.

Granularity defaults to a sensible value and is one of the last things worth tuning — type and expression matter far more.

Materialize

Same gotcha as projections:

Create index  ──► applies to data inserted from now on
Materialize   ──► existing rows become covered

Nothing errors when this is skipped — the index just quietly doesn't help.

Unlike projections, there's no partition-scoping option here — MATERIALIZE INDEX runs against the whole table in one go.

This screen is the answer to:

"I added the index and nothing changed."

Drop

Removes the index, not the data.

Every index costs on writes for as long as it exists.

If it's not earning that back, drop it.

That's normal tuning, not a mistake.

Answers: creating, materializing, and dropping — the three states of an index.

From schema discovery to optimization

Here's the workflow:

Open the Visualizer and select parsed_logs.
See three MVs and a Distributed table depend on it.
Read the sort order from the sidebar.
Check Data Skipping Indexes for what's already covered.
Compare against your actual workload — endpoint/user filters aren't served by the sort key.
Check Projections for an existing pre-aggregation.
Decide: projection for a repeated aggregation, index for a plain filter.
Create it.
Materialize it.
Check whether it helped. Drop it if not.

CH-Ops doesn't tell you which index or projection to build.

It shows what exists and where the load sits, then removes the DDL friction.

The judgment calls — steps 5 and 7 — are still yours.

The Query Profiler is where you confirm a query is actually slow before reaching for any of this.

Same table across all three panels — one object, four views of it.

Conclusion

Understand the schema.

Check what's already optimized.

Weigh a projection.

Manage indexes when the evidence supports it.

The value isn't skipping SQL — you can write the DDL yourself, and CH-Ops shows you the statement anyway.

It's having a fast, structured way to see what's already there before you touch it.

Most bad schema decisions come from not seeing the dependency, the existing index, or the projection that was already there — not from an inability to write ALTER TABLE.

Pick your busiest table, open the Schema Visualizer, and see what's attached to it.

References

Schema Tools Documentation:

https://www.ch-ops.io/docs/guide/schema-visualizer?v=latest

Next in the CHOps series

Watch your clusters live on CHOps:

https://www.ch-ops.io/blog/ch-ops-cluster-dashboard

CHOps Is Now GA: Open-Source Operations for Self-Hosted ClickHouse®

Kanishga Subramani — Thu, 24 Sep 2026 12:44:28 +0000

CHOps is now generally available.

ClickHouse® Cloud has a nice UI and good tools to admin and monitor a
cluster. If you self-host the open-source ClickHouse® database, you get
control, but the tools are fragmented and the daily work is clumsy.

We built CHOps for our customers who self-host the ClickHouse® database.
It started as many small internal UIs. When we decided to make it public,
we put them into one app.

CHOps works with any deployment: VMs, bare metal, Kubernetes (Altinity®
operator, and the official ClickHouse® operator in early access), and
managed cloud services.

We released a beta in July 2026. After several rounds of testing by our
ClickHouse® DBAs and use on production clusters, CHOps is now generally
available. It is tested with ClickHouse® database 26.8 LTS.

The core is open source under Apache 2.0. CHOps Pro adds features for
production teams, such as SSO, audit logs, Slack, Teams and PagerDuty
alerts, and remote node management.

Thank you to everyone who tested the beta and sent feedback.

GitHub: https://github.com/Quantrail-Data/CH-Ops
CHOps home page: https://ch-ops.io

Design a ClickHouse® Table Without Hand-Writing DDL: Schema Studio

Kanishga Subramani — Wed, 23 Sep 2026 16:10:58 +0000

Designing a ClickHouse® table involves more than defining columns. Data types, sorting keys, partitioning, MergeTree configuration, indexes, and other settings can influence how the table performs as data grows.

Writing the complete DDL manually gives you control, but it also means translating each design decision into the correct ClickHouse® syntax.

Schema Studio simplifies this process by providing a guided workflow for designing and creating ClickHouse® tables while keeping the generated SQL visible and editable.

What is CH-Ops?

CH-Ops is a browser-based operations platform for ClickHouse®. It brings common database operations into a single web interface, including SQL querying, cluster monitoring, user management, backups, alerts, dashboards, and other operational workflows.

Alongside these operational capabilities, CH-Ops includes Schema Studio, a SQL tool designed to simplify the process of building ClickHouse® table definitions from source data.

Introducing Schema Studio in CH-Ops

Schema Studio is a guided table-design feature within CH-Ops.

Starting with your source data, it helps:

Infer and refine the schema
Configure ClickHouse®-specific table settings
Generate and validate the DDL
Optionally review the design with AI
Create the table

Importantly, Schema Studio creates the table structure only. The source data is used for schema inference and is not loaded into the newly created table.

You can access it under:

SQL Tools → Schema Studio

Building a ClickHouse® Table with Schema Studio

Schema Studio organizes the table-design process into four core stages.

Each stage focuses on a specific part of the design, starting with understanding the source data and ending with a validated table definition ready to be created in ClickHouse®.

1. Start with Your Source Data

Schema Studio first connects to the ClickHouse® instance selected in CH-Ops.

Enter the ClickHouse® username and password to establish the session.

Once connected, choose the data that will be used for schema inference.

You can upload a local file in formats such as:

CSV
TSV
JSON
NDJSON/JSONL
Parquet
ORC

You can also configure an object-storage source such as:

S3
Azure

2. Review and Shape the Schema

After analyzing the source, Schema Studio displays the inferred columns and corresponding ClickHouse® data types.

It also shows:

Approximate distinct values
Null percentages

This helps you review the structure before moving to table configuration.

The inferred schema remains editable.

You can:

Modify column names
Change data types
Add derived columns using DEFAULT, MATERIALIZED, ALIAS, or EPHEMERAL
Configure additional column options such as codecs and comments

Note: Schema inference may produce nullable types such as Nullable(Int64). Review the inferred types before configuring ORDER BY, and adjust the type if a nullable column needs to be used as the sorting key.

3. Define the ClickHouse® Table Design

The Engine step is where you configure how the table will be structured in ClickHouse®.

You can select the database and table name, choose the required MergeTree behavior, and define key table clauses such as:

ORDER BY
PRIMARY KEY
PARTITION BY
SAMPLE BY
TTL

For more advanced designs, you can also configure:

Data-skipping indexes
Projections
Replication
Distributed tables
Frequently filtered columns
Additional MergeTree settings

Note: For MergeTree tables, configure an ORDER BY or PRIMARY KEY before generating the DDL. If no sorting key is required, use tuple() for ORDER BY. Schema Studio flags a missing key in the Generate step.

Engine Configuration

The Engine Configuration step allows you to configure the MergeTree engine and key table clauses.

Advanced Configuration

Advanced Configuration allows you to add options such as:

Indexes
Projections
Replication
Distributed tables

4. Generate and Validate the DDL

After the table design is configured, Schema Studio generates the corresponding ClickHouse® CREATE TABLE statement in an editable SQL editor.

You can review or modify the generated SQL.

Use Validate to check the DDL before creating the table.

If you want to discard editor changes, Rebuild from Form regenerates the DDL using the configuration from the previous steps.

This keeps the generated SQL visible and gives you the ability to make manual adjustments before creating the table.

5. Review the Design with AI

Schema Studio also provides Evaluate with AI for an optional review using the supported AI provider configured in CH-Ops.

The evaluation can identify potential improvements related to:

Data types
Nullability
LowCardinality
Sorting keys
Partitioning
Codecs
Other table-design choices

Recommendations are presented for review and are not applied automatically.

When a recommendation is useful, Apply to Editor places the suggested DDL into the editor for further review and validation.

This provides an additional review step while keeping the final decision with the user.

6. Create the Table

After the DDL has been reviewed and validated, select Create Table.

Schema Studio displays a confirmation before executing the CREATE TABLE statement on the connected ClickHouse® instance.

Only the table structure is created.

The source data used for schema inference is not loaded into the table.

After creation, open the table in the SQL Editor to verify that it was created successfully and review its schema and configuration.

Why Schema Studio Matters

The value of Schema Studio is not simply that it generates a CREATE TABLE statement.

It brings the decisions involved in ClickHouse® table design into one workflow while keeping those decisions visible to the user.

Schema inference provides a starting point.

The Engine step exposes ClickHouse®-specific configuration.

Validation checks the generated DDL.

AI-assisted review provides an additional opportunity to refine the design before creation.

This reduces the repetitive work of translating a table design into SQL while keeping the final DDL available for inspection and modification.

Conclusion

Designing a ClickHouse® table requires decisions that can affect query performance, storage, and how the table behaves as data grows.

Schema Studio brings those decisions together in a guided workflow, from understanding the source data to creating the final table.

By combining:

Schema inference
ClickHouse®-specific configuration
DDL generation
Validation
Optional AI-assisted review

Schema Studio provides a more structured path to table creation without hiding the SQL or taking control away from the user.

References

CH-Ops Installation Guide
CH-Ops Official Repository
CH-Ops Demo Video

Next in the CH-Ops Series

CH-Ops Schema Tools: Visualizer, Indexes & Projections

Secure API Key Management: Your AI, Your Choice

Kanishga Subramani — Tue, 22 Sep 2026 15:50:45 +0000

What is CH-Ops?

CH-Ops is a browser-based operations platform for ClickHouse® that combines database administration, SQL development, monitoring, backups, dashboards, alerts, and AI-powered capabilities into a single interface.

One of these AI-powered capabilities is Qurioz AI, which enables users to interact with ClickHouse® databases using natural language instead of manually writing SQL queries.

To communicate with AI models securely, Qurioz AI requires one or more configured AI providers. CH-Ops provides API Key Management, allowing administrators to configure, verify, and manage these providers from a centralized location.

What is Qurioz AI?

Qurioz AI is an AI-powered SQL assistant in CH-Ops that allows users to interact with ClickHouse® databases using natural language instead of manually writing SQL queries.

Users can simply ask questions about their data, and Qurioz AI understands the request, generates the appropriate ClickHouse® SQL query, executes it against the selected database, and presents the results in an easy-to-understand format.

Qurioz AI can also visualize query results using charts, making it easier to understand trends, comparisons, and patterns in the data.

For example, instead of manually writing a SQL query such as:

SELECT product_name, sum(total_amount) AS total_sales
FROM sales
GROUP BY product_name
ORDER BY total_sales DESC;

A user can simply ask:

"Show me the total sales by product."

Qurioz AI can generate the corresponding ClickHouse® query, execute it against the selected database, and display the results. Users can then switch to the chart view to visualize the returned data.

This makes it easier for users to explore data, generate SQL queries, understand query results, and visualize insights without requiring them to write SQL manually.

To communicate with the selected AI model, Qurioz AI requires a valid and verified AI provider configuration. This is where API Key Management becomes important.

What is API Key Management?

API Key Management is the configuration center for all AI providers used by Qurioz AI.

Instead of embedding API keys inside the application or requiring every user to configure providers individually, administrators can securely register AI providers once and make them available throughout Qurioz AI.

Currently, CH-Ops supports configuring up to five AI providers:

OpenAI
Google Gemini
Claude
Mistral
Ollama

Once configured, these providers automatically become available inside Qurioz AI, allowing users to switch between AI models whenever required.

Why Configure Multiple AI Providers?

Different AI models are suited for different workloads.

Some models generate SQL faster, while others provide more detailed explanations or perform better with complex analytical queries.

By configuring multiple providers, users can:

Compare SQL generated by different AI models
Switch providers without changing application settings
Use both cloud-based and local models
Continue working if one provider is temporarily unavailable
Evaluate different models for various analytical workloads

Managing AI API Keys

API Key Management provides a simple workflow for securely configuring AI providers before they are used inside Qurioz AI.

1. Add a New API Key

Navigate to:

Control Panel → AI API Keys

When no providers have been configured, the page displays an empty API Key Manager.

Select Add API Key to configure a new provider.

For each provider, enter:

Display Name
AI Provider
Model Name
API Key

Each provider uses its own supported models.

For example:

OpenAI → GPT models

Gemini → Gemini models

Claude → Claude models

Mistral → Mistral models

Ollama → Local models

CH-Ops supports configuring up to five API providers, making it easy to manage multiple AI services from one place.

2. Verify Before Saving

Before an API key can be stored, CH-Ops validates the credentials.

Once a valid API key is entered:

The API key is successfully verified
A success message is displayed
The verification status appears in green
The Save Key button becomes available

This verification step ensures that only valid API credentials are stored and prevents invalid configurations from being used by Qurioz AI.

Since Qurioz AI depends on configured AI providers, a provider must be successfully verified and saved before it can be used for SQL generation.

3. Manage Saved API Keys

After verification, the provider can be saved.

The API Key Manager displays all configured providers together with their current status.

Administrators can:

View configured providers
Edit the provider name
Change the configured model
Update the API key
Delete providers that are no longer required

This makes it easy to keep AI provider configurations up to date without recreating them from scratch.

4. Delete an API Key

Administrators can delete an API key when an AI provider is no longer required.

Selecting Delete removes the provider from API Key Management and makes it unavailable in Qurioz AI.

A new key can be added and verified whenever the provider is needed again.

5. Edit an API Key

Administrators can edit an existing provider to update the model name, provider details, or API key.

After making changes, the updated API key can be verified and saved without creating a new provider.

Using Configured Models in Qurioz AI

After an AI provider has been configured, no additional setup is required.

Navigate to:

SQL Tools → Qurioz AI

The configured providers automatically appear in the model selection dropdown.

Users can simply choose the model they want to use before asking questions.

Once selected, Qurioz AI uses that provider to:

Understand natural language questions
Generate ClickHouse® SQL queries
Execute queries against the selected database
Explain query results in simple language

Switching the dropdown immediately changes the AI provider used for subsequent requests, allowing users to compare responses from different models without leaving the interface.

Why API Key Management Matters

API Key Management separates provider configuration from everyday usage.

Administrators configure providers only once, while users simply select the model they want inside Qurioz AI.

By validating API keys before storage and exposing configured providers directly within the AI interface, CH-Ops creates a seamless workflow between configuration and AI-assisted querying.

Support for multiple providers also makes it easy to compare models, evaluate their responses, and choose the most suitable AI for different analytical tasks.

Conclusion

Reliable AI-assisted analytics begin with secure AI provider configuration.

The API Key Management feature in CH-Ops provides a centralized way to configure and validate OpenAI, Gemini, Claude, Mistral, and Ollama providers before they are used by Qurioz AI.

Once configured, these providers integrate directly with Qurioz AI, allowing users to switch between models effortlessly while generating ClickHouse® SQL queries using natural language.

By combining secure API key management with flexible model selection, CH-Ops simplifies both the administration and everyday use of AI-powered analytics.

References

CH-Ops Installation Guide
CH-Ops Official Repository
CH-Ops Demo Video

Next in the CH-Ops Series

Design a ClickHouse® Table Without Hand-Writing DDL: Schema Studio

Ask your ClickHouse® database in plain English

Kanishga Subramani — Mon, 21 Sep 2026 15:47:38 +0000

Introducing Qurioz, the AI assistant built into CHOps.

What is CH-Ops?

CH-Ops is a browser-based operations platform for ClickHouse®. Instead of relying entirely on the command line or HTTP API, it provides a visual interface for managing your ClickHouse® deployment.

From running SQL queries and monitoring cluster health to managing users, backups, alerts, and dashboards, CH-Ops brings operational tasks into a single web application.

It stores its own configuration in a local SQLite database without modifying your ClickHouse® data unless you explicitly execute queries.

Every team that runs ClickHouse® has the same bottleneck.

The data is there, the questions are obvious, and the answers are three or four hours away because someone has to remember which of the 200 tables holds the events, whether the timestamp column is event_time or created_at, and how to phrase a conditional count without accidentally scanning a billion rows.

ClickHouse® is fast, but its SQL has a dialect of its own.

countIf instead of COUNT(CASE WHEN ...).

uniq when an approximate distinct is good enough and uniqExact when it isn't.

FINAL to read the deduplicated state of a ReplacingMergeTree.

ANY JOIN when you want one match instead of a fan-out.

None of it is hard once you know it. All of it is a wall when you don't.

That wall is what Qurioz removes.

What is Qurioz?

Qurioz is the AI assistant built into CHOps.

It turns plain questions about your data into ready-to-run ClickHouse® SQL, without leaving the app.

You ask a question the way you'd ask a colleague, Qurioz writes the query against your actual schema, runs it, and shows you the rows.

You can then edit the query, chart the result, or pin it to a dashboard.

New team members get productive on an unfamiliar schema in minutes instead of weeks.

Experienced engineers skip the part where they look up column names for the fortieth time.

You'll find it in the sidebar under SQL Tools → Qurioz AI.

Getting set up

Three things need to happen once. The first two are admin tasks; after that, anyone on the team can ask questions.

1. Add an AI provider key

Qurioz talks to a model you choose.

Go to Control panel → AI API Keys and find the Qurioz API Key Manager.

It supports Gemini, OpenAI, Mistral, Claude, and Ollama, and you can store up to four keys and switch between them.

Paste your key and press Verify AI API Key.

The Save Key button stays disabled until verification passes a deliberate choice, so you find out the key is wrong here rather than halfway through your first question.

Keys are encrypted before they're stored.

This page is admin-only. If you're not an admin you'll see:

"API key management is only available for administrators."

2. Connect your ClickHouse® cluster

If you're already using CHOps, this is done.

If not, Control panel → Cluster Management is where you add a cluster and its nodes.

You can configure the node host, port, user, password, and an HTTPS toggle, with a per-node connection test.

3. Generate the schema

This is the step that makes Qurioz specific to your database rather than generically knowledgeable about SQL.

Open SQL Tools → Qurioz AI.

Next to the status pill reading Database Not Selected, click the pencil icon.

The Database Schema Generator opens, listing every database on the connected node.

Select the ones you want Qurioz to know about. There's a Select All toggle if you want everything.

Click Add Schema.

Qurioz reads the structure of those databases and indexes it.

When it's done you'll see:

"Database ID is created successfully!"

The pill then flips to Database Selected.

Schemas change, so the same modal has Refresh Selected Schema to re-read a database after you've added tables or columns, and Delete Schema's to remove one entirely.

Asking your first question

Type into the box marked Search for query... and press Enter.

(Shift+Enter gives you a new line if the question is long.)

Ask it the way you'd say it out loud:

Which customers placed the most orders last month?

Show me the 20 slowest queries in the last 24 hours

How many unique users hit the API each day this week?

Qurioz works out which tables are relevant, writes the query, and shows it in a block headed ClickHouse® Query.

It then runs it immediately and renders the rows underneath.

There's no separate Run button to hunt for; the result is just there.

If the query returns nothing you'll get:

"No data found. Please check the SQL query and try again."

If it fails outright, you get the error and a Retry button.

Refining the answer

The first query is a starting point, not a verdict.

Qurioz is built around the assumption that you'll want to adjust it.

Edit opens the SQL in an inline editor. Change what you want and press Update or Ctrl+Enter to re-run it. Cancel backs out.
Copy puts the query on your clipboard for the SQL editor, a dashboard, or a code review.
Hovering your own question reveals a pencil. Reword it, hit Enter, and Qurioz regenerates from the new phrasing, usually faster than describing the fix in a follow-up message.

From result to chart to dashboard

Once you have rows, Chart View turns them into a visualization.

Pick a Chart Type and Subtype, map your columns to the axes, and watch the Preview update.

Give it a name, choose a Dashboard, and Save.

The chart lands on that dashboard alongside everything else your team tracks.

Saving to a dashboard requires the editor role or above.

Questions that span several databases

Analytics rarely respects database boundaries.

If you've generated schemas for more than one database, hover the Database Selected pill and you'll get a list of them.

Click to toggle each one in or out of the current question.

Everything toggled on is fair game for the same question, so Qurioz can reach across databases when the question calls for it, and stay narrowly focused when you'd rather it didn't wander.

What it can actually write

Qurioz isn't limited to SELECT * FROM one_table.

It handles the shapes real analysis takes:

Joins across tables, worked out from how your columns are named, such as an orders.customer_id matched to a customers.id.
Aggregations using ClickHouse®'s own idioms: countIf and sumIf for conditional counts, uniq for fast approximate distincts, and uniqExact when you need the exact number.
Window functions for rankings, running totals, and row-over-row comparisons.
CTEs and subqueries when a question needs staging before the final answer.
FINAL on ReplacingMergeTree tables when you're asking about current state rather than raw history.

Every query comes back with a LIMIT 10 by default, so an exploratory question can't accidentally pull a billion rows.

Ask for "top 5" or "limit 50" and it uses your number instead.

One honest caveat:

Qurioz gives you a well-formed starting query, not a guaranteed-correct one.

It's working from your schema, not from knowledge of what your columns mean in your business.

Read the SQL before you trust the number. The query is right there above the results precisely so you can.

If a question is genuinely ambiguous — two equally plausible tables, no sensible way to join them — Qurioz says so instead of inventing a join and handing you a confidently wrong answer.

Your data and your choice of model

Worth being precise about, because it's the question every data team asks first.

The embedding and retrieval run locally.

The step that writes the SQL does not:

Your question and the relevant table and column definitions are sent to whichever AI provider you configured.

Table names, column names, and types — not your row data.

If that's more than your compliance posture allows, use Ollama.

Point Qurioz at a model running on your own infrastructure and nothing leaves your network at any stage.

On the safety side, Qurioz generates read-only queries.

Ask it to drop a table, truncate, or update rows and it declines.

It's built to answer questions, not to change your data.

Conclusion

Qurioz makes working with ClickHouse® data faster, simpler, and more accessible.

Ask questions in plain language and get ready-to-run SQL based on your actual schema.

You can review, edit, visualize, and save results without leaving CHOps.

It helps teams spend less time searching through schemas and more time finding answers.

With Qurioz, your ClickHouse® data is only a question away.

References

Qurioz ships with CHOps, the ClickHouse® administration and monitoring dashboard from Quantrail™ Data.

Installation Guide: CH-Ops Installation Guide
Website: ch-ops.io
Docs: ch-ops.io/docs — see the Qurioz AI guide under SQL Tools, and AI API Keys for provider setup
GitHub: Quantrail-Data/CH-Ops

If your team spends more time remembering schemas than asking questions, this is the part of the workflow we built Qurioz to delete.

Debugging Query Performance with Per-Second Metrics

Kanishga Subramani — Sat, 19 Sep 2026 05:55:53 +0000

A query can look perfectly healthy when all you see is its final execution time.

It ran for 12 seconds. It used 8 GB of memory. It read 40 GB from disk.

But those numbers don't tell you the whole story.

When did the memory spike? When did the query start waiting on disk? Did cache misses increase halfway through execution? Did a JOIN suddenly consume most of the memory? Did the query spill to disk near the end?

A final query profile can tell you what happened overall. But to understand why it happened, you need to see what the query was doing while it was running.

That's where Query Metrics comes in.

Query Metrics provides a second-by-second timeline of resource consumption during query execution. It exposes memory, CPU, disk I/O, cache hits and misses, network activity, and hundreds of other counters.

Think of it as a heart-rate monitor for a query.

Why Per-Second Metrics Matter

Consider a query that eventually reaches 10 GB of memory usage.

That number alone doesn't tell you much.

Maybe memory gradually increased from 1 GB to 10 GB because the query was building a large aggregation state.

Or maybe memory stayed around 2 GB for most of the query, suddenly jumped to 10 GB while building a JOIN hash table, and then dropped back down.

Those are completely different problems.

The same applies to disk I/O.

A query reading 100 GB over 30 seconds may be perfectly normal for its workload. But if disk writes suddenly spike at the 20-second mark, the query may have started spilling intermediate results to disk.

Without a timeline, you see the final numbers.

With a timeline, you see the behavior.

Query Metrics takes resource snapshots every second for queries that run for more than roughly one second. These snapshots are stored in system.query_metric_log, with each snapshot containing hundreds of counters.

Instead of asking:

"Why was this query slow?"

you can ask:

"What happened at second 7 that made this query slow?"

That is a much more useful question.

From Query Duration to a Query Timeline

Query duration tells you how long a query took.

Query Metrics helps explain what happened during that time.

The raw metric snapshots are converted into visual timelines grouped by category and unit. The X-axis represents the query's execution time, with one data point per second, while the Y-axis shows the metric value.

For example, a query might show:

Memory steadily increasing
CPU remaining relatively flat
Disk reads suddenly increasing
Cache misses appearing midway through execution
Network activity spiking near the end

Instead of looking through hundreds of raw counters, you can visually follow the query's execution.

Metrics with different units are also separated into different charts, so bytes, counts, and time measurements don't get mixed together on the same scale.

The result is much easier to reason about:

You don't just see the result of the query. You see its journey.

Getting Started

Getting to a query's metrics is straightforward:

Go to Tools → Query Metrics.
Choose the From and To timestamps.
Click Load Queries.
Select a query that has per-second metric data.
Click Use This Query.
Click Show Query Metrics.

The charts are then grouped by category and unit.

Only categories containing non-zero data are displayed. A simple query may show only Memory and CPU, while a more complex query involving JOINs, disk spilling, remote reads, or distributed execution can activate many more categories.

This keeps the visualization focused on what actually happened during that query instead of showing hundreds of irrelevant metrics.

Start With the Memory Chart

Memory is often the first place to look when investigating an unstable query.

The Memory chart typically includes:

memory_usage — memory currently allocated by the query
peak_memory_usage — the highest memory usage seen so far

The relationship between these two metrics can tell you a lot.

Both Lines Climb Steadily

The query may be continuously accumulating data in memory.

This can happen during operations such as:

Hash table construction
Sorting
Aggregation

Memory Spikes and Then Drops

The query experienced a temporary memory burst.

A large hash JOIN is one example. The query may allocate a large hash table, use it, and then release that memory.

Peak Memory Keeps Climbing

This can indicate that the query is progressively consuming more memory throughout its execution.

Peak Memory Reaches the Configured Limit

The query may be killed or throttled because it exceeded max_memory_usage.

This is one of the biggest advantages of a timeline.

A final memory number tells you how much memory was used.

A per-second graph tells you when and how that memory was used.

Disk I/O: Find the Moment the Query Starts Waiting

Disk metrics can reveal another important part of a query's execution.

OSReadBytes represents bytes read from disk. A steadily increasing value generally means the query is scanning data.

OSWriteBytes is particularly interesting when it suddenly spikes. A spike can indicate that intermediate results are being written to disk.

Then there is:

DiskReadElapsedMicroseconds

This represents the time spent waiting for disk reads.

These metrics help distinguish between two very different situations:

The query is reading a lot of data.

versus

The query is spending a lot of time waiting for storage.

Those problems require very different optimizations.

If the query is simply reading too much data, you may need to reduce the amount of data being scanned.

If the query is spending significant time waiting for storage, the storage layer or filesystem cache may deserve closer attention.

Cache Hits vs. Cache Misses

Cache behavior is another area where a final query profile can hide useful information.

Query Metrics exposes counters such as:

MarkCacheHits
MarkCacheMisses
PageCacheHits
PageCacheMisses

Comparing hits and misses can help determine whether the cache is actually helping the workload.

For example, a query with many mark-cache misses may be repeatedly going to disk instead of finding the required information in memory.

The documentation uses a mark-cache miss ratio above 10% as a signal that the cache may be cold or too small.

The important part is that you aren't simply observing:

"The query is slow."

You can start connecting that slowdown to a specific resource behavior.

The Most Useful Pattern: Correlating Spikes

The real power of per-second metrics appears when you stop looking at individual charts in isolation.

Suppose peak_memory_usage suddenly jumps at second 18.

Don't stop at the memory chart.

Look at the other charts at that exact moment.

Maybe ArenaAllocBytes starts climbing at the same time.

That suggests the query is allocating memory for a large aggregation or sort.

Or perhaps an External Operations category appears immediately afterward.

That could mean the query exceeded its in-memory limits and started spilling intermediate results to disk.

The debugging workflow becomes:

Find the timestamp where the spike occurs.
Look at the other metrics around that timestamp.
Identify what operation was becoming more expensive.
Determine whether the query transitioned from an in-memory operation to an external operation.

This is where a timeline becomes more than a visualization.

It becomes a way to reconstruct what the query was doing.

JOINs Have Their Own Story

JOIN-heavy queries can be particularly interesting because memory usage may spike during hash-table construction.

For a SELECT with a JOIN, Query Metrics exposes metrics such as:

peak_memory_usage
JoinBuildTableRows
JoinProbeTableRows
JoinResultRows
ExternalJoinWritePart

A large gap between steady-state memory and peak memory can indicate that the JOIN's hash table became large.

You can also compare the number of rows involved in building and probing the JOIN.

If the JOIN result is dramatically larger than its inputs, that may indicate a many-to-many JOIN and is worth investigating.

And if external JOIN metrics appear, the JOIN has spilled to disk.

That gives you considerably more information than simply knowing:

"The JOIN was slow."

You can start asking:

Was the build side too large? Did the JOIN produce too many rows? Did it exceed memory and spill?

GROUP BY and ORDER BY: Watch for Spilling

Aggregation and sorting introduce another common source of performance problems.

For these queries, ArenaAllocBytes can reveal a steadily growing aggregation state.

This can be a sign of a large aggregation workload, particularly with high-cardinality GROUP BY operations.

External-operation metrics can reveal when sorting or aggregation spills to disk:

ExternalSortWritePart
ExternalSortMerge
ExternalAggregationWritePart
ExternalAggregationMerge

Spilling isn't necessarily an error.

It is a safety mechanism that allows an operation to continue when it cannot fit entirely in memory.

But it is significantly slower than keeping the operation in memory.

So if the timeline shows memory increasing and then external writes suddenly appearing, you've found an important part of the query's performance story.

CPU-Bound or Waiting?

A query can consume a lot of wall-clock time without actually spending that time computing.

Query Metrics separates several time measurements, including:

RealTimeMicroseconds
UserTimeMicroseconds
SystemTimeMicroseconds

If real time is significantly greater than user plus system CPU time, the query is likely spending substantial time waiting—for example on I/O, locks, or network activity.

If user CPU time dominates, the query is more likely CPU-bound.

This distinction matters.

Adding more CPU won't fix a query that is mostly waiting on storage.

Likewise, increasing memory won't necessarily solve a problem caused by network latency.

The timeline helps answer a fundamental question:

Is the query spending its time computing, or waiting?

Distributed Queries Add Another Dimension

When a query runs across shards, network metrics become important.

Query Metrics exposes:

NetworkSendBytes
NetworkReceiveBytes
NetworkReceiveElapsedMicroseconds
DistributedConnectionMissCount

Large amounts of data moving between shards may indicate that filters could be pushed down or that PREWHERE could reduce the amount of data being transferred.

High network receive time can point toward network bandwidth or latency as the bottleneck.

Again, the goal isn't simply to find a large number.

It's to understand where in the query's lifetime that behavior happened.

How Query Metrics Finds the Important Counters

There is an interesting challenge behind this feature.

system.query_metric_log has more than 700 columns, and the available columns can change between ClickHouse® versions.

Hardcoding a list of metrics would make the feature fragile.

Instead, Query Metrics discovers the active metrics dynamically.

For the selected query, it:

Fetches the rows from system.query_metric_log.
Scans every row to find columns containing non-zero values.
Sorts metrics by activity.
Keeps the 100 most active metrics when more than 100 are present.
Classifies each metric by category and unit.
Splits crowded categories into multiple charts.
Builds the charts directly from the fetched data.

This approach is especially useful because metrics can become active mid-query.

For example, an external sort metric might remain zero for the first few seconds and suddenly become non-zero when the sort starts spilling.

Looking across all snapshots catches that transition.

You Don't Need to Understand Hundreds of Metrics

At first, hundreds of metrics can feel overwhelming.

But you don't need to memorize every counter.

Start with a few questions.

Did Memory Spike?

Look at:

memory_usage vs. peak_memory_usage

Did the Query Read Too Much?

Look at:

OSReadBytes, SelectedRows, and SelectedMarks

Is Storage the Bottleneck?

Look at:

DiskReadElapsedMicroseconds

Is the Cache Helping?

Compare:

MarkCacheHits vs. MarkCacheMisses

Did the Query Spill?

Look for:

ExternalSort*, ExternalAggregation*, or ExternalJoin*

Is It CPU-Bound?

Compare:

RealTimeMicroseconds with the CPU time metrics.

Is a Distributed Query Moving Too Much Data?

Look at:

NetworkSendBytes and NetworkReceiveBytes

These metrics cover many of the most common performance investigations.

The goal isn't to understand everything.

The goal is to find the few metrics that explain what changed.

Compare a Slow Query With a Fast Query

One of the most useful ways to use Query Metrics is to compare two queries.

Start with the slow query.

Identify the categories with unusually high activity.

Then examine the fast query.

The differences can point directly toward the cause.

For example, imagine the slow query has many MarkCacheMisses, while the fast query has significantly more MarkCacheHits.

That suggests the slow query is reading more from disk while the fast query is benefiting from cache.

The comparison turns performance debugging into a much simpler question:

What did the fast query avoid doing that the slow query had to do?

This can be far more actionable than simply comparing execution times.

Before You Start

There are a few prerequisites for Query Metrics:

ClickHouse® 26.3 LTS or newer
query_metric_log enabled
A query lasting more than roughly one second
SELECT access to system.query_metric_log and system.query_log

On ClickHouse® 26.3 LTS, query_metric_log is enabled by default.

The sampling interval defaults to 1000 ms.

You can configure the interval using query_metric_log_interval.

Lower values provide more granular data, but they also increase collection overhead. Setting it to 0 disables metric collection entirely.

So there is a trade-off:

More detail means more collection overhead.

A Practical Debugging Workflow

When a query suddenly becomes slow—or gets killed for exceeding its memory limit—don't start by staring at the final query duration.

Start with the timeline.

Step 1: Find the Query

Load queries for the relevant time range and select the query you want to investigate.

Step 2: Look at Memory

Find the point where peak_memory_usage changes sharply.

Step 3: Check What Happened at That Timestamp

Look at CPU, disk, cache, JOIN, aggregation, and external-operation metrics.

Step 4: Identify the Transition

Did the query start reading heavily from disk?

Did a JOIN hash table grow?

Did aggregation state increase?

Did the operation start spilling?

Step 5: Validate With Related Metrics

One metric rarely tells the whole story.

Look for multiple metrics changing together.

Step 6: Compare Against a Healthy Query

If possible, compare the timeline with a faster or previously successful execution.

This approach shifts debugging from guessing to observation.

Instead of asking:

"What configuration should I change?"

you first ask:

"What actually happened?"

That usually leads to a much better fix.

Conclusion

Query duration tells you that something happened.

Per-second Query Metrics helps you understand what happened along the way.

A memory spike, a burst of disk I/O, a sudden increase in cache misses, a growing JOIN hash table, or an operation spilling to disk doesn't magically appear at the end of a query. It happens at a specific point during execution.

That is what makes the timeline so valuable.

Instead of looking at a query as a collection of final numbers—12 seconds, 8 GB of memory, 40 GB read—you can follow its execution second by second and correlate changes across memory, CPU, storage, cache, network, and execution metrics.

The debugging workflow becomes simple:

Find the spike → find what changed → correlate the metrics → identify the bottleneck → fix the query.

That's the real value of Query Metrics.

It doesn't just tell you that a query was slow or expensive. It gives you the evidence needed to understand why.

And when a production query starts behaving differently, that difference between knowing something is wrong and knowing exactly when and why it went wrong can save a lot of debugging time.

Don't just measure how long a query takes. See what it did along the way.

References

CH-Ops Repo

Where Did the Time Go? Query Profiler in CHOps

Kanishga Subramani — Fri, 04 Sep 2026 09:46:05 +0000

A query takes 9 seconds. You read the SQL. You read EXPLAIN. Nothing looks wrong.

EXPLAIN tells you what ClickHouse® plans to do. It does not tell you where the 9 seconds actually went. For that you need to watch the query run — and that is what the CHOps Query Profiler does.

Open SQL Tools → Query Profiler, pick a query, and CHOps draws a flame graph of it.

What a flame graph actually is

A flame graph is a picture of where time went. That's it.

The bottom bar is where the query starts.
Every bar is one function that ran.
Width = time. Wider bar, more time.
Stacked bars = the call chain. A called B, B called C.

Read it bottom to top for what called what, left to right for what ran. But mostly you just find the widest bar. That's the bottleneck.

You do not need to know C++ or ClickHouse® internals for this. The function names carry enough meaning on their own:

If the widest bar says…	The query is…
`ReadBufferFromFileDescriptor`	IO-bound — reading too much from disk
`HashTable::insert`	building hash tables for GROUP BY or JOIN
`MergeTreeDataSelectExecutor`	scanning MergeTree parts — likely missing the primary index
`MemoryTracker::allocImpl`	allocating — expected at the top of a memory trace

Widest bar, read the name, act on it.

First, understand what a "sample" is

This is the part that trips people up, and it explains most of the confusion people have with the tool.

ClickHouse® does not record every function call. That would be ruinously slow. Instead it takes periodic snapshots: a timer fires, and whatever function each thread happens to be executing at that instant gets written as one row into system.trace_log. That row is one sample.

A flame graph is nothing more than those rows counted and stacked.

Bar width = how many snapshots caught that function running.

By default ClickHouse® takes one snapshot per second, per thread:

Sampling period	Snapshots/sec/thread	A 5s query on 4 threads gives
`1000000000` ns (1s — the default)	1	~20 samples
`10000000` ns (10ms)	100	~2,000 samples

Twenty samples produce a few blocky bars and percentages that swing on every re-run. Two thousand produce a graph you can trust.

So if your flame graph looks thin, the query is usually fine — the sampling rate is the problem.

Raise it for that one query:

SELECT
    ... your heavy query ...
SETTINGS
    query_profiler_real_time_period_ns = 10000000,
    query_profiler_cpu_time_period_ns  = 10000000;

Those go on the query you want to profile, when you run it.

They change how ClickHouse® records that query while it executes. Nothing on the server changes, and no other query is affected.

Memory traces work on a different trigger: instead of a timer, ClickHouse® records a stack every time the query allocates another memory_profiler_step bytes (4 MiB by default). Lower that value for a denser memory graph.

The workflow

Set From and To to when the query ran. The range is capped at 24 hours.
Click Load Queries. The header shows how many queries in that window have trace data.
Find your query. The picker searches by query text or query ID, and each row shows the ID, a SQL preview, the duration, the sample count and the timestamp.
Click it — the selected ID appears below the list, with Clear beside it.
Choose a Trace Type, then Generate Flame Graph.

The sample count in the list is the number to watch.

Single digits means you're about to get a graph that tells you nothing; go back and re-run the query with a higher sampling rate.

Above the graph you get three quick stats:

Total samples
Unique stacks
Max depth

Unique stacks is the one people overlook.

A low number means the query took very few distinct code paths, so there's little to see regardless of sample count.

If a query you just ran doesn't appear, run:

SYSTEM FLUSH LOGS;

Trace data is buffered before it's written.

Trace types: pick the one that matches your symptom

Nine options, and picking the right one matters more than anything else on the page.

Trace Type	Answers	Use when
All Types	everything at once	first look, general orientation
CPU Time	where CPU went	the default choice for a slow query
Wall Clock (Real)	where clock time went, waits included	slow query, but CPU looks idle
Memory (Watermark)	what caused the biggest allocations	query was killed for memory
Memory (Sampled)	the spread of memory use	broad memory picture
Memory Peak	what was running at the memory high point	pinning down a spike
Profile Events	which internal counters moved most	advanced
Jemalloc Samples	what the allocator is doing	advanced — fragmentation debugging
Instrumentation	XRay instrumentation traces	advanced — needs `SYSTEM INSTRUMENT`

Not all nine work out of the box.

Some rely on collectors that are off by default, and if a collector is off you get an empty graph rather than an error.

Worth knowing before you assume the tool is broken:

Trace type	On a stock server
CPU Time, Wall Clock (Real)	work — but at 1 sample/sec/thread, thin
Memory (Watermark), Memory Peak	work — a stack every 4 MiB allocated
Memory (Sampled)	empty — needs `memory_profiler_sample_probability > 0`
Profile Events	empty — needs `trace_profile_events = 1`
Jemalloc Samples	empty unless the jemalloc profiler is enabled
Instrumentation	empty unless `SYSTEM INSTRUMENT` is on

Check where you stand:

SELECT
    name,
    value
FROM system.settings
WHERE name LIKE '%profiler%'
   OR name = 'trace_profile_events';

The graph also re-labels itself for the trace type you picked.

On a CPU or All Types graph, the stats read total samples and the tooltip shows counts.

Switch to a memory type and the same line reads total bytes.

A caption next to the Generate button spells out what the current selection measures.

Memory graphs get a second dropdown

Pick a memory trace type and a Memory Context filter appears next to it, with five options.

Context	Shows
All Contexts	everything
Global (server)	server-wide allocations
User (user/merge)	user and merge allocations
Process (query)	just this query
Thread	thread-level allocations

Choose Process (query) when debugging one query.

Otherwise background merges and server caches get mixed into the graph and you end up optimising something unrelated.

Reading the shapes

One very wide bar

Easiest case.

One function owns the query. Read its name, act on it.

Many narrow towers

Normal for queries with joins, subqueries and several aggregations — no single function dominates.

Scan across all the towers for the widest single bar.

Still your best lever.

Two towers of similar width

Work split across parallel paths.

Widths are shares of the total, so two 50% towers means the cost is genuinely divided — fix both, or reduce the input feeding them.

Flat, no towers

One code path, or too few samples.

Check the unique-stacks count before concluding anything about the query.

Hover any bar for its full function name and share of the total.

Click to zoom into that subtree; the toolbox has restore, download and full-screen.

What CHOps is doing under the hood

No magic, and the UI doesn't hide it — a View Generated SQL panel under the graph shows the exact query CHOps ran:

SELECT
    arrayStringConcat(
        arrayReverse(
            arrayMap(
                x -> demangle(addressToSymbol(x)),
                trace
            )
        ),
        ';'
    ) AS stack,
    count() AS samples
FROM system.trace_log
WHERE query_id = '...'
GROUP BY stack
SETTINGS allow_introspection_functions = 1;

Here's what each part does:

addressToSymbol turns raw addresses into C++ symbols.
demangle makes those symbols readable.
arrayReverse puts the root at the bottom, where a flame graph expects it.
GROUP BY stack counts how often each call chain was sampled.

CHOps folds those stacks into a tree and renders it.

That folded-stack format is the same one every flame graph tool uses, which is why the output looks familiar if you've used perf.

Note this query only reads what was already captured.

It can't create samples after the fact — which is why the sampling settings belong on the query you profile, not here.

Query Profiler or Processors Profile?

CHOps ships two profilers.

Different tables, different questions.

	Query Profiler (flame graph)	Processors Profile (pipeline)
Source	`system.trace_log`	`system.processors_profile_log`
Shows	C++ functions inside the engine	logical pipeline steps
Best for	engine-level debugging	day-to-day query optimisation
Example finding	most of the time in a read-pool function	`ReadFromMergeTree` 7.2s, `AggregatingTransform` 0.3s

Start with Processors Profile.

Its names map directly to query plan steps, so the fix is usually obvious.

Switch to the Query Profiler when Processors Profile has told you which step is slow and you need to know why.

Before you get a graph

Requirement	Why	Check
`system.trace_log` enabled	that's where samples live	`SELECT count() FROM system.trace_log`
`allow_introspection_functions`	needed for symbol resolution	CHOps passes it for you
SELECT on `system.trace_log`, `system.query_log`	the CHOps ClickHouse® user needs read access	`GRANT SELECT ON system.trace_log TO your_user`
`clickhouse-common-static-dbg`	optional — resolves system frames to names	`dpkg -l clickhouse-common-static-dbg`

When it doesn't work

Symptom	Cause	Fix
Graph is thin — a handful of bars	default 1 sample/sec/thread	re-run with `query_profiler_*_period_ns = 10000000`
"No trace data found"	query finished before a snapshot fired	longer query, or a higher sampling rate
Empty graph on a specific trace type	that collector is off by default	see the trace-type table above
Query missing from the picker	trace data not flushed yet	`SYSTEM FLUSH LOGS;`
Bars show raw hex addresses	no debug symbols on the server	install `clickhouse-common-static-dbg`; only new traces resolve
Empty query list	nothing traced in that window	widen the range (up to 24h)

Four habits worth forming

1. Raise the sampling rate before you profile

More snapshots, better picture.

This single setting is the difference between a useless graph and a useful one.

2. Profile something heavy

A query finishing in milliseconds leaves almost nothing to sample, whatever the rate.

3. Always compare CPU against Real

Fastest way to tell computation from waiting.

4. Take a before and after

Generate a graph, add the index or projection, generate again.

The change in bar widths is your proof the fix worked — a far better artifact for a PR than "feels faster now."

That last one is the real value.

Flame graphs get sold as a diagnosis tool, but they're just as good as a verification tool.

Optimisation without a before-and-after is guessing.

Try it

CHOps is free and open source.

GitHub: https://github.com/Quantrail-Data/CH-Ops
Docs: https://www.ch-ops.io/docs/guide/query-profiler
Docker: https://hub.docker.com/r/quantrailadmin1/ch-ops

Run one slow query with the sampling rate turned up.

Profile it.

Look at the widest bar.

You'll know more in thirty seconds than in an hour of reading EXPLAIN output.

CHOps SQL Editor: A Complete Guide to Faster ClickHouse® Query Development and Optimization

Kanishga Subramani — Fri, 04 Sep 2026 06:13:08 +0000

What is CHOps?

CHOps is a browser-based operations platform built for managing ClickHouse® deployments. Instead of relying entirely on the command line or HTTP APIs, it provides a unified interface for executing SQL queries, monitoring clusters, managing users, backups, alerts, dashboards, and much more — all from a single web application.

One of its most powerful features is the SQL Editor, designed to simplify the entire query development experience.

Introducing the CHOps SQL Editor

When working with ClickHouse®, writing SQL is only one part of the job. Developers and Data Engineers often spend just as much time browsing schemas, remembering table names, checking execution plans, estimating query costs, and debugging performance issues.

With traditional SQL editors, these tasks usually involve switching between multiple tools or browser tabs. That constant context switching slows development and makes query optimization more difficult.

The CHOps SQL Editor is designed to solve these challenges by bringing everything into a single workspace. Whether you're exploring a new dataset, optimizing analytical queries, or troubleshooting production workloads, this editor provides all the tools needed to build, analyze, and optimize queries without leaving the page.

Let's explore how these features streamline the ClickHouse® query development workflow and performance.

The SQL Editor at a Glance

The SQL Editor is organized into four main areas, each designed for a specific part of the query workflow.

Left: Schema Explorer for browsing databases and tables.
Top of the center: Query Tabs for working on multiple queries simultaneously.
Center: The SQL Editor and its toolbar where you write SQL, choose how to run it, and reach the history, bookmarks, share, export, fullscreen, and AI controls.
Bottom: The Results Panel for viewing results, execution statistics, and debugging information.

This layout keeps everything within reach, eliminating the need to jump between multiple applications while developing queries.

Connecting First

The SQL Editor allows direct authentication using ClickHouse® credentials.

Simply enter your:

Username
Password

Once authenticated, the SQL editor connects securely and unlocks schema browsing, query execution, and analysis features. This design separates application login from database authentication, improving security and flexibility.

Built-in Database Explorer

Once connected, the first place you'll likely visit is the Schema Explorer.

The Schema Explorer lets you browse your ClickHouse® databases and tables directly from the left panel. Expand a database to view its tables, then select a table to insert its fully qualified name into the SQL editor.

Need to check the table structure first? The code icon beside each table opens its complete CREATE TABLE statement, making it easy to review columns, sorting keys, and table engines without leaving the editor.

For databases where AI assistance is needed, the sparkles icon provides quick access to AI SQL generation. We'll explore that workflow later in Generating SQL with AI.

Smart SQL Autocomplete

One of the biggest productivity boosters of the SQL Editor is Autocomplete.

As you type:

SELECT

the editor automatically suggests:

SQL keywords
ClickHouse® functions
Database names
Table names
Column names

Unlike a generic SQL editor, these suggestions come directly from your connected ClickHouse® cluster. Instead of showing generic SQL objects, the editor suggests only the databases, tables, functions, and columns that actually exist on your server.

Autocomplete reduces syntax mistakes while making query writing significantly faster.

Example

Instead of remembering:

SELECT * FROM sales.customer_transactions_archive

you simply type:

SELECT * FROM sales.

and choose the required table from the suggestion list.

Autocomplete also displays function signatures and descriptions, making it much easier to discover ClickHouse® functions without switching to external documentation.

Running Your Query

Once your query is ready, executing it is straightforward.

Simply click Go, or use Ctrl + Enter.

The action performed depends on the selected execution mode. You can either execute the SQL directly or choose one of the available EXPLAIN modes to analyze the query before running it.

Understand Queries with EXPLAIN

Understanding how ClickHouse® executes a query is often more valuable than simply seeing the result.

Normally, checking a query plan requires manually prefixing every query with EXPLAIN, executing it, reviewing the output, and then removing the prefix before running the actual query.

The CHOps SQL Editor simplifies this workflow. Simply select an EXPLAIN mode from the dropdown beside the Go button and execute the query. No query rewriting is required.

Explain mode	What it shows
Explain & Explain plan	Displays the execution plan in order
Explain syntax	Your query after ClickHouse®'s internal rewrites
Explain query tree	The analyzed, internal form of the query
Explain pipeline	The actual processors that will do the work
Explain estimate	Estimated rows, parts, and marks to be read
Explain AST (graph)	Visualizes the parsed query structure
Explain pipeline (graph)	Displays the execution pipeline as an interactive graph
Explain plan (JSON)	Returns the execution plan in JSON format

AI-Powered SQL Generation

Not every query needs to start from scratch. Sometimes you know what information you need but not the exact SQL syntax.

The Generate SQL feature helps convert natural language into SQL queries.

Example prompt:

Show the top 10 products by revenue during the last month.

The generated SQL can then be reviewed, modified, and executed like any manually written query, making it useful for rapid prototyping and learning new schemas.

The Debugging Tools Around the Query

A few smaller features exist specifically to shorten the time between "something feels slow" and "here is why":

Estimate Query Cost

Before executing an expensive query, it's often useful to understand how much work ClickHouse® is expected to perform.

The Cost feature estimates:

Rows to be read
Parts to be scanned
Marks to be processed
Available indexes

without actually executing the query.

This provides a quick way to identify potentially expensive queries before they impact your cluster.

Max Rows Control

Max Rows caps how many rows come back to the browser, so an accidental unbounded query does not lock up the tab while you are trying to debug something else.

When larger datasets are required, the limit can be adjusted or the results can be exported instead.

Action Buttons After a Run

Once a query finishes and ClickHouse® has assigned it a query ID, a row of buttons appears in the statistics bar to take you straight into the profiling tools for that exact query:

Query_id: copies ClickHouse®'s ID for the query to your clipboard, useful for looking it up in system tables or handing to whoever administers the cluster.
Flame Graph: opens the Query Profiler with this query loaded, showing where it spent its time. Reach for this first when something is slow.
Pipeline: opens the Processors Profile with the query loaded, rendering its execution as a diagram so you can see which step dominated.
Metrics: opens Query Metrics with the query loaded, showing a second-by-second view of how it used resources while it ran.

History

History keeps every query you have run, with its timing and success or failure.

Instead of rewriting or searching through old SQL files, you can quickly reopen previous queries, review execution results, and continue where you left off.

History keeps your most recent queries and drops the oldest as new ones arrive. The Clear button empties it.

Bookmarks

Some queries become part of your daily workflow.

Bookmarks let you save the ones you check often, like a recurring health check query, so you are not retyping the same debugging query every day.

Share Option

Need a second opinion on a query?

The Share feature generates a link containing the current SQL, allowing teammates to open the query directly in their own SQL Editor.

Since every user reconnects using their own ClickHouse® credentials, sharing a query never grants access to your database. It simply shares the SQL itself.

Compare Query Performance

Next to the connect control is a second switch: Regular and Comparison.

Regular is the single query view described above.

Comparison splits the screen into a current query on the left and an experimental rewrite on the right, each with its own cost estimate and run button.

This is the mode built for tuning.

Paste the slow query on one side, write a rewrite on the other, and check whether the rewrite actually reduces estimated cost before you touch production.

Export Option

Once your query is complete, exporting the results is just as simple.

The SQL Editor supports exporting query results in multiple formats, including:

CSV
JSON
Parquet
etc.

Exports are processed on the server, allowing large datasets to be generated without affecting the browser session.

A Simple Workflow

A typical workflow inside the CHOps SQL Editor looks like this:

Connect to your ClickHouse® deployment.
Browse databases and tables using the Schema Explorer.
Use autocomplete to discover tables, columns, and functions.
Write your SQL query.
Use EXPLAIN to understand query execution.
Estimate query cost before running expensive workloads.
Execute the query.
Review the results and execution statistics.
Use Query Profiler, Pipeline, or Metrics when troubleshooting.
Use Comparison Mode to test query improvements.
Bookmark useful queries for future use.
Share SQL with teammates when collaboration is needed.
Export results when required.

Conclusion

Each feature in the SQL Editor solves a small part of the query development process.

Autocomplete reduces typing, EXPLAIN helps you understand execution plans, Cost estimation highlights expensive queries before execution, and Comparison Mode makes performance tuning much easier.

Individually, these features improve specific tasks.

Together, they reduce context switching, simplify query optimization, and provide a smoother development experience for anyone working with ClickHouse®.

ClickHouse® 26.8 LTS Release: What's New and Why It Matters

Kanishga Subramani — Sat, 29 Aug 2026 05:45:03 +0000

ClickHouse® 26.8 is the newest LTS release, and it is a substantial one: 21 backward-incompatible changes, 49 new features, 127 performance improvements, and around 30 settings that changed their default value.

This article covers 26.8 on its own — what landed, what breaks, and what to verify before you upgrade.

Release status at time of writing (27 August 2026). ClickHouse® 26.8 has been announced, but the release is not fully published yet and the upstream changelog still marks the 26.8 section as in progress. Confirm the current release status before you plan an upgrade window.

At a glance
Breaking changes
- Ingestion and the write path
- Type and function semantics
- Query planning and output
- Security and configuration
- Removals
- Monitoring and introspection
Default settings that changed in 26.8
- Behaviour
- Security
- Performance (enabled by default)
- MergeTree - on-disk formats
What's new
- SQL surface
- Server and operations
- Observability
- Joins and text search
- Data lakes
- AI functions
Performance
Upgrade checklist
Summary

At a Glance

Category	Entries
Backward incompatible changes	21
New features	49
Experimental features	48
Performance improvements	127
Improvements	138
Bug fixes	556

Breaking Changes

All 21 breaking changes, grouped by what they affect.

Ingestion and the Write Path

`max_insert_threads` now defaults to `auto`

It resolves to the number of CPU cores available to the server, parallelising INSERT SELECT by default. It can also parallelise the writing side of a plain INSERT where the destination write path can safely fan out.

Two consequences worth planning for: the number of parts created by such queries changes, and so does the order of inserted rows.

If you have tight parts_to_throw_insert thresholds, or anything depending on insertion order — a non-deterministic ORDER BY tie-break, _part or _block_number assumptions, a ReplacingMergeTree without a proper version column — test this before rolling out.

A detail that catches people diffing configurations: the declared default is 0 in both 26.7 and 26.8.

What changed is the setting's type, from UInt64 to MaxThreads.

Under UInt64, both 0 and 1 meant single-threaded; under MaxThreads, 0 resolves to auto.

So the value column in system.settings reads 0 before and after, while the behaviour has flipped.

Upstream's own compatibility mapping records the change as 1 → 0 for this reason — 1 is what you now set to get the old behaviour, not what the declaration used to say.

Restore with:

SET max_insert_threads = 1;

Or use a compatibility version below 26.8.

Lightweight `UPDATE` patch parts use a new v2 on-disk format

They are now sorted by:

(sorting_key..., _block_number, _block_offset)

and applied with a new merging algorithm.

Peak memory during apply is bounded by the largest equal-sort-key run rather than the full patch, and updates crossing merge boundaries no longer fall back to an in-memory Join apply.

Old-format patch parts remain readable.

For replicated clusters this requires a rolling-upgrade pin.

Note that patch_parts_version is a MergeTree setting rather than a session setting:

<merge_tree>
    <patch_parts_version>v1</patch_parts_version>
</merge_tree>

Or:

ALTER TABLE my_table MODIFY SETTING patch_parts_version = 'v1';

Hold that until every replica is on 26.8, then remove it.

Object-storage disk transactions

Object-storage disk transactions now use the metadata storage's native transactions by default instead of the previous fake transactions.

The upstream changelog does not explain why this is listed as backward-incompatible, so treat it as worth testing if you run object-storage disks.

`disable_insertion_and_mutation` changes

disable_insertion_and_mutation now also stops background consumption from Kafka, RabbitMQ and NATS tables, while still permitting direct writes to external storage.

Gated Kafka2, NATS and RabbitMQ tables no longer initialise consumers for a direct SELECT.

Separately, message_queue_disable_insertion now requires a server restart to take effect.

Type and Function Semantics

Unquoted JSON numbers are now Unix timestamps

In JSONEachRow and similar formats, an unquoted number for a DateTime or DateTime64 column is read as a Unix timestamp with optional sub-second precision, consistent with Values, CAST and toDateTime64.

Previously a fractional value such as:

1703363853.035

was rejected outright, and a bare integer such as:

1703363853

was read as the raw scaled value of DateTime64, producing a 1970 timestamp.

Quoted strings and ClickHouse®'s own JSON output are unaffected.

For most pipelines this is a silent fix.

If yours was compensating for the old raw-value behaviour, it will now double-correct.

Restore with:

SET input_format_read_datetime_number_as_raw_value = 1;

`Date32` range extended

The Date32 range is extended from:

[1900-01-01, 2299-12-31]

to:

[0000-01-01, 9999-12-31]

matching DateTime64.

Parsing and conversions accept the extended range instead of silently clamping.

The compatibility note matters: in toDate32(N), values in:

[120530, 2932896]

are now interpreted as day numbers — dates from 2300-01-01 to 9999-12-31 — rather than Unix timestamps in early 1970.

Numbers below the day number of 0000-01-01, and timestamps after 9999-12-31, saturate to the new boundaries.

`arrayIntersect` and `arraySymmetricDifference` deduplication fixed

A value repeated inside a single argument is no longer treated as though it appeared in several arguments.

A value now counts for an argument only when it was present in every argument before it, so the result contains exactly the values present in all arguments.

Examples:

SELECT arrayIntersect([1], [2], [1, 1]);
-- []

SELECT arrayIntersect([1, 2], [2], [1, 1, 2]);
-- [2]

SELECT arraySymmetricDifference([1], [2], [1, 1]);
-- [2, 1]

SELECT arraySymmetricDifference([1], [2, 2]);
-- [2, 1]

arrayUnion is unaffected.

As part of the same change, arrayIntersect builds its hash table from the smallest argument rather than all of them — up to 1.85x faster and a third less memory when argument sizes differ significantly.

Window functions over `AggregateFunction` columns are rejected

A window PARTITION BY or ORDER BY over an AggregateFunction column now raises ILLEGAL_COLUMN, as top-level ORDER BY over such a column already did.

Previously at least one analyzer accepted it, and window PARTITION BY partitioned differently depending on max_threads.

The refusal covers states nested in Array, Tuple, Map, Variant or SimpleAggregateFunction.

A SimpleAggregateFunction over an ordinary type, QBit, and GROUP BY or DISTINCT over a state are all unaffected.

Timespan settings that overflow `Int64` microseconds are rejected

This applies to millisecond and second settings.

Query Planning and Output

Trivial views over `Distributed` tables are pushed to the shards

For a view whose body is a plain SELECT over a single Distributed table, the whole outer query now goes to the shards.

This is the new:

optimize_trivial_view_pushdown_to_distributed

setting, enabled by default.

Observable behaviour changes in two ways:

FINAL and SAMPLE written on the view reference are now propagated to the shard-local table instead of being ignored.
extremes is not reported on single-shard clusters.

If you had views where FINAL was silently a no-op, results will change.

Set the setting to 0 to restore the previous behaviour:

SET optimize_trivial_view_pushdown_to_distributed = 0;

`EXPLAIN SYNTAX` returns a single record

The reformatted query comes back as one String value with embedded newlines rather than one record per line.

So:

SELECT count() FROM (EXPLAIN SYNTAX ...);

returns:

To restore the old behaviour:

SET explain_syntax_single_record = 0;

Other EXPLAIN kinds — PLAN, PIPELINE, AST — keep their per-line tree output.

Security and Configuration

A clear theme this release: the server no longer opens filesystem paths supplied from SQL, because it opens them with its own privileges.

MySQL source TLS credentials

MySQL source TLS credentials:

ssl_ca
ssl_cert
ssl_key

can no longer be given as file paths from SQL — not in CREATE NAMED COLLECTION, query arguments, or CREATE DICTIONARY.

Paths remain supported in the server configuration file.

Elsewhere, pass the contents via the new:

ssl_ca_pem
ssl_cert_pem
ssl_key_pem

parameters, which are masked in logs and SHOW output the way passwords are.

NATS credentials move inline

The new nats_credentials setting takes the same payload as a .creds file.

nats_credential_file is no longer accepted from SQL.

It can only be set in:

a named collection defined in the server configuration, or
nats.credential_file in the server configuration itself.

A query may replace a configured path with inline nats_credentials unless the operator pinned it with:

<nats_credential_file overridable="false">

Tables created before the restriction keep working.

PostgreSQL database engines respect `remote_url_allow_hosts`

The PostgreSQL and MaterializedPostgreSQL database engines now honour remote_url_allow_hosts, as the table engine, table function and DDL-created dictionaries already did.

With it configured, CREATE DATABASE and user-issued ATTACH DATABASE pointing at disallowed hosts fail with:

UNACCEPTABLE_URL

Existing databases still load at startup.

`SYSTEM ... CACHE ON CLUSTER` privilege checks are granular

Each command now uses its own privilege rather than the SYSTEM DROP CACHE group.

This lets a holder of a single granular cache privilege run its matching command, and prevents a holder of the group from running:

SYSTEM SYNC FILESYSTEM CACHE ON CLUSTER

without:

SYSTEM SYNC FILESYSTEM CACHE

`include_from` no longer defaults to `/etc/metrika.xml`

That file was previously used for configuration substitutions whenever it existed, even with nothing in the ClickHouse® configuration referring to it.

If you relied on it, add the element explicitly:

<include_from>/etc/metrika.xml</include_from>

Separately loaded users.xml and XML dictionary configs each need their own include_from element.

Removals

The `library` dictionary source is gone

SOURCE(LIBRARY(...))

now fails with:

UNKNOWN_ELEMENT_IN_CONFIG

The dictionaries_lib_path server setting is obsolete with no effect.

Apache Arrow library-based reader and writer removed

The Apache Arrow library-based reader and writer for Arrow and ArrowStream are removed.

The native ClickHouse® implementation, default since 26.7, is now the only one.

The following settings are still accepted but have no effect:

input_format_arrow_use_native_reader
output_format_arrow_use_native_writer

So a query that set them to 0 to force the Apache Arrow path now silently uses the native one.

Experimental `ALP(STD)` codec changes

The experimental ALP(STD) codec now performs Float32 scaling arithmetic in Float64.

This improves compression ratios and eliminates exception-heavy compression of decimal data, but Float32 values written by earlier versions may decode 1 ULP differently.

Monitoring and Introspection

Asynchronous metrics can now be `Map`-typed

Asynchronous metrics can now be Map-typed, and the per-CPU-core and per-device metrics were consolidated.

For example:

OSUserTimeCPU0
OSUserTimeCPU1
...

became a single:

OSUserTimeCPU

metric holding a map from core number to value.

The same applies to the other:

OS*TimeCPU*
CPUFrequencyMHz_*
Temperature*
EDAC*
Block*_*
Network(Receive|Send)*_*
Disk*_*
*BlobsQueueEstimate
AsyncLogging*QueueSize

metrics.

Downstream effects:

system.asynchronous_metrics gains key_values Map(LowCardinality(String), Float64).
The value column is NaN for these metrics.
system.asynchronous_metric_log logs one row per key via a new key column.
The Prometheus endpoint exports them with a label, for example:

ClickHouse®AsyncMetrics_BlockReadBytes{device="sda"}

Graphite's MetricsTransmitter sends them as:

<prefix>.<Metric>.<key>

This is the change most likely to break existing dashboards.

Panels keyed on the old metric names will not error — they will simply return nothing, which is easy to miss.

`system.users.valid_until` changed type

system.users.valid_until changed type from:

Array(DateTime)

to:

Array(DateTime64(0))

so deadlines beyond the year 2106 are represented exactly.

Tooling reading this column needs to handle the new type.

This arrived alongside a new:

VALID FOR <interval>

clause on CREATE USER and ALTER USER.

It is a shorthand for VALID UNTIL, where the deadline is computed at query execution time and stored in VALID UNTIL form.

Default Settings That Changed in 26.8

Around 30 core settings and several MergeTree settings changed their defaults.

These do not appear in the breaking-change list but will change behaviour on upgrade.

Behaviour

Setting	Previous	New
`max_insert_threads`	`1` - single-threaded	`auto` - all available cores
`input_format_read_datetime_number_as_raw_value`	`true`	`false`
`optimize_trivial_view_pushdown_to_distributed`	-	`true`
`explain_syntax_single_record`	`false`	`true`
`filesystem_cache_wait_for_concurrent_download_timeout_milliseconds`	`60000`	`1000`

Security

Setting	Previous	New
`ai_function_allow_insecure_endpoint`	`true`	`false`
`ai_function_max_api_calls_per_query`	`0` (unbounded)	`1000`

Performance (Enabled by Default)

The following performance improvements are now enabled by default:

enable_adaptive_aggregator
enable_group_by_top_k_optimization
enable_packed_string_keys_in_aggregation
enable_parallel_single_level_merge
read_in_order_use_virtual_row
query_plan_push_down_volume_reducing_functions
query_plan_short_circuit_constant_false_join
use_query_condition_cache_for_top_k
allow_distinct_partitions_independently
allow_window_partitions_independently
allow_creating_set_partitions_independently
optimize_trivial_count_with_sparsity_filter
input_format_parquet_spatial_filter_push_down
query_plan_optimize_count_from_text_index
materialize_statistics_on_insert

The last setting has a 25 GiB table-size cap.

MergeTree - On-Disk Formats

Setting	Previous	New	Compatibility
`text_index_serialization_version`	`v1_with_codec`	`v2_with_positions`	Older servers cannot read the new format. Pin to v1 during a rolling upgrade
`packed_skip_index_max_bytes`	`0`	`1 MiB`	New parts only; still readable by older servers, though pre-26.6 ignores packed indices for pruning
`compute_exact_num_defaults_for_sparse_columns`	`false`	`true`	The flag in `serialization.json` is ignored by older versions, so parts survive downgrade
`text_index_posting_list_apply_mode`	`materialize`	`lazy`	Posting lists decoded on demand
`text_index_max_memory_usage_before_flush`	unlimited	`1 GiB`	Memory-based flush trigger for index builders

One protocol-level note: the native protocol changed how String columns are transmitted — a separate stream of cumulative byte offsets followed by concatenated data — once both peers are on revision 54489 or later.

This is around 4x faster for client-side reads.

It is negotiated by protocol revision, so old clients and servers are unaffected, but maintainers of custom native-protocol clients should handle the new revision.

What's New

SQL Surface

Pipe operators

GoogleSQL-style |> chaining is now supported.

Each pipe wraps the preceding query in a subquery, so the resulting AST matches the nested equivalent.

Example:

FROM events
|> WHERE status = 'active'
|> AGGREGATE count() AS total GROUP BY user_id
|> ORDER BY total DESC
|> LIMIT 10;

In a query starting with FROM, SELECT is now optional and defaults to:

SELECT *

`GROUPS` window frame mode

GROUPS is a SQL:2011 window frame mode.

Frame boundaries count whole peer groups rather than physical rows or value distances, completing the set alongside ROWS and RANGE.

Query AST as JSON

New functions:

parseQueryToJSON
formatQueryFromJSON

An experimental ClickHouse®_json dialect is also available behind:

enable_json_ast_dialect

Also new:

arr[indexes] for subscripting an array with an array of positions
notHas
gini
mergedJSONPatch

Server and Operations

SQL-defined HTTP handlers

CREATE HANDLER, ALTER HANDLER and DROP HANDLER define custom HTTP endpoints from SQL.

Handlers can be persisted locally or in Keeper.

Supporting additions include:

currentHandler()
currentRequestURL()
system.handlers
http_handler_name in system.query_log
http_request_url in system.query_log

For teams maintaining small API services that exist only to expose a query over HTTP, this is worth evaluating.

`run_query_in_background`

The server accepts the query, returns immediately, and runs it to completion regardless of what happens to the connection.

Track it by query_id in:

system.processes
system.query_log

This is aimed at long-running operations such as:

INSERT SELECT
CREATE TABLE AS SELECT
POPULATE

Atomic `POPULATE`

A plain:

CREATE MATERIALIZED VIEW ... POPULATE

is now locally atomic, controlled by:

materialized_views_populate_atomically

and enabled by default.

Rows inserted through the same server during population are no longer missed or duplicated.

This applies to the local insert path only and requires a snapshot-capable source — the MergeTree family or Memory.

CREATE OR REPLACE, REPLACE, and Replicated databases keep the legacy path.

POPULATE also works with TO now.

Introspection port

A native-protocol TCP listener starts before tables attach and stops after detach completes.

This makes:

SHOW PROCESSLIST

and:

system.stack_trace

available during startup and shutdown.

Alongside it, shutdown_wait_unfinished moved from 5 seconds to 120 seconds.

The old default was shorter than the connection poll interval.

Keeper on-disk storage

Keeper now supports on-disk storage via a custom LSM tree.

Enable with:

use_lsmt_storage = true
storage_memory_only = false

Configure through:

data_storage_path

or:

data_storage_disk

This can point at an s3_plain disk for S3.

The Keeper dashboard also gains a Cluster tab showing Raft membership as a topology graph.

HTTP URL-path access to tables

Tables can now be accessed through HTTP URL paths such as:

/database/table.format.gz?filter=a>0

This is behind a set of http_allow_* opt-ins.

Framing output formats

framing_output_format multiplexes:

data chunks
totals and extremes
progress
profile events
logs
exceptions

into a single HTTP stream.

Available formats include:

EventStream
JSONEachPacketBase64
JSONEachPacketString

Also new:

default_session_user as a server setting
Prometheus constant labels via a <labels> element inside <prometheus>
ALTER TABLE ... MODIFY PROJECTION to change projection settings without a rebuild

Projection changes are applied lazily via merges.

Observability

Several useful observability improvements landed in 26.8:

`system.user_query_log`

Every user sees their own query log rows without needing access to:

system.query_log

`create_union_system_log_tables`

This creates auto-maintained all_... tables such as:

system.all_query_log

These union:

a log table
its rotated versions
the same table across cluster replicas

remote, remoteSecure, cluster and clusterAllReplicas now accept a trailing SETTINGS clause.

`system.mutations.finish_time`

Provides mutation duration without having to infer it.

`system.tables.skipping_indices_types`

Provides a cheap summary of which index types a table uses.

Play UI

The Play UI now supports:

server-side sorting
filtering
paging

These settings are encoded in the page URL so a shared link reproduces the result.

Joins and Text Search

`IEJoin`

IEJoin is a sort-based algorithm for ON clauses containing two inequality comparisons.

Previously such joins ran as a CROSS JOIN with a filter, and only as INNER.

Enable by adding:

ie_join

to:

join_algorithm

`parallel_full_sorting_merge`

parallel_full_sorting_merge shards a full sorting merge join by join-key hash across threads.

Upstream benchmarks put it around:

2.4x faster
3.3x lighter on memory

than parallel_hash, while keeping streaming memory behaviour.

The result is unordered.

New text index tokenizers

New tokenizers include:

japanese — MeCab
chinese — jieba-style dictionary plus HMM
icu — locale-aware Unicode segmentation
splitByRegexp — keeps tokens such as C++ and C# intact

Data Lakes

A number of data-lake integrations have been expanded.

BigQuery

A bigquery table function and BigQuery table engine are now available.

Authentication supports:

OAuth token
service account JSON
refresh token

Snowflake Horizon

Snowflake Horizon catalog support is available for reading and writing Iceberg.

S3 Tables

The S3 Tables catalog now supports:

INSERT

Puffin

Puffin file format support has been added.

URL database engine

A URL database engine and s3_base setting complete the URL unification.

ClickHouse®-local's default database now uses it with a file:// base.

This means:

SELECT * FROM 'https://example.com/data.csv'

works directly.

AI Functions

The experimental:

aiSimilarity
aiFilter
aiRedact

functions were hardened in this release.

Insecure http endpoints to remote hosts are denied by default.

Outbound calls per query are bounded at:

Provider error responses are also sanitised before logging.

Performance

ClickHouse® 26.8 contains 127 performance entries, with the majority enabled by default.

The improvements with the broadest reach include:

Aggregation

A new adaptive parallel GROUP BY allows each thread to aggregate into its own cache-resident hash table until it hits a threshold, then freezes it.

Other aggregation improvements include:

bounded-heap pruning for GROUP BY ... ORDER BY ... LIMIT
smaller hash-table cells for single-String keys
parallelised final merge of single-level tables
aggregations without aggregate functions now use HashSet rather than HashMap

The latter can be up to 1.8x faster.

Reads

Lazy materialization for Parquet on object storage can significantly reduce I/O.

For example, on a 200 MB S3 file:

ORDER BY ... LIMIT 10

read:

3.3 MB

instead of:

171 MB

That represents:

51x less I/O
8x faster

read_in_order_use_virtual_row is enabled by default and reduces peak memory when reading in primary key order across many parts.

The Parquet V3 reader also gains dictionary-page-based row group skipping.

Per-Partition Processing

DISTINCT, window functions and IN (subquery) set building can now keep each partition's rows in a single stream when the partition expression is a deterministic function of the relevant columns.

This skips the hash scatter entirely.

The Important Trade-Off

The trade-off worth stating plainly:

Query plans and resource usage will change after upgrading, even for queries you did not touch.

Most workloads benefit, but plan for a period of observation rather than assuming parity.

Upgrade Checklist

Before Upgrading

Check for dictionaries using the removed library source:

SELECT name, source
FROM system.dictionaries
WHERE source ILIKE '%library%';

Check non-default settings you are carrying:

SELECT name, value, default
FROM system.settings
WHERE changed;

And:

SELECT name, value
FROM system.server_settings
WHERE changed;

Then check by hand:

Named collections and dictionaries using MySQL ssl_ca / ssl_cert / ssl_key paths
NATS tables or collections using nats_credential_file
Reliance on the implicit /etc/metrika.xml substitutions file
PostgreSQL / MaterializedPostgreSQL databases against hosts outside remote_url_allow_hosts
Ingestion clients writing unquoted epoch numbers into DateTime64 columns via JSONEachRow
Queries using toDate32 on epoch-second values
Anything parsing EXPLAIN SYNTAX output
Tooling reading system.users.valid_until
Dashboards keyed on individual per-CPU or per-device asynchronous metric names

During a Rolling Upgrade

Pin:

patch_parts_version = 'v1'

and:

text_index_serialization_version = 'v1_with_codec'

until every replica is on 26.8.

Then remove both pins.

After Upgrading

Watch part counts and merge queue depth in:

system.parts
system.merges

for the max_insert_threads effect.

Also monitor:

system.errors

for:

UNACCEPTABLE_URL
ILLEGAL_COLUMN
UNKNOWN_ELEMENT_IN_CONFIG
BAD_ARGUMENTS

These cover most of the new rejections.

If you want to stage the transition:

SET compatibility = '26.7';

This restores the majority of the default flips in one move, letting you upgrade the binaries first and enable the new behaviour deliberately afterwards.

It does not cover removals or type changes — those need code fixes, which the checks above should surface.

Summary

The three changes most likely to affect a running deployment are:

1. `max_insert_threads` defaulting to `auto`

This changes part creation patterns and insert row order on every:

INSERT SELECT

2. Asynchronous metric consolidation

This can break dashboards silently rather than loudly.

3. Patch parts v2 format

This requires a rolling-upgrade pin on replicated clusters.

Beyond that, 26.8 is a strong release.

The security tightening around credential handling is overdue and welcome.

The operational additions — SQL-defined handlers, background queries, atomic POPULATE, and the introspection port — address real gaps.

And the 127 performance improvements, mostly enabled by default, represent a meaningful return on the upgrade work.

The key lesson is simple:

Treat ClickHouse® 26.8 as a real upgrade project, not just a version bump.

Review the defaults, test workload behaviour, validate observability, and plan the rollout carefully.

DEV Community: Kanishga Subramani

CH-Ops Scheduled Alerts: Know Before Things Break

What is CH-Ops

Introducing CH-Ops Alert Rules

Setting up an email notification channel

Creating an Alert Rule

From Query to Notification

A Simple End-to-End Flow

Why This Is Worth Setting Up

Further Reading

Next in the CHOps series

Search ClickHouse® Logs Without Writing SQL

What Is CH-Ops?

Exploring ClickHouse® Logs in CH-Ops

1. Crash Log: Investigating Server Crashes

2. Error Log: Finding Recurring Errors

Searching Error Logs

3. Text Log: Understanding Server Activity

Searching Text Logs

4. Session Log: Tracking Login Activity

From Overview to Search

When Should You Use Each Log?

From Investigation to Alerts

Bringing ClickHouse® Log Investigation Into One Interface

Explore CH-Ops

Next in the CHOps series

Watch your clusters live on CHOps

Complete Visibility into Your ClickHouse® Infrastructure

Introduction

Key Features & Dashboard Overview

1. Machine & Node Telemetry

2. Disk & Storage Health Check

3. Background Pools & Execution Shaping

4. Query & Time Execution Profiling

Dashboard Snapshot

Advantages of Using CHOps

Early Detection of Bottlenecks

Data Compression Optimization

Simplified Cluster Management

ClickHouse® Architecture: Clusters & Nodes Explained

1. What is a ClickHouse® Node?

2. What is a ClickHouse® Cluster?

Conclusion

Why CHOps telemetry is different

References

Next in the CHOps series

CH-Ops Schema Tools: Visualizer, Indexes & Projections

The running example

Schema Visualizer: how is this schema connected?

Node types

Navigation

The sidebar

The heatmap

Data Skipping Indexes: what already exists here?

Four types

Projections: a different representation of the same data

Grouping and ordering

Creating isn't the same as filling

Index Management: create, materialize, drop

Create

Materialize

Drop

From schema discovery to optimization

Conclusion

References

Next in the CHOps series

CHOps Is Now GA: Open-Source Operations for Self-Hosted ClickHouse®

Design a ClickHouse® Table Without Hand-Writing DDL: Schema Studio

What is CH-Ops?

Introducing Schema Studio in CH-Ops

Building a ClickHouse® Table with Schema Studio

1. Start with Your Source Data

2. Review and Shape the Schema

3. Define the ClickHouse® Table Design

Engine Configuration

Advanced Configuration

4. Generate and Validate the DDL

5. Review the Design with AI

6. Create the Table

Why Schema Studio Matters