{"id":47076311,"title":"Show HN: Run SigNoz on ObsessionDB and ClickHouse Cloud","points":2,"user":"alvarogar","time":1771521614,"time_ago":"5 hours ago","type":"link","content":"

Hey HN, I'm Alvaro. I work on ObsessionDB, a managed ClickHouse service. We run petabyte-scale ClickHouse infra as a service.

We open-sourced a fork of SigNoz's schema migrator that makes SigNoz work on SharedMergeTree. That means it runs on both ObsessionDB and ClickHouse Cloud.

The problem: SigNoz's production setup assumes sharded ClickHouse. The official docs spec 56 CPU cores, 152 GiB RAM and 10 nodes including 3 ZooKeeper instances. Your observability tool becomes its own ops problem.

SigNoz's schema creates `_local` tables (ReplicatedMergeTree) and `Distributed` tables on top. Our migrator does three things:\n- Creates the `distributed_*` tables as SharedMergeTree (this is where data actually lives)\n- Creates the local table names as VIEWs pointing to the SharedMergeTree tables\n- Redirects Materialized Views to write to SharedMergeTree directly, since VIEWs can't receive inserts

SigNoz doesn't know the difference. The Query Service reads from the same table names. The OTEL Collector writes to the same table names. No core code changes.

This works with ClickHouse Cloud too, not just us. Same docker compose, different credentials.

Repo: https://github.com/obsessiondb/signoz-obsessiondb\nBlog post with the full technical walkthrough: https://obsessiondb.com/blog/scale-signoz-on-obsessiondb

What other ClickHouse-backed tools would benefit from SharedMergeTree support? Would love to hear what you're running into.","url":"https://github.com/obsessiondb/signoz-obsessiondb","domain":"github.com","comments":[],"comments_count":0}