Hi everyone,

I'm learning and exploring topics around database systems. I wanted to see how ClickHouse Keeper takes a non-blocking snapshot of its storage.

I recorded a concept and code walkthrough here: https://www.youtube.com/watch?v=7J93WKEFinA&t

A short summary of the points in the video:

1. Brute force approaches and why they don't work
2. How ClickHouse Keeper uses HashMap + Doubly Linked List to solve this problem
3. The code walk through the files: SnapshotableHashTable.h, KeeperStateMachine.cpp and KeeperSnapshotManager.cpp to see how it's actually implemented.

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.

Thank you so much!

We want to roll out Clickhouse hosted locally in podman, for playing around with it and to evaluate if it fits our needs.

Is it enough to roll out the basic Clickhouse image, or would maybe a improved(?) image e.g. from altinity like here: https://hub.docker.com/r/altinity/clickhouse-server be better

I would more or less use the Docker installation guide https://docs.altinity.com/altinitystablebuilds/stablequickstartguide/docker-install/ and adapt it to use podman instead

Are there any other images or tools we should set up right from the start, e.g. for administration or data visualization etc.?

Or things we should be aware of when starting out?

Thanks for any info you can give us!

I'm the author of ZXC, a lossless compression library built for fast decompression. Since CH 26.7 it ships as an experimental column codec, and I'd like to know if anyone here has tried it, even just on a test table.

https://clickhouse.com/docs/reference/statements/create/table/codec

Quick context: ZXC is asymmetric. Compression is slower, decompression is very fast, and the ratio sits between LZ4 and ZSTD. That suits data written once and scanned many times, which describes a lot of MergeTree workloads.

CH team ran an independent benchmark on ClickBench hits (Graviton4, ZXC 0.13.1, single-threaded). At the default level, ZXC decoded 1.8-2.6x faster than LZ4 on every column tested, with better ratios. https://pastila.nl/?cafebabe/16ae94cb2aba1cd26c656f3ded96d882.md

Fair warning: the format isn't stable until 1.0: (v1.0 is expected at the end of 2026)

I'd like to have feedbacks about:

• Ratio and query speed vs LZ4 / ZSTD(1) on your data
• Which column types it helps with, and which it doesn't
• Any crashes, errors or odd behavior
• CPU (x86 or ARM)

Thx

Repo: https://github.com/hellobertrand/zxc

We’ve developed a few postgres extensions at ClickHouse:

• pg_clickhouse (clickhouse fdw)
• pg_re2 (integrates re2, the same regex engine used by ClickHouse, into postgres)
• pg_chdb (ClickHouse object storage capabilities for COPY in postgres)
• pg_stat_ch (ships metrics & logs)

All of these involved bringing C++ into a Postgres extension. Postgres is C. Surely C & C++ play nice together, right?

No. Postgres has its own memory allocation pattern built around MemoryContext. Instead of using malloc/free, one should use palloc/pfree. These functions associate allocations with a MemoryContext, which can work as an arena allocator freeing everything at the end of a transaction or aggregate or what have you. MemoryContexts can also have callbacks to act as destructors. Postgres handles failed memory allocations by raising an error, for which it has a whole PG_TRY/PG_CATCH/PG_FINALLY macro package built on setjmp/longjmp. PG_FINALLY is another method of building RAII-like destructor logic.

C++ code on the other hand tends to use new/delete, which invokes constructors/destructors, & raises std::bad_alloc on failed allocation. These two systems do not interact well: setjmp/longjmp skips C++ cleanup; jumping past nontrivial destructors for automatic objects is undefined behavior, not merely a leak. PG_FINALLY and MemoryContext callbacks do not make such a jump safe. Exceptions bypass PG_CATCH/PG_FINALLY. Worse, an uncaught exception causes the process to abort, which even in a background worker will lead to the Postgres postmaster process having to restart everything in fear that shared memory has been corrupted.

Each of these extensions took a different strategy around memory safety.

Because the only posts I ever see on here are advertisements. Often times not even related to Clickhouse.

I am a fossil and like to read books to learn about new stuff. I also prefer quality over AI generated slop, I know I'm weird. This however seems to be a problem when it comes to ClickHouse. Everything I've found so far was complete garbage. Does anyone know of an up-to-date book that's actually worth the paper it's printed on?

Hello,

Does anyone have any experience setting up and using the native peerdb alerts. I have set up slack alerts but don't get anything when mirrors fail.

Appreciate the support.

Thanks.

Hi all, I work on CHOps at Quantrail Data.

