ClickHouse Cloud FinOps: A Board-Ready 12-Metric Scorecard to Stop Overspending

Anatomy of the invoice

ClickHouse Cloud pricing and billing: the five meters behind every invoice

ClickHouse Cloud billing is usage-based, and every metric in this paper traces back to one of the meters below. The rates are the list rates published on the ClickHouse Cloud pricing page when we checked it on 16 October 2026, for its reference configuration. They differ by cloud provider and region, and negotiated commitments change the effective rate, so treat them as a model input, not a quote.

Two properties of ClickHouse Cloud pricing drive most of the analysis that follows. First, compute is billed per minute for the capacity that is awake, not for the CPU a query uses. A service at 2% utilization costs the same per minute as one at 90%. Second, storage is billed on compressed bytes, so a schema that compresses poorly is a recurring charge, not a one-off inefficiency. The ClickHouse Cloud billing overview documents the meters in full, including how Basic services pause after a period of inactivity.

The unit conversion used throughout is simple. At the Scale rate, one unit-hour buys 2 vCPU for 3,600 seconds, or 7,200 vCPU-seconds. One vCPU-second of awake capacity therefore costs $0.2985 / 7,200 = $0.0000415. Every CPU figure in this paper converts to dollars with that factor.

Inform · metrics 1 and 2

Cost mix and allocation coverage from the ClickHouse Cloud billing API

The organisation-level view starts with the usage cost endpoint of the ClickHouse Cloud API. It returns, per UTC day and per entity (a warehouse, a service or a ClickPipe), the ClickHouse Credits (CHC) consumed on each meter. Requests cover at most 31 days, and authentication is HTTP Basic with an API key. The usage cost API reference documents the fields. One detail matters for ClickHouse Cloud FinOps arithmetic: the public and inter-region transfer fields are a breakdown of dataTransferCHC. Summing all of them double-counts transfer.

#!/usr/bin/env python3
"""
ClickHouse Cloud FinOps: pull daily usage cost from the ClickHouse Cloud billing API and derive
the organisation-level FinOps metrics (cost mix, allocation coverage, burn index, anomaly score).

Endpoint: GET https://api.clickhouse.cloud/v1/organizations/{organizationId}/usageCost
          ?from_date=YYYY-MM-DD&to_date=YYYY-MM-DD   (maximum 31 days per request)
Auth:     HTTP Basic with an API key id and secret, read from the environment, never hard-coded.
Amounts:  ClickHouse Credits (CHC), per entity (datawarehouse, service, clickpipe) per UTC day.
"""
import base64, json, os, statistics, sys, urllib.request
from collections import defaultdict
from datetime import date, timedelta

API = "https://api.clickhouse.cloud/v1/organizations/{org}/usageCost?from_date={f}&to_date={t}"

def fetch(org_id: str, start: date, end: date) -> list[dict]:
    """Return the daily per-entity cost records, splitting the range into 31-day windows."""
    token = base64.b64encode(f"{os.environ['CH_CLOUD_KEY_ID']}:{os.environ['CH_CLOUD_KEY_SECRET']}".encode()).decode()
    records, cur = [], start
    while cur <= end:
        stop = min(cur + timedelta(days=30), end)
        req = urllib.request.Request(API.format(org=org_id, f=cur, t=stop), headers={"Authorization": f"Basic {token}"})
        with urllib.request.urlopen(req, timeout=60) as r:
            records += json.load(r)["result"]["costs"]
        cur = stop + timedelta(days=1)
    return records

# These five meters are a breakdown of dataTransferCHC; counting them as well would double-count transfer
TRANSFER_DETAIL = {"publicDataTransferCHC", "interRegionTier1DataTransferCHC", "interRegionTier2DataTransferCHC",
                   "interRegionTier3DataTransferCHC", "interRegionTier4DataTransferCHC"}

