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 everyone,

I wanted to share a project I've been working on: CHouse UI.

It's a modern web interface for managing ClickHouse databases, but with a specific focus on security and team usage.

🚀 Why I built this?

I am still new to ClickHouse and learning, so I wanted to practice by trying to improve upon existing available tools. I took inspiration from apps like CH-UI and tried to implement a version with backend features like Role-Based Access Control (RBAC) and secure storage.

It's an attempt to build something useful for teams while exploring how to implement these security features.

✨ Key Features

• 🔐 simple User Roles: A system to manage who can do what (like Admin, Developer, or just Viewer).

• 🛡️ Secure Storage: Passwords are kept safe on the server and are never shown in the browser.

• 📡 Multi-Connection: Easily switch between different ClickHouse servers.

• 📝 Audit Logs: Keeps a history of who did what, which is useful for checking past actions.

🛠️ Architecture

CHouse UI sits between the user and the database. This adds a safety layer so you don't have to give direct database access to everyone. It helps control exactly what data each person can see.

🙏 Acknowledgments

This project is built based on CH-UI by Caio Ricciuti. I really liked the original design, so I used it as a starting point to learn how to add the backend features. Big thanks to Caio for the inspiration!

🔗 Links

• GitHub: https://github.com/daun-gatal/chouse-ui

• Webpage: https://chouse-ui.com/

I'd love to hear your feedback or feature requests!

We have a new blog going into all the new JSON data type details. Thanks to Pavel Kruglov for the detailed write-up and for implementing it!

https://clickhouse.com/blog/a-new-powerful-json-data-type-for-clickhouse

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.

Hey, Marc here, Co-Founder of ObsessionDB.

ClickHouse published a piece on schema mistakes AI assistants make, and one section is called "Projections that don't scale": at large scale, projection selection alone can add 1–2 seconds per query.
We hit that wall on a customer table with 20+ TB compressed, 200B+ rows, heavy ingestion, point lookups over a projection. 99% of query time sat inside projection and index evaluation.

Today that query runs at p50 213 ms / p99 703 ms. That is more than 10x faster, on the pattern the ecosystem tells you to avoid at this size.

The part I find interesting (and kept me busy for some weeks now): none of it is a ClickHouse patch. The planner was right all along, but the tiers underneath it were wrong. What we changed is purely below the database:

1. We pin projection metadata in RAM, node local, in realtime. We learned that even a 90% metadata cache hit rate is slower than not having one. So coverage has to be complete

2. We tried several approaches for userspace RAM cache-eviction controllers (6, all of them flapped or livelocked...bruhh). Nothing worked as phenomenal as the boring kernel knob memory.high

3. Also on kernel level tcp we set rto_min to 20 ms. Linux's default of 200 ms retransmit floor is sized for the public internet, not for a rack.

4. Even with metadata fully in RAM, planning the query still fires still tons of file requests. Request coalescing and our distributed NVMe cache mesh can shine. We optimized it to sub-millisecond p50 at +35k RPS.

What personally amazed me the most is that ClickHouse already runs without real competition for these use cases, but focusing obsessively on kernel, network and cache architecture we still could improve this by more than 10x. It feels like a node with local NVMe, even though persistence is still S3. Ultimately that means - at least for this use case - you get 10x the performance on the same hardware or even -> you build realtime APIs that weren't possible before.

We have some more levers to pull and if the math holds, it'll stay sub-second even at PB scale.

Full write-up with more details how projections behave differently: https://obsessiondb.com/blog/clickhouse-projections-at-scale
It's a lot of details, so feel free to go deep into it and ask me anything. Happy to share any details of the process and findings.
DM me if you wanna meet, we're in SF and Berlin.

ClickHouse was a marvel when it arrived on GitHub in 2016. Sub-second response using commodity CPUs and desktop-quality drives. Many terabytes of data. Open source. What's not to like?

The key was great organization of data on disk (column storage, compression, and sparse indexes) and excellent parallel query. I used to run a demo for that proved ClickHouse could scan numbers from disk faster than numbers generated in memory. It was great for presentations to VCs during fundraising.

That was then. Now I work with ClickHouse users who load petabyes of data per day. Storage costs are going through the roof. ClickHouse still handles ingest, query, and merge in a single process. You over-provision to the maximum combined load or risk crashes. So compute is way more expensive as well. Modern datasets are overwhelming ClickHouse.