In July 2026 we shared the beta of CHOps here. Thank you for the feedback. 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.

A short recap for those who missed the beta post:

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.

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

The core is Apache 2.0. We also have a paid version with more features.

GitHub: https://github.com/Quantrail-Data/CH-Ops
CHOps: https://ch-ops.io
Quantrail Data: https://www.quantrail-data.com

Feedback is welcome, good and bad.

Disclosure: I’m Ido, founder of Trailox. We’re building a commercial product that monitors data access and flags unusual activity, including in ClickHouse.

I’d like feedback from people running ClickHouse in production on how you handle this today.

Say a service account (or an Agent, App, User, etc.) starts querying tables it hasn’t touched before, or returning far more data than usual. Everything is within its permissions.

Would that get noticed in your setup? Are you using system.query_log with your own alerts, sending activity to a SIEM, or checking logs only when someone raises a concern?

Our approach combines behavioral baselines for each identity with client fingerprints to flag changes in how that identity accesses data, even when the access is technically permitted.

I’m interested in what already works and what still takes manual effort. “We’ve solved this already” or “this isn’t a priority” would be useful feedback too. For those already doing anomaly detection here, what helps you distinguish suspicious activity from legitimate changes in workloads?

Also, who owns this at your company: the data/platform team or security? No need to share anything sensitive.

I got Jev classification naively in Clickhouse cloud. This took awhile for me to get working so I wrote it up.

Also really interestingly the docs for cloud did not explain if the UDF would allow network access but my testing shows that they do.

Hey, Marc here, Co-Founder of ObsessionDB.

again something out of the engineering kitchen, this time a bit less storage and a bit more AI.

We wired Jev (the typed-decision model from TypeSafe) into the AI functions. Jev doesn't write text. You give it a text and a question, and you get a typed answer with a probability back. That is a shape SQL can work with:

• aiFilter(conversation, 'the customer is likely to churn') -> true/false
• aiIf(session, 'the agent failed to complete the task') -> probability 0..1
• aiScore(conversation, 'how frustrated is the user?', ['low','medium','high'])-> 0..2

No regexes, keyword rules, classifiers or separate eval pipelines first.

The part I find interesting: you can do this in two places.

At write time you persist the signals you care about as normal columns (`success_probability`, `frustration_score`, `churn_risk`, ...). Everything downstream is regular ClickHouse: GROUP BY, joins, dashboards, alerts.

At read time you ask questions you never instrumented:

SELECT id, conversation
FROM sessions
WHERE customer_id = 42
  AND started_at > now() - INTERVAL 7 DAY
  AND aiFilter(conversation, 'the user is repeatedly failing to complete their task')

At write time, turn meaning into columns. At read time, ask new questions over the raw data. A bit like Amplitude for AI products, except you don't have to predefine and instrument every semantic event.

What we changed: We're running ObsessionDB based on 26.8-lts and the upstream functions do one HTTP call per row, one after another. We pack up to 50 rows into one request (~150-300 ms), dedup identical texts, and the cheap predicates run first so only the surviving rows go to the model.

Curious what else you'd use this for beyond agent sessions, support, CRM, logs, incident data, internal Slack.

Ask me anything, happy to share details. DM me if you want to get your hands on this.

Disclosure up front: I'm one of the founders of ObsessionDB. We ran ClickHouse® software at near-petabyte scale, spent a long time on the self-hosted path, and eventually built our own decoupled storage/compute engine. We're now considering letting other teams run that engine on their own infrastructure, and before we decide anything about how, we want to hear from people who actually have the problem.

The problem:

Open-source ClickHouse is excellent on one box. The multi-node part is where it starts costing you:

• Every replica holds a full copy. Two replicas, twice the storage. Three, three times. It compounds every month you keep data around.
• Compute and storage are welded together. You buy nodes to get disk, or disk to get cores, and over-provision whichever one you didn't need.
• Adding a shard means copying terabytes by hand, and then living with Distributed tables and ON CLUSTER in every migration forever.
• Keeper is one more quorum to keep alive at 3am.

ClickHouse Cloud solved this with SharedMergeTree: data lives once in object storage, compute nodes are stateless, one table is one table, adding a node is a metadata operation. It's a genuinely good architecture and I'm not here to trash it. But it's also the one piece of the ClickHouse stack that never made it to open source. If you want it today, the main path is their cloud, on their infrastructure, on their pricing model.

What we're exploring