def finops_metrics(records: list[dict], owners: dict[str, str], remaining_chc: float, days_left_in_term: int) -> dict:
    """owners maps serviceId -> owning team; anything unmapped counts as unallocated spend."""
    mix = defaultdict(float)                        # metric 1: ClickHouse Cloud cost mix by meter
    by_day = defaultdict(float)                     # daily total, for the anomaly score
    allocated = unallocated = 0.0                   # metric 2: ClickHouse Cloud cost allocation coverage
    for rec in records:
        for meter, chc in (rec.get("metrics") or {}).items():
            if meter not in TRANSFER_DETAIL:
                mix[meter] += chc or 0.0
        by_day[rec["date"]] += rec["totalCHC"]
        if rec.get("serviceId") in owners: allocated += rec["totalCHC"]
        else: unallocated += rec["totalCHC"]
    total = sum(by_day.values())
    days = sorted(by_day)
    # metric 12b: the latest day's spend against the trailing 14-day mean and standard deviation
    tail = [by_day[d] for d in days[-15:-1]]
    z = (by_day[days[-1]] - statistics.mean(tail)) / (statistics.pstdev(tail) or 1.0) if len(tail) >= 7 else None
    run_rate = sum(by_day[d] for d in days[-30:]) / len(days[-30:])   # trailing 30-day CHC per day
    runway = remaining_chc / run_rate if remaining_chc else None    # days the remaining commitment lasts
    return {
        "total_chc": round(total, 2),
        "cost_mix_pct": {m: round(100 * v / total, 1) for m, v in sorted(mix.items(), key=lambda kv: -kv[1]) if v},
        "allocation_coverage_pct": round(100 * allocated / total, 1) if total else None,
        "unallocated_chc": round(unallocated, 2),
        "runway_days": round(runway) if runway else None,
        # metric 12a: above 1.0 the credits run out before the term ends; well below 1.0 they expire unused
        "commit_burn_index": round(days_left_in_term / runway, 2) if runway else None,
        "latest_day_zscore": round(z, 2) if z is not None else None,
    }

if __name__ == "__main__":
    if len(sys.argv) > 1 and sys.argv[1] == "--sample":     # offline check against a saved response
        records = json.load(open(sys.argv[2]))["result"]["costs"]
    else:
        end = date.today() - timedelta(days=1)
        records = fetch(os.environ["CH_CLOUD_ORG_ID"], end - timedelta(days=89), end)
    owners = json.load(open(os.environ.get("FINOPS_OWNERS", "owners.json")))
    print(json.dumps(finops_metrics(records, owners,
                                    remaining_chc=float(os.environ.get("REMAINING_CHC", 0)),   # from the credit balance endpoint
                                    days_left_in_term=int(os.environ.get("DAYS_LEFT_IN_TERM", 0))), indent=2))

$ REMAINING_CHC=12000 DAYS_LEFT_IN_TERM=165 python3 usage_cost.py --sample sample_usage.json
{
  "total_chc": 3333.49,
  "cost_mix_pct": {"computeCHC": 81.2, "storageCHC": 14.7, "backupCHC": 2.5, "dataTransferCHC": 1.6},
  "allocation_coverage_pct": 93.1,
  "unallocated_chc": 229.48,
  "runway_days": 108,
  "commit_burn_index": 1.53,
  "latest_day_zscore": 2.58
}

Read as a steering committee would, that synthetic result says three things. Compute dominates, so the optimize metrics on compute come first. Almost 7% of spend has no owner, below the 95% coverage threshold, so someone must claim it before the next review. And at the current run rate the commitment runs out 57 days before the term ends. That is a renegotiation conversation to have now, not at renewal.

Optimize · metrics 4 and 5

Compute utilization and idle-awake time: the gap ClickHouse Cloud pricing bills for

Because compute is billed for awake capacity, the most important ClickHouse Cloud cost optimization question is how much of that capacity did useful work. Two FinOps metrics answer it. Utilization compares CPU consumed with vCPU-seconds provisioned. The idle-awake ratio counts the minutes in which the service was awake but no business query ran: only probes, monitoring or operators. The query below spreads each query’s CPU across every minute it was running, so a long query is not booked to the minute it happened to finish.

