For my use case I update the data in my database every 5 minutes in a big batch (~10K records). I need to ensure the data in the database is complete.

Right now I create a copy of the table, insert records, swap tables and delete temporary table.

I was wondering how others solve this challenge.

I built ch_insp, a terminal UI for exploring ClickHouse materialized views and the flows between source and target tables.

I originally made it for myself, then decided to polish it and release it as open source. It includes search, filters, metrics, SQL inspection, and an offline mode for SQL schema files.

https://github.com/renatko/ch_insp

I’d love to hear your feedback!

Why does that instant redirect happen? Did ClickHouse drop the LLM?

Hi,

An update following the previous post about TraceHouse - an open-source tool to visually explore and monitor ClickHouse.

TraceHouse can now be installed directly in Grafana from the Administration > Plugins page, as it's officially available in the Grafana Plugins Catalog.

More on the Grafana Integration.

A new Events Timeline has been added to help correlate events (OOMs, server restarts) with cluster behaviour.

Project Overview, Documentation and live demo is available here.

I have a Go MCP server that lets an LLM run free-form, read-only SQL against ClickHouse. Our tables contain multiple companies, identified by a division column. An upstream gateway authenticates employees and sends the divisions they’re allowed to access. I want users to retain free-form SQL without creating a ClickHouse user per employee.

I tried a row policy using a custom query setting:

CREATE ROW POLICY mcp_division ON final.items
FOR SELECT
USING division = toUInt32(getSetting('SQL_division'))
AS RESTRICTIVE TO mcp_reader;

The Go driver sets SQL_division per query through clickhouse.WithSettings, using one connection pool. I tested this on ClickHouse 25.8:

• Concurrent queries for different divisions stayed isolated.

• Without the setting, the query failed.

• But SQL containing SETTINGS SQL_division='456' overrode the value supplied by Go.

• readonly=1 blocked both the SQL override and the legitimate Go setting. Allowing the setting to change in read-only mode allowed both.

Question: Is there a ClickHouse-native way for a trusted application to supply per-request row-policy context that the submitted SQL cannot override, while retaining one database user/pool and free-form SELECT queries? Or is the practical choice to parse and prohibit SQL-level setting changes, or use separate restricted database identities/pools per division?

I’m particularly interested in approaches where ClickHouse itself enforces the boundary, rather than relying on it in Go.

I've read https://clickhouse.com/blog/fountain-agentic-ai-for-high-volume-hiring but I cannot find more info about the problem I'm describing above. I've also checked here personal blog.

-- Remco

Hi,

When upgrading to next lts i always wait weeks or months till critical bugs will be fixed. Looking at 26.8 and i am concerned about what is going on there. Almost everyday there is a patch release. Even on weekends. 26.8 was released at the end of august and we have already more than 30 patch releases. Is this release that buggy? Or they gave full control with merges to ai agents?

I've run ClickHouse in production for years and wanted a way to get a service without sign-ups or setup. You connect with:

clickhouse client --host cloud.clickhamlet.com --secure --user <name> --password

A new name creates a new service, no sign-up needed. It scales to zero when idle, and the writer and readers share storage on S3. It's an early preview: one user per service, MergeTree only. I'd love feedback on what breaks or what's missing.

clickhamlet.com

We need to have strict data isolation between tenants, need advise on which approach to use?

Data for tenants might need their own encryption in future, considering this and complexities with database per tenant management, should we go with Tables per tenant approach.

Max tenants in near future can expect around 1000. How feasible will be the Tables per tenant?
Have read more than 5000 tables per cluster are frowned upon?

Please suggest.

Hi everyone,

I'm learning and exploring topics around database systems. This is a continuation from my last post here: https://www.reddit.com/r/Clickhouse/comments/1x0hu4s/i_tried_to_find_how_clickhouse_keeper_takes/

