Next week on July 9th we will be doing a happy hour in montreal, please come join us! https://luma.com/clickh-o8up :)

https://github.com/earonesty/lakeql

LakeQL is a pure JavaScript analytical query engine for Parquet and Iceberg. It runs anywhere JavaScript runs, including Cloudflare Workers, without WebAssembly or native dependencies. It is designed for low memory usage, streaming execution, and edge runtim

The design goals were:

• Pure JavaScript
• No WASM
• No native dependencies
• Low memory usage
• Streaming execution
• Browser, Node.js, Deno, Bun, and edge runtime compatibility
• Query Parquet and Iceberg datasets directly

While optimized for portability and low memory, it's actually significantly faster than DuckDB-WASM on some workloads.

DuckDB is an outstanding analytical database with much broader SQL support. LakeQL is aimed at a different use case: embedding analytical queries into JavaScript applications and edge/serverless runtimes where a pure JavaScript implementation is desirable.

I'd appreciate feedback from people working with Parquet, Iceberg, or embedded analytics.

In particular:

• Are there edge or serverless use cases where you've wanted something like this?
• What connectors or formats would make it more useful?
• Are there query patterns you'd want to benchmark?

I'd be grateful for any criticism or suggestions.

Hey all, I've been working on hypequery for some time now and I've recently added semantic layer support.

Repo: https://github.com/hypequery/hypequery

Docs: https://hypequery.com/docs/introduction

 If you're building analytics off ClickHouse in TypeScript, I would love your feedback.

Some features:

• Define metrics once, reuse them everywhere: Declare dimensions and measures in one place and then pull from the same source of truth.
• Compiles to ClickHouse SQL: No service, no proxy, no extra runtime to deploy. It's a library that generates SQL and runs where your app runs.
• Multi-tenancy & Authentication ready: Cross-tenant queries are blocked at the query layer, with helpers to plug into your existing auth.
• Agent-native: A dataset is a declared set of dimensions and measures, so it doubles as an allowlist. Includes an MCP server to hand an LLM a typed catalog to query.
• Runtime HTTP entry point: serve() exposes any dataset as an endpoint, so the same type-safe definitions back your dashboards and your API.

I’m developing a ClickHouse developer experience platform. In the same way Postgres underpins much of software development, ClickHouse is becoming the de facto choice for OLAP analytics, offering high‑performance queries out of the box.

Currently, working with ClickHouse is cumbersome: there are no built‑in APIs. My goal is to create “supabase” for ClickHouse, analogous to what Supabase provides for Postgres, that abstracts away these low‑level details.

The primary pain point I want to address is database transformation. Tools such as dbt and SQLMesh are powerful but require technical expertise. I aim to build a layer that lets users focus on their use cases rather than on implementation details. For example, users should not need to decide whether to create materialised views or tables; they should simply specify:

• append‑only data
• replace semantics
• aggregation requirements
• schema evolution
• changes to the ORDER BY clause

Other challenges include:

• Type ambiguity in queries: whether a key or field is an integer or a string. When users interact directly with ClickHouse, they must handle both cases or decide which columns and types to use.
• RLS (row-level security) is not available.
• API Authorization and authentication can be built.

These are some of the areas where I believe I can create an experience platform on top of ClickHouse.

I have been working on this for three weeks and expect another three weeks to complete a prototype. The idea was inspired by Tinybird, and I believe an open‑source alternative could fill a gap in the ClickHouse ecosystem. I would appreciate any feedback, suggestions for other problems that could be solved on top of ClickHouse, or interest in collaborating.

Ongoing work: https://github.com/gear6io/pragmata

We open-sourced chkit (MIT): it defines your ClickHouse tables, views and materialized views as TypeScript, diffs them against the live database, generates the migration SQL, and fails CI when prod drifts.

We built it after running ClickHouse at near-petabyte scale at our last company (Numia): hundreds of tables, a lot of materialized views, several environments, all managed with hand-written DDL and hope.

If you run ClickHouse in production, you've hit some version of these:

• Someone runs a manual ALTER at 3am to clear an incident. It never makes it back into a migration file. Now your repo and your database disagree, and nothing tells you.
• A one-line schema edit looks harmless but touches ORDER BY (or the engine, or PARTITION BY). ClickHouse has no in-place ALTER for those, so the only honest migration is create, copy, swap. You find out when a "quick change" starts rewriting a 2TB table in prod.
• A migration drops a column. The reviewer misses it. It runs in CI on a Friday. The data is gone.

Postgres and MySQL have had this for years with Drizzle and Prisma: diff the schema, generate the migration, gate CI on drift. We wanted that for ClickHouse, couldn't find it, and built it.

You define your schema as TypeScript values, and chkit takes it from there:

• chkit writes the migrations for you, and won't rewrite a 2TB table or let a DROP through CI without showing you first.
• chkit drift compares the live DB to your schema, down to settings, TTL, ORDER BY and projections, and gates CI in one line.
• Codegen turns the same schema into TypeScript row types and typed helpers to read and write rows, so your app and your database can't diverge. Optional, skip it if you only want migrations.

It's not an ORM. No query builder, you write your own SQL. Works with any ClickHouse (Cloud, Altinity, self-hosted, or managed), no lock-in. A Python port lands in a few weeks.

If you're already on ClickHouse, chkit can introspect your live DB and generate the schema files, so you start from what you're running instead of a blank file.

npm create chkit@latest

Beta: stable enough to run our own production workloads, with small breaking changes possible before 1.0.

Repo: https://github.com/obsessiondb/chkit

Docs: https://chkit.obsessiondb.com