-- ClickHouse Cloud FinOps metrics 4 and 5: compute utilization and idle-awake ratio, minute by minute
-- vcpus = vCPUs provisioned across all replicas of the service
WITH per_query AS
(
    SELECT
        range(toUInt32(toStartOfMinute(query_start_time)), toUInt32(event_time) + 1, 60) AS minutes,
        ProfileEvents['OSCPUVirtualTimeMicroseconds'] / 1e6 / length(minutes)            AS cpu_per_minute,
        user NOT IN {non_business_users:Array(String)}                                    AS is_business   -- probes, operators
    FROM system.query_log
    WHERE type = 'QueryFinish'
      AND event_time BETWEEN {from:DateTime} AND {to:DateTime}
),
per_minute AS
(
    SELECT
        arrayJoin(minutes)            AS minute,
        sum(cpu_per_minute)           AS cpu_s,
        max(is_business)              AS any_business_work
    FROM per_query
    GROUP BY minute
)
SELECT
    count()                                                                   AS awake_minutes,
    countIf(any_business_work = 0)                                            AS idle_awake_minutes,
    round(100 * idle_awake_minutes / awake_minutes, 1)                        AS idle_awake_pct,
    round(sum(cpu_s), 1)                                                      AS consumed_cpu_s,
    awake_minutes * 60 * {vcpus:UInt32}                                       AS provisioned_vcpu_s,
    round(100 * consumed_cpu_s / provisioned_vcpu_s, 1)                       AS compute_utilization_pct
FROM per_minute
FORMAT Vertical;

-- business window, vcpus = 2:  awake_minutes 9, idle_awake_pct 0, consumed_cpu_s 22.3,
--                              provisioned_vcpu_s 1080, compute_utilization_pct 2.1
-- probe-only window:           awake_minutes 3, idle_awake_pct 100, compute_utilization_pct 0.1

Two findings matter. The business window used 2.1% of what a 2 vCPU unit provides, and it would still have billed every minute in full. The planned quiet minutes at the end of the run never came, because the unbounded query ran for 268 seconds and kept the service busy. The probe-only window is the purer lesson. About 50 health checks over three minutes used 0.1% of capacity, yet on a service with idling enabled, any query counts as activity. A load-balancer probe aimed at the database, rather than at the application in front of it, can keep a service awake around the clock.

Utilization below 20% for a month is our trigger to right-size: lower the autoscaling floor, reduce replicas outside business hours, or move bursty work to a separate compute group. Before acting, check memory headroom (metric 11). A service sized for one memory-hungry query will look idle on CPU and still need its memory.

Optimize · metric 7

Egress intensity: when data transfer outweighs compute in ClickHouse Cloud billing

Data transfer is a small share of most ClickHouse Cloud billing, which is exactly why it goes unwatched. It is concentrated: one consumer that ships raw rows out of the region can cost more in transfer than its queries cost in compute. Egress intensity measures that per consumer from the bytes each query returned.

-- ClickHouse Cloud FinOps metric 7: egress intensity, result bytes leaving the service per user and interface
WITH {egress_usd_per_gb:Float64} AS usd_per_gb
SELECT
    user,
    interface,
    count()                                                                   AS queries,
    formatReadableSize(sum(result_bytes))                                     AS returned,
    round(sum(result_bytes) / 1e9 * usd_per_gb, 4)                            AS egress_usd_if_public,
    round(sum(ProfileEvents['OSCPUVirtualTimeMicroseconds']) / 1e6, 2)        AS cpu_s
FROM system.query_log
WHERE type = 'QueryFinish'
  AND event_time BETWEEN {from:DateTime} AND {to:DateTime}
GROUP BY user, interface
ORDER BY sum(result_bytes) DESC;

-- --param_egress_usd_per_gb=0.1152
-- user            interface  queries  returned    egress_usd_if_public  cpu_s
-- partner_export  HTTP             5  39.97 MiB                 0.0048   0.36
-- healthcheck     HTTP           240  960.00 KiB                0.0001   0.35
-- bi_dashboard    HTTP           182  95.44 KiB                      0   0.96
-- analyst         HTTP             7  68.27 KiB                      0  20.68

The partner feed used 0.36 CPU-seconds, about $0.0000148 of compute at the Scale rate. Its 39.97 MiB of results would cost $0.0048 if they crossed the public internet: roughly 320 times the compute. The health check returned 960 KiB, which also outweighs its compute. The analyst is the mirror image, expensive to compute and almost free to ship. A single cost-per-query figure hides both patterns. The partner feed’s lever is location, through private connectivity, an in-region consumer or a scheduled export to object storage. The analyst’s lever is the sort key and the guardrail.

