ClickHouse and object storage in GitGuardian self-hosted

Issued on July 29, 2026

Starting with the 2026.8 self-hosted release, GitGuardian ships ClickHouse, an open-source column-oriented database, as a new component of the self-hosted deployment. ClickHouse powers features that require fast analytics over large volumes of data, starting with machine and endpoint secret occurrence analytics, and progressively more datasets in the dashboard. Starting with release 2027.1.0, ClickHouse and its object storage backend become mandatory for all self-hosted deployments.

PostgreSQL remains the primary datastore for the rest of the application. ClickHouse is only involved for the specific features that need it.

Why ClickHouse

Endpoint scanning gives you a strong assessment of the level of underlying vulnerabilities on the machines you own, and it generates a huge amount of data. To synthesize that data and present a meaningful overview of the findings, GitGuardian needs a column-oriented database.

Upcoming features of the GitGuardian suite will also need either ClickHouse or object storage, such as in-app analytics, which currently relies on daily runs on dedicated PostgreSQL tables.

What's changing

• A new in-cluster component: ClickHouse runs as a dedicated stateful workload inside your Kubernetes cluster, deployed as a single node by default. Unlike PostgreSQL or Redis, there is no "bring your own external ClickHouse" option at this time.
• Object storage is required: ClickHouse relies on external object storage for durable data storage. S3-compatible storage (AWS S3, MinIO, on-prem S3 gateways...), Azure Blob Storage, and Google Cloud Storage are supported.
• Two local persistent volumes: ClickHouse also needs two SSD-backed persistent volumes, one for metadata and one for a filesystem cache in front of object storage. HDD-class storage and network filesystems (NFS, EFS, Azure Files) are not supported.
• Automated backups: a backup sidecar runs alongside ClickHouse and takes scheduled full and incremental backups to your object storage. There is no separate cron job to configure.

Who's affected

All self-hosted customers. ClickHouse first powers endpoint findings analytics, and more features will rely on it over time. Starting with release 2027.1.0, ClickHouse becomes a mandatory component of every self-hosted deployment.

How to prepare

1. Provision an S3-compatible bucket: confirm your organization can provide object storage reachable from your cluster. Air-gapped or fully on-prem environments can use MinIO or an on-prem S3 gateway.
2. Plan authentication to the bucket: workload identity (IRSA on AWS, Microsoft Entra Workload ID on Azure) is preferred; static credentials are passed through a Kubernetes secret, never inline in Helm values.
3. Check your StorageClass: make sure an SSD or NVMe-backed StorageClass (for example gp3 on AWS, Premium_LRS on Azure, pd-ssd on GCP) is available for the metadata and cache volumes.
4. Plan node capacity: as a starting point, budget 4 cores and 16 GiB of RAM for ~100 active endpoints, up to 8+ cores and 32 GiB+ for ~10,000. Schedule ClickHouse on a dedicated (not shared with other workloads), stable, on-demand node rather than spot or preemptible instances.
5. Pick a backup destination: backups are written to object storage you configure. We recommend a separate bucket from ClickHouse's data, though a separate path prefix in the same bucket also works.

Timeline

• 2026.8: ClickHouse ships with the self-hosted release, required for the features backed by it (starting with endpoint findings analytics). Full deployment, sizing, and backup documentation will be published in the self-hosting documentation alongside the release.
• 2027.1.0: ClickHouse and its object storage backend become mandatory for all self-hosted deployments.

Questions

Reach out to your Customer Success Manager or email us at support@gitguardian.com.