dbdb.io VS clickhouse-operator

Have a look at https://dbdb.io/ for potential inspiration

Enter dbdb.io, the Database of Databases created and maintained by Carnegie Mellon Database Group. The catalog has entries of 841 databases (at the time of writing this article). It is fascinating to see the number of databases that have existed, the history about them and their technical details.

We automatically source the full list of open-source databases from https://dbdb.io/ and calculate daily updated metrics based on Github data. Check the full list of open-source databases on our website https://runacap.com/data/db-index/. All of them was included in analysis.

In dbdb.io there is no mentions of any github repos (https://dbdb.io/db/sqlite).

but this pricing looks excessive.

A single node instance with a fast disk is more than sufficient for most needs: https://hub.docker.com/r/clickhouse/clickhouse-server

If you need a cluster, https://github.com/Altinity/clickhouse-operator makes things easy

Altinity is doing a good job of this with Clickhouse. They offer some decent open source guides for self hosting[0] and offer a hosted option. The hosted option is as self serve as I'd like (you have to get "approved").

0 - https://github.com/Altinity/clickhouse-operator and

Where is the clickhouse data stored, in the Docker container?

For reference, here's what I'm using: https://github.com/Altinity/clickhouse-operator/blob/master/...

ClickHouse works great on Kubernetes. Check out the ClickHouse Operator for Kubernetes. [0] We just added a UI to it, blog article out shortly.

[0] https://github.com/Altinity/clickhouse-operator

Disclaimer: I work at Altinity.

Don't use helm. The ClickHouse Kubernetes Operator is the way to go. Here's the project: https://github.com/Altinity/clickhouse-operator

This is generally true for most databases these days. Use an operator if it's available. Helm can't handle the dynamic management required to run databases properly.