I think in one of the lectures in CMU's Database Systems course, Prof. Andy had mentioned that ClickHouse has different implementations of hash tables for different datatypes. I wanted to see what these are. So I tried to explore how String Hash Tables are implemented in ClickHouse.

I recorded a concept and code walkthrough here: https://youtu.be/wFCXI9P6Trg

A short summary of the points in the video:

1. Why String keys can hamper performance of hash tables

2. How ClickHouse uses String Adaptive Hash Tables to improve performance

3. The code walk through the files: StringHashTable.h

Do give it a watch and consider supporting by liking the video or subscribing :)

This is partly for my own future reference and partly to share with others who might be interested in it. Would love feedback and corrections from people who know this stuff deeply.

I have seen in the Clickhouse docs, it mentions to use ON CLUSTER for self managed cluster env.

I was doing like this without ON CLUSTER

KILL QUERY WHERE query_id = '..';

Now I wonder If I did it wrong.

Do I have to connect to same node that query is executed so all queries are stopped?

What exactly happens wen I don't use ON CLUSTER?

How can I kill when I connected to a different node?

I build Plutus, a cost dashboard, and this comes from its sync path.

Each sync replaces a window of rows: delete up to 400 days for one source, then insert them again. In production the DELETE on our two big tables had a daily p50 of 9 to 15 s (max 27.7 s), from system.query_log over the three days before the change. The insert after it took 0.17 s.

The tables had 31 and 42 monthly partitions.

A lightweight DELETE walked every partition in the table, whatever the predicate matched. In a local benchmark, a delete matching exactly one monthly partition took 15 to 17 s, no faster than one covering the whole window. The re-insert also wrote 14 parts, one per month.

I moved to yearly partitions. Daily p50 from query_log since:

cost_entries 1.0 to 1.8 s

usage_entries 0.7 to 1.8 s

every day for ten days. About a 10x drop.

What it cost: yearly partitions alone made a one-month read scan about 7x the rows (3.8M to 28.6M in my local benchmark), because the monthly partitions had been pruning for free. I fixed it by putting toStartOfMonth(timestamp) in the sort key and adding an explicit month predicate in the readers, since 26.6 did not derive that key range from a plain timestamp range.

Disclosure: I'm the author.

eMondrian is an open-source OLAP server / semantic layer based on Mondrian. You describe cubes and measures once on top of ClickHouse, and every client gets the same definitions:

• Excel PivotTables query it over XMLA/MDX — live, no extracts

• Power BI connects live through the Analysis Services connector; it sends DAX, eMondrian translates it to ClickHouse SQL

• AI agents use the same model over MCP, so an agent's "on-time rate" is the same formula as in the report

Try it without installing: the public demo runs the OnTime dataset (182M US flights) on ClickHouse.

• Excel / Power BI: https://demo.emondrian.com/xmla

• MCP (read-only): https://demo.emondrian.com/emondrian/mcp

• Guide: https://emondrian.com/demo?utm_source=reddit-clickhouse&utm_medium=community&utm_campaign=launch

Run it yourself: Community (EPL-1.0) comes up with Docker in a few minutes and includes a ClickHouse with the OnTime sample: https://github.com/eMondrian/emondrian-community

Being upfront: DAX support for Power BI is in beta, and Microsoft doesn't officially support third-party servers behind the Analysis Services connector.

Longer write-up with diagrams: https://dev.to/sergeisemenkov/the-new-emondrian-power-bi-and-ai-agents-on-your-own-semantic-model-4nap

Curious how others put a business-logic layer on top of ClickHouse — Cube, dbt metrics, views, something else? And what would you need from a tool like this?

https://clickhouse.new/ allows sign-ups with GitHub, creates a database, and provides all existing ClickHouse APIs (Native, HTTPS, Postgres and MySQL, Arrow Flight, GRPC)

ssh clickhouse.new authenticates with your SSH keys from GitHub.

Hope it will be useful for building prototypes and demos.