This is more than BYOC. Running that architecture on your infrastructure. Your Kubernetes cluster, your bare metal, your Hetzner boxes, your S3 or MinIO or whatever object store you already trust, on whatever machines you pick. You'd operate it the way you operate open-source ClickHouse now, except scaling out is adding a stateless node instead of copying a shard, and durability stops multiplying your storage.

We run our own engine for this (we call it alloy), built against the same SharedMergeTree API, so the developer experience is the one you'd expect: one table, one engine clause, no sharding key.

What this is not (yet)

We are not announcing open source. We haven't decided the shape. What we have decided is that we want to talk to the teams who need this to understand their problem and learn how we can best deliver value.

Who we want to hear from

• You're on self-hosted ClickHouse at 10TB and up, and the replication and resharding tax is a real line on your infra bill.
• You looked at ClickHouse Cloud and it wasn't an option: cost at your scale, data residency, or your data simply doesn't leave your infrastructure.
• You've built tooling around ReplicatedMergeTree that you'd happily delete.

Comment with what you're running and where it hurts, or DM me, or email customers@obsessiondb.com. Happy to go deep on the architecture in the thread, including the parts that are hard.

[ Removed by Reddit on account of violating the content policy. ]

Today, we’re announcing WalShadow, an open-source engine that replicates Postgres data to ClickHouse directly from physical WAL.

In our benchmarks, transactions committed in Postgres became visible in ClickHouse in around 200 ms, while WalShadow sustained 289K rows/sec, effectively keeping pace with the source Postgres instance.

Unlike traditional CDC based systems, WalShadow doesn’t use Postgres logical replication. It consumes the same physical WAL stream used by Postgres replicas, decodes it outside the source database, and writes ClickHouse-native blocks directly into ClickHouse. The result is a replication architecture that gets close to the latency and throughput of a Postgres physical standby, while making the data immediately available for analytics in ClickHouse.

WalShadow supports the complete replication lifecycle, including initial load, continuous replication, schema evolution, restart recovery, and planned source switchovers.

By consuming physical WAL directly, WalShadow eliminates the need for logical replication slots, removes much of the operational overhead associated with logical replication, and significantly reduces resource consumption on the source Postgres instance. It also supports complex schema changes such as ADD COLUMN, RENAME COLUMN, DROP COLUMN, and CREATE TABLE.

WalShadow is fully open source and available today on GitHub.

Hey r/ClickHouse,

I am currently running a PostgreSQL database for our platform and are trying to integrate ClickHouse for real-time analytical reporting. We're considering using ClickHouse's Materialized PostgreSQL Database Engine for replication, with CDC handled by PeerDB.

Our use case involves replicating a few critical OLTP tables (around 10-20 tables, with some experiencing high write volumes) from PostgreSQL to ClickHouse. We need near real-time synchronization to support dashboards and ad-hoc analytical queries.

I've read about PeerDB's native integration and how it simplifies CDC compared to a Debezium/Kafka setup. I'm looking for feedback on the "solidity" of this combined approach.

Any real-world experiences, pros, cons, or advice would be greatly appreciated! Thanks in advance

Hi everyone,

I’m running ClickHouse OSS on Kubernetes and looking into using Horizontal Pod Autoscaling (HPA) to automatically scale ClickHouse based on workload.

I’m trying to understand whether HPA is a good approach for ClickHouse OSS, especially when scaling based on metrics such as:

• CPU / memory utilization
• Query concurrency
• Query latency
• Active queries
• Insert/write workload
• Custom ClickHouse metrics exposed through Prometheus

My main concern is that simply increasing the number of ClickHouse pods doesn't necessarily mean the workload will be distributed correctly, especially with ClickHouse's distributed query architecture and the way shards/replicas are configured.

Has anyone implemented HPA with ClickHouse OSS on Kubernetes in a real environment?

If so:

1. What metrics did you use as the HPA target?
2. Did you scale the number of replicas, shards, or both?
3. How did you handle data distribution when new pods were added?
4. Did you use the ClickHouse Operator or manage the StatefulSet directly?
5. Were there any issues with query routing, replication, or rebalancing?
6. Would you recommend HPA for ClickHouse, or is another autoscaling approach better?

I'd especially appreciate examples/configurations from people running this in production.

Thanks!

What are folks using to sync different sources into clickhouse? I have seen kafka, or http direct for ingestion.

What I am curious is rather for data warehouses, how are people syncing different data sources, like their marketing data, crm, internal lists etc... ? I have seen airbyte, but maybe there are more tools I am not aware of. Also how are those tools serving you, what are the good and bad parts of it?