tsbs VS clickhouse-operator

1. correctness: from small units tests to relatively complex integrations tests. they typically populate a test database and query it via various interfaces, such as REST or the Postgres protocol. we use Azure Pipelines to execute them - testing in MacoOS, Linux (both Intel and ARM) and Windows.

2. performance: we tend to use the TSBS project for most of our performance testing and profiling. fun fact: we actually had to patch it as the vanilla TSBS was a bottleneck in some tests. Sadly, the PR with the improvements is still not merged: https://github.com/timescale/tsbs/pull/186

As usual, we use the industry standard Time Series Benchmark Suite (TSBS) as the benchmark tool. Unfortunately, TSBS upstream does not support MongoDB time series collections.

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.