For a long time my dashboard workflow looked like this: write the query in one tool, copy it into Grafana, wrestle with a data source connector, build the panel, and then maintain that connector forever. The data lived in ClickHouse®, but the dashboards lived somewhere else, and keeping the two in sync was a standing tax. Building dashboards directly on ClickHouse®, in the same place I write the queries, removed that tax entirely.
The cost of a separate BI tool
External BI tools are powerful, and for big organizations with many data sources they make sense. But for a team whose analytics live in ClickHouse®, a separate dashboard tool adds a layer that mostly creates work. You deploy and maintain it. You configure and update the ClickHouse® connector. You manage a second set of users and permissions. And you context-switch constantly, writing SQL in one place and building charts in another.
For a lot of teams, that overhead is bigger than the value. You do not need a federated BI platform to chart a ClickHouse® query. You need to run the query and see it as a chart, in one place.
Query and chart in the same place
That is the idea behind CHOps dashboards. You are already in the tool writing ClickHouse® SQL. A dashboard panel is that same SQL, shown as a chart instead of a table. There is no connector, because you are already connected to the cluster. There is no second tool, because the dashboards live next to the query editor.
The workflow collapses to: write the query, pick a chart type, add it to a dashboard. When the data model changes, you edit the query in place. The dashboard reads live from ClickHouse®, so there is nothing to sync and no copy of the data sitting in another system getting stale.
What you give up, honestly
I want to be fair about the tradeoff. A dedicated BI platform will do things a database-native dashboard tool does not: blending many disparate sources, a semantic modeling layer, the most elaborate visualizations. If you need to join ClickHouse® with five other systems in the dashboard layer, a BI tool is the right call.
But if your dashboards are fundamentally "show me this ClickHouse® query as a chart," which describes the large majority of operational and product analytics dashboards I build, then a database-native tool is simpler, faster, and one less thing to run. You stop maintaining infrastructure whose only job is to draw your ClickHouse® data.
The speed advantage
There is a performance angle too. ClickHouse® is fast, and when the dashboard queries it directly, your charts are fast. A lot of the slowness people blame on dashboards is actually the BI layer, its caching, its query rewriting, its own database round-trips. Querying ClickHouse® directly keeps the speed that made you choose ClickHouse® in the first place. A dashboard that updates as quickly as the database can answer feels completely different to use.
Where to go next
Once you are building dashboards on ClickHouse® directly, the next questions are which chart to use and how to lay things out. I wrote about picking the right chart type for ClickHouse® data, and about the drag-and-drop dashboard builder for arranging panels without touching configuration files.
The short version: if your analytics live in ClickHouse®, you can probably build your dashboards there too, and skip a whole tool. The dashboards feature page shows the chart types and layout options. For most teams, less infrastructure and faster charts is an easy trade to make.