Result bytes are an upper bound on transfer. The meter counts bytes that actually leave the service’s network boundary, and compressed HTTP responses send fewer bytes than result_bytes records. Use this metric to rank consumers, then confirm against dataTransferCHC in the billing API.

Operate · metrics 10 to 12

Memory headroom, backups and the burn index: ClickHouse Cloud FinOps for leadership

The operate metrics answer whether the service is the right size and the commitment the right shape. Memory headroom comes first because it is the usual reason a service cannot be scaled down. A compute unit pairs 2 vCPU with 8 GiB, so a service sized for memory carries CPU it does not need, and the reverse.

-- ClickHouse Cloud FinOps metric 11: memory headroom, peak query memory against one replica's memory
SELECT
    user,
    count()                                                                   AS queries,
    formatReadableSize(quantile(0.99)(memory_usage))                          AS p99_query_memory,
    formatReadableSize(max(memory_usage))                                     AS max_query_memory,
    round(100 * max(memory_usage) / ({replica_gib:UInt32} * 1073741824), 1)   AS pct_of_replica_memory
FROM system.query_log
WHERE type = 'QueryFinish'
  AND event_time BETWEEN {from:DateTime} AND {to:DateTime}
GROUP BY user
ORDER BY max(memory_usage) DESC;

-- --param_replica_gib=8
-- user            queries  p99_query_memory  max_query_memory  pct_of_replica_memory
-- analyst               7  41.07 MiB         41.07 MiB                           0.5
-- bi_dashboard        182  5.70 MiB          5.73 MiB                            0.1
-- partner_export        5  4.35 MiB          4.36 MiB                            0.1

The heaviest query in our window used 41.07 MiB, 0.5% of an 8 GiB replica. This workload was bound by neither CPU nor memory. A review that saw that profile for a month would test a smaller floor, after checking peak concurrency and merge memory, which this per-query view does not capture.

The backup-to-data ratio is the backup CHC from the billing API divided by storage CHC. Backups are billed separately, and the default keeps one backup for one day. When the ratio rises with no change in retention policy, someone has extended retention or added backups without a cost decision. Neither is wrong; both should be visible.

The burn index compares the days left in a commitment term with the days the remaining credits will last at the trailing 30-day run rate. At 1.0 the credits and the term end together. Above 1.1 they run out early and further usage is billed outside the commitment; below 0.8 credits are likely to expire unused. The daily anomaly score is the latest day’s spend as a z-score against the trailing 14 days. Both are computed by the script above from the usage cost API, with the remaining balance taken from the organisation’s credit balance endpoint.

Scope of the evidence

How we measured, and what this ClickHouse Cloud FinOps evidence does not show

Three limits follow. ClickHouse Cloud bills awake compute, not the CPU a query uses, so our CPU-based unit costs allocate the bill rather than reproduce it. The workload compressed a business day into eight minutes, so absolute dollar figures are tiny and only the ratios carry over. And a single small service shows none of the effects of autoscaling, multiple replicas or compute groups. On ClickHouse Cloud, read system.query_log across replicas with clusterAllReplicas, and validate every threshold against your own baseline before it drives a decision.

Further reading

Related ChistaDATA research and ClickHouse sources

From ChistaDATA: how expensive queries become a very large ClickHouse Cloud bill, the query-level companion to this paper; ClickHouse performance observability, for the system tables used here; and our ClickHouse high availability architecture framework, for the replica and zone decisions that drive compute spend.

ClickHouse documentation: ClickHouse Cloud pricing, the billing overview, the usage cost API, system.query_log and query complexity restrictions.

Measurements: ChistaDATA lab, 16 October 2026, ClickHouse 26.9.17.8 on one 2 vCPU host, synthetic data and workload. Prices: ClickHouse Cloud list rates as published on 16 October 2026; your rates depend on provider, region and contract. Usage cost API output is from a synthetic response. Test every recommendation on a non-production service before applying it to production, and keep a tested backup and recovery posture.