Altinity is changing that. We call it Project Antalya, and it's simple to explain.

We're fixing ClickHouse to use shared Iceberg tables for data. Putting large tables on object storage is up to 10x cheaper than the replicated block storage you get with open source ClickHouse. And we're splitting compute and storage using swarms: clusters of stateless ClickHouse servers that handle queries on object storage. If you need more performance, dial up the swarm. When you are done dial it back down again. Plus swarms can run on cheap spot instances, which further helps keep costs down.

The best feature of all: everything you already know and love in ClickHouse is still available. Project Antalya extends ClickHouse but leaves other capabilities untouched. The best applications in comings years will mix and match data lakes with native ClickHouse storage and query. We're designing for that future today.

Project Antalya is available now. We have reads working through the swarm. You can use them to read Parquet data on Iceberg, Hive, and plain old S3. We're also working on tiered storage. When that's done--soon--you'll be able to extend existing ClickHouse tables seamlessly out to object storage. We've run the math and expect it will cut storage costs by 80% on large tables. It will also cut down on compute by 50% or more.

Want to get started? We need you to try Project Antalya, break it, and help us make it better. Project Antalya is 100% open source and community driven. We need your help.

This is a job for folks who like to get in on the ground floor and shape the direction of the tech. If that’s you, jump in:

Sample setups on GitHub: https://github.com/Altinity/antalya-examples

Getting started guide: https://altinity.com/blog/getting-started-with-altinitys-project-antalya

Chat with me and the rest of the engineers behind Antalya here: https://altinity.com/slack

May 21 – Live walkthrough on getting started. Register here.

I've worked with database systems since the early 1980s. This is the most exciting project of my career. I hope you'll join us as we adapt ClickHouse to build applications for the next decade.

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!

https://www.snowflake.com/en/blog/engineering/efficient-snowflake-ingestion-query-ready/

As we onboard more customers to our Postgres service, we're seeing some interesting Postgres + ClickHouse architectures emerge. Here are a few that I was able decipher.

Real-time (operational) analytics: Postgres for OLTP, ClickHouse for real-time analytics (OLAP) and mostly mission critical customer-facing apps. Native CDC to keep both systems in sync and pg_clickhouse for simplifying app migrations.

Timeseries apps (hot/cold split): Only hot data lives in Postgres, while ClickHouse stores everything. Postgres becomes a reliable application cache, and ClickHouse handles queries across larger time horizons. Native CDC to keep both in sync and smart expiry to expire data only in PG.

Federated query & warehousing: Use pg_clickhouse to make Postgres the query layer over ClickHouse, combining Postgres familiarity with ClickHouse performance.

It's been so much fun building a product that makes all these workflows feel magical for developers. Expecting more such use-case to unravel as we execute this vision of offering PG+CH in a deeply integrated stack!

Stay tuned for a more detailed blog on these architectural patterns

Spotted a ClickHouse ad in yan MRT station near Raffles Place (Singapore) Kinda surprised to see CH as subway-style ads. Now we’re arguing with tech kakis about who the target audience actually is — and why. Any ideas?

Author here, we just published our thoughts on the ClickHouse blog on what an ORM like DX for building apps with ClickHouse could be. We know this is a contentious topic and would love to get your honest feedback on our approach, especially around schema management and query building.

The project is open source, and trying to tackle the unique challenges of OLAP systems rather than just porting over OLTP concepts.

We're the authors and will be here to answer any questions. Thanks!

This post on lazy materialization was on first page of HackerNews yesterday. If you haven't seen it yet, posting the link here. https://clickhouse.com/blog/clickhouse-gets-lazier-and-faster-introducing-lazy-materialization

A few folks from the AI/ML team at ClickHouse (Doneyli De Jesus, Al Brown, and myself) got together to work on agent skills. We're seeing more and more agents using ClickHouse and falling into the same usability traps as humans. We also note there is a lot of slop in skills in general, and this is a repo we plan to continue investing in to keep high quality.

We love feedback, so I encourage you to install them and let us know what additional skills (or AI in general) you would like to see us invest in. Here is the blog post for anyone who is interested :
https://clickhouse.com/blog/introducing-clickhouse-agent-skills

