ClickHouse® is one of the fastest analytical databases you can run. We have used it for years on client projects, and the speed still surprises people the first time they see a billion-row aggregation come back in under a second. But there is a gap that anyone running it in production runs into eventually: managing the thing is mostly a command-line job. You SSH into a node, you run clickhouse-client, you read config files by hand, you write ad-hoc SQL against system tables to figure out what is going on. That works when one engineer owns the cluster. It stops working when a team does.
We built CHOps to close that gap. This post is the why behind it.
The day-to-day problem
Most ClickHouse® teams I have worked with end up maintaining a private collection of "remember to run this" queries. One person knows the query that shows which merges are stuck. Someone else has a script that lists slow queries from the morning. The backup process lives in a cron job that two people understand. None of this is written down in one place, and none of it is visible to the people who actually need it during an incident.
The result is that operating ClickHouse® depends on tribal knowledge. New team members take weeks to get productive. On-call engineers page the one person who knows the magic query. And because everything happens over SSH on production boxes, every routine task carries a small risk of a big mistake.
The database was never the problem. The problem was that everything around it lived in people's heads and shell history.
What we wanted instead
We wanted the same things you get with a mature managed database, but for self-hosted ClickHouse® that you own:
A single place to run queries, with autocomplete that understands your schema, history you can search, and results you can export without copying from a terminal.
Monitoring that shows cluster health at a glance, and lets you click from a spike on a graph to the exact query that caused it, instead of grepping logs.
Backups you can configure, run, and restore through a UI, so the process is not a script only one person can read.
Access control you can see. A screen that answers "who can drop this table" without you reading grant statements line by line.
None of these are exotic. They are the basics of operating a database as a team. They just did not exist for ClickHouse® in one open-source tool, so we built them.
Open source first
CHOps is open source, and that was a deliberate choice rather than a marketing one. Teams running their own ClickHouse® clusters tend to be the kind of teams who want to read the code, run it on their own infrastructure, and not send their query metadata to a third party. CHOps covers the core admin work under the AGPL: the SQL editor, monitoring, dashboards, email alerting, backups to S3, GCS and Azure, and visual RBAC. It is the full software, not a teaser for a paid version.
You install it next to your cluster, point it at your nodes, and it talks to ClickHouse® over the standard HTTP interface. There are no agents to install on your database servers. If you can reach the cluster, CHOps can manage it.
Who it is for
If you are a solo engineer running a single ClickHouse® node for analytics, CHOps will save you from living in a terminal. If you are a platform team handing ClickHouse® to a dozen analysts, it gives those analysts a safe, visual way to work without root on the box. And if you are the person who currently owns all the tribal knowledge, it gives you somewhere to put it.
CHOps is in beta, and we are building it in the open with feedback from teams running ClickHouse® at real scale. The rest of the articles on this blog go feature by feature: how the SQL editor works, how monitoring and alerting fit together, and how backups and access control keep your cluster safe. If any of the problems above sound familiar, those are the ones we set out to solve.