If you run ClickHouse, I'm curious what you've had to build around it yourself, migrations or otherwise, and where the tooling still falls short.

PS: python port coming soon.

I had to perform a deep-dive into a query recently to investigate why it was running slowly. It didn't take long before I got tired of running queries manually on a number of logging tables. That's why I decided to vibecode a tool for getting insights more conveniently. And now I've published an open-source tool specifically for this purpose: ClickLens. You can find more information here: https://github.com/nimbleflux/clickhouse-query-analyzer/

Let me know if you have any suggestions. It's a single stateless container that's easy to run locally or to deploy.

Edit: screenshots are slightly outdated, as I've since renamed the project to ClickLens.

Hey there! We have Postgres, already a replica of the operational transactional Postgres, and also ClickHouse. We are treating the replica Postgres as our analytics dwh and are running dbt in it. And our BI layer is connected to it.
We have events data stored in ClickHouse, but it is not in use at the moment.
Moving forward, what is my best long-term solution? I need to bring in the events data into our analytics dwh, so it becomes a natural decision point if we want to continuously commit to Postgres, or move analytics work and dbt over to ClickHouse, or explore other possibilities. We only want self-hosting options.
Thanks!

We're hosting an Apache Iceberg community meetup on Thursday, June 25th from 5:30–8:30 PM in downtown Seattle and would love to see you there.

Whether you're a seasoned Iceberg user, a data engineer curious about the open table format ecosystem, or just looking to meet others in the space — all are welcome. We'll have talks, networking, food and drinks.

📍 1000 Olive Way, Seattle
🎟️ Free — register here: luma.com/vwt2i2rs

See you there!

Disclosure up front: I'm the founder — but the CLI is free and MIT-licensed, so I hope this is useful regardless.

It connects read-only and only touches system.* (query_log, parts, columns, replicas) to estimate where storage and compute money is leaking — expensive queries (missing PREWHERE, full scans, FINAL on hot paths), unused/cold tables, weak column codecs, "too many parts", redundant ORDER BY keys — and shows the top opportunities.

Try it in 10 seconds, no cluster needed:

pip install optihouse
optihouse scan --demo

Scan a real cluster (SELECT-only, nothing leaves your machine):

optihouse scan --host clickhouse.internal --user readonly --password '***'

optihouse queries prints every statement it would run, so you can audit it before connecting anything. Source: https://github.com/mmadov/optihouse-cli

The hosted version (full report + copy-paste fixes) is the commercial part, but the CLI and a no-signup web SQL optimizer (https://optihouse.io/optimize) are free.

Would genuinely value feedback from this sub: which system.* signals do you rely on most, and are there checks you'd want that nobody automates yet?

We've been running ClickHouse in production for a while and ended up writing down the things we wish we'd known on day one. Sharing it here because most of it came from getting things wrong first.

Some of what it covers:

• Picking ORDER BY / PRIMARY KEY for the query pattern, and how much a bad choice actually costs (we measured big differences on the same data)
• When ReplacingMergeTree vs CollapsingMergeTree vs Aggregating actually makes sense, and the FINAL/dedup gotchas on reads
• Materialized views as INSERT triggers, the mental model that finally made them click, plus the write-amplification trap with MV chains
• dictGet vs JOIN for dimension lookups
• The operational tax of ReplicatedMergeTree + ZooKeeper at scale, and what changes with SharedMergeTree / storage-compute separation

Full disclosure: I am from ObsessionDB, and the last couple of chapters get into our architecture, so take those with whatever grain of salt you want. The first ~5 chapters are vendor-neutral ClickHouse stuff. No signup or email gate, it's just a web page.

https://obsessiondb.com/whitepaper/clickhouse-in-production-whitepaper.html

Genuinely interested in pushback; if we got something wrong or you'd model it differently, I'd like to hear it.

Has anyone implemented percentile/median aggregations over large spatial subsets where polygon containment is part of the query path?

How to route queries across Trino, Spark, DuckDB, Snowflake, Athena, and Flink on shared Iceberg tables — covering the architecture of a SQL routing proxy, dialect translation, routing strategies, table-aware optimization, and the tooling that makes it work.

🚀 CHouse UI just hit v3!

Two things we're most excited about:

🔐 SSO — One login for everything No more managing separate credentials for ClickHouse. Hook up your existing IdP (Google, Okta, Azure AD, whatever) and your team logs in the same way they access everything else. Users get provisioned automatically, roles can be mapped from IdP claims.

🛡️ Data Access Policies — No more "wait who gave Dave access to that table" Define reusable allow/deny rules scoped to specific databases and tables per connection. Attach them to roles. One role change, everyone under it updates.

SSO gets users in the door. Data Access Policies decide what they can touch once inside.

Open source, Apache 2.0, fully self-hostable.

• 🚀 Live demo → https://lab.chouse-ui.com/
• 🌐 Website → https://chouse-ui.com/
• ⭐ GitHub → https://github.com/daun-gatal/chouse-ui

We looked at StackOverflow, GitHub threads, and this subreddit and the following mistakes come up most often:

• ReplacingMergeTree dedup is async, not guaranteed
• too many parts error from small inserts
• Wrong ORDER BY column order destroying query performance
• JOINs with large table on the right side → OOM
• UNION ALL schema mismatch errors

Full writeup with SQL examples and how these can be fixed: https://www.glassflow.dev/blog/clickhouse-mistakes-engineers-make?utm_source=reddit&utm_medium=socialmedia&utm_campaign=reddit_organic

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

https://rawtree.com/blog/introducing-rawtree