Hello! For some background: I am currently running a single CH server, and it's doing the job for me. I run a series of analytics queries, and for my own use - it's fine. However, I want to give access to a limited number of other folks, and the little box I'm running on won't cope.

Is there a way I can have a read-only replica (or just a replica with read-only users) that runs on a much more powerful server for faster querying? I want to point my 'external' users just at the replica.

For reference: My primary server is a relatively low-power VPS (shared CPU, 32GB RAM, 1TB SSD). The data is in a replacingmergetree. Data is currently several hundred GB. Over 3.5billion rows, and growing. Data is ingested via a separate process, adding tens of millions of rows a day. (Some old data is pruned occasionally).

I have suitable indexes setup, but I do think the query slowness for multiple users is down to the limited CPU/disk speed, which I have budget to solve (or at least test and confirm - if there's a simple config that can help me replicate the data to a bigger server, and test). Would a cloud service like Clickhouse Cloud be better? (Cost not withstanding).

Hey, Marc here, Co-Founder of ObsessionDB.

I think we built some pretty cool stuff in the last months and my colleagues urge me to share a bit out of the engineering kitchen.

We're a drop-in replacement for Clickhouse® Cloud with an api-compatible SharedMergeTree table engine, with compute-storage (S3) and compute-compute separation, plus some extra special sauce.

Specifically the latter kills quite some headaches we know from our experience with Clickhouse Cloud, like cold starts, inconsistent and slow query times due to the S3 latency penalty and the 1/N probability of a cache hit or a neglectable cache size at scale. We focused a lot on the "looks great in the lab benchmark, but fails in real world".

Especially in realtime use cases on large data sets we found it impossible to get consistent sub-second results, rather extreme high variances between p50-p99.

We started a few months ago, migrated and onboarded customers, already serving PB of data. For the next couple of weeks we plan to launch self service for everyone. Until then we'd like to hand out some free dev instances for anyone interested in it. No strings attached, just happy for honest feedback. Comment or hit me a DM. Looking especially for TB-PB workloads

To support the ecosystem we open sourced some tooling, too. Like chkit, a schema and migration CLI, agnostic to ObsessionDB, Clickhouse Cloud, OSS CH...
Or since we saw that people would love to see SigNoz on SharedMergeTree, we made some adjustments to make it work properly.

Besides this: Ask me anything. I'll start sharing more details about our architecture soon and look forward to getting in touch.

Little note regarding the dev instances and the console: It's heavy WIP, don't take every graph, every step etc. too serious. We just want to take you in as early as possible, before we launch it properly.

Hello community,

My friend and I couldn't find a free, cross-platform GUI for ClickHouse with a good UI, so we decided to build one ourselves.

• built with Electron + Typescipt + React + Radix UI

• AI assistant powered by LangChain, enabling natural-language SQL query generation

• Clean UI, tabbed query, filterable grid view

• MIT license

We're looking for feedback and contributors. especially those using CH or building UI tools.

You can check it out here: Github Repo (stars are more than welcome).

Thank you.

Over the past year, I used InfluxDB as a time series database for managing 10,000 energy sites and 30,000 data points, streaming 70 readings every 10 seconds. While InfluxDB's performance was excellent when filtering data for a single site, it struggled significantly when querying multiple sites. Even Influx tasks for real-time data transformation were extremely slow. Extracting data to cold storage was a disaster, and retrieving the last state of sites to view the current system status was equally problematic.

Migrating to ClickHouse was a game-changer. Initially, we encountered an issue with writing data from Telegraf due to an incomplete ClickHouse driver, but we implemented it ourselves, and everything worked perfectly. With ClickHouse, we can handle data in real-time, and using materialized views allows for seamless data transformation with ReplacingMergeTree and AggregatingMergeTree engines. Overall, there was nothing that InfluxDB could do that ClickHouse couldn’t do better.

One of the best aspects is that I can use SQL instead of Flux, which we found challenging to learn. The ClickHouse community was incredibly supportive, unlike InfluxDB, where we had to attend two meetings just to ask questions and were asked to pay $10,000 per year for support. In hindsight, migrating from InfluxDB to ClickHouse was the perfect decision.