incubation-engineering VS clickhouse-operator

However if you really want to optimize data currently residing in Postgres for analytical workloads, as the original comment suggests - consider moving to a dedicated OLAP DB like ClickHouse.

See results from Gitlab benchmarking ClickHouse vs TimescaleDB: https://gitlab.com/gitlab-org/incubation-engineering/apm/apm...

Key findings:

ansible: stage: configure image: alpine rules: - if: $ANSIBLE_SETUP_VM != "" && $ANSIBLE_SETUP_HOST != "" variables: ANSIBLE_HOST_KEY_CHECKING: "False" script: - apk add curl bash openssh python3 py3-pip - pip3 install ansible paramiko - ansible-galaxy collection install -r ansible/requirements.yml - curl --silent "https://gitlab.com/gitlab-org/incubation-engineering/mobile-devops/download-secure-files/-/raw/main/installer" | bash - mkdir /root/.ssh && cp .secure_files/ansible.priv /root/.ssh/id_rsa && chmod 600 /root/.ssh/id_rsa - ansible-playbook ansible/main.yml -i ansible/inventory --extra-vars vyos_host=$ANSIBLE_SETUP_VM --limit $ANSIBLE_SETUP_HOST,$ANSIBLE_SETUP_VM ```

Interesting to match with the observations from the practice of using ClickHouse[1][2] for time series:

1. Reordering to SOA helps a lot - this is the whole point of column-oriented databases.

2. Specialized codecs like Gorilla[3], DoubleDelta[4], and FPC[5] lose to simply using ZSTD[6] compression in most cases, both in compression ratio and in performance.

3. Specialized time-series DBMS like InfluxDB or TimescaleDB lose to general-purpose relational OLAP DBMS like ClickHouse [7][8][9].

[1] https://clickhouse.com/blog/optimize-clickhouse-codecs-compr...

[2] https://github.com/ClickHouse/ClickHouse

[3] https://clickhouse.com/docs/en/sql-reference/statements/crea...

[4] https://clickhouse.com/docs/en/sql-reference/statements/crea...

[5] https://clickhouse.com/docs/en/sql-reference/statements/crea...

[6] https://github.com/facebook/zstd/

[7] https://arxiv.org/pdf/2204.09795.pdf "SciTS: A Benchmark for Time-Series Databases in Scientific Experiments and Industrial Internet of Things" (2022)

[8] https://gitlab.com/gitlab-org/incubation-engineering/apm/apm... https://gitlab.com/gitlab-org/incubation-engineering/apm/apm...

[9] https://www.sciencedirect.com/science/article/pii/S187705091...

Documentation of rules is now available: https://gitlab.com/gitlab-org/incubation-engineering/ai-assist/dokter/-/blob/main/docs/overview.md

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.