[Blog](/blog/.md)

<!-- -->

/

<!-- -->

[Build with Tigris](/blog/tags/build-with-tigris/.md)

# The Most Expensive ClickHouse Query Is the Restore

David Myriel · July 16, 2026 ·

<!-- -->

4 min read

[![David Myriel](https://github.com/davidmyriel.png)](https://github.com/davidmyriel)

[David Myriel](https://github.com/davidmyriel)

Machine Learning Engineer

![The Most Expensive ClickHouse Query Is the Restore](/blog/assets/images/hero-img-c0b2925e9b6b1183f042eebc71bc64d4.webp)

If you self-host ClickHouse, you probably run it on Hetzner, OVH, or your own hardware. That's the whole appeal: ClickHouse is fast on cheap metal, and hyperscaler compute prices are hard to justify when your queries scan terabytes for fun.

But every guide to running ClickHouse in production assumes there's an S3 bucket nearby. Backups go to object storage. Partitions older than 30 days get tiered off to object storage. If you're not on AWS, there is no bucket nearby, so most teams point everything at S3 anyway and eat the bandwidth charges. AWS bills $0.09/GB to read your own data back.

## What that actually costs[​](#what-that-actually-costs "Direct link to What that actually costs")

Old data doesn't stay untouched. Someone digs through it during an incident, an auditor asks for it, or a backfill re-reads it. If an incident has you scanning 50 TB of old partitions, that's around $4,500 in bandwidth before you've learned anything. A full restore of a 500 TB backup costs about $45,000 at list price.

The worse problem is the one that doesn't show up on any bill: because restores cost real money, nobody tests their backups. You find out whether they work during the outage. That's the worst possible moment to learn something new about your infrastructure.

## The fix is an endpoint URL[​](#the-fix-is-an-endpoint-url "Direct link to The fix is an endpoint URL")

[Tigris](https://www.tigrisdata.com) speaks S3 and [doesn't charge egress](https://www.tigrisdata.com/pricing/). Nothing about your setup has to change, because these are the same stock ClickHouse features you'd use with any bucket. Backups are the five-minute version:

```
BACKUP TABLE logs

TO S3(

  'https://t3.storage.dev/ch-cold/backups/logs-2026-07-16',

  'tid_your_access_key',

  'tsec_your_secret_key'

);
```

That endpoint is the entire integration. Incremental backups and restore rehearsals work the same way, and our [ClickHouse guide](https://www.tigrisdata.com/docs/guides/clickhouse/) walks through both. If you have retention-heavy tables, add a tiered storage policy too. Recent partitions stay on NVMe, and everything older moves to Tigris on its own:

```
TTL timestamp + INTERVAL 30 DAY TO VOLUME 'cold'

SETTINGS storage_policy = 'tiered'
```

Your queries don't change. A dashboard query that filters to the last few days gets pruned down to the hot partitions and never leaves local disk. Queries that reach further back read from Tigris at object storage speed, and a cache disk soaks up repeat reads of the same old partitions. The full disk and policy config is in the [ClickHouse guide](https://www.tigrisdata.com/docs/guides/clickhouse/).

## To be clear about what this is not[​](#to-be-clear-about-what-this-is-not "Direct link to To be clear about what this is not")

Your hot data stays on NVMe. Local disk answers in microseconds and object storage answers in milliseconds, and that difference is most of why ClickHouse feels fast. Tigris is for your cold tier and your backups, not your primary storage.

One more thing: don't try zero-copy replication over S3 in open-source ClickHouse, tempting as it looks. The design shares one copy of the data between replicas, but each replica keeps its own local metadata about which blobs it uses, with reference counts coordinated through Keeper. That bookkeeping can race when one replica runs a merge while another runs a mutation. A replica can delete blobs its siblings still need, or it can strand orphaned blobs in your bucket forever. That's why the feature has been [disabled by default since 22.8](https://clickhouse.com/docs/operations/storing-data) and marked not production-ready. The clearest signal is what ClickHouse did about it. Rather than fix the bookkeeping, they built a new engine with shared metadata, called SharedMergeTree, and kept it in their cloud. Use Tigris for your backups and cold tier, and don't ask replicas to share a disk.

## What changes when reads are free[​](#what-changes-when-reads-are-free "Direct link to What changes when reads are free")

A lot changes. You can restore a backup just to prove it works, and you can do it monthly, because it costs nothing. Backfills and audits stop being budget conversations. The restore, the number that scared you most, drops to zero.

Your data was never the expensive part. Getting it back was. Fix that, and it's just storage. The [ClickHouse guide](https://www.tigrisdata.com/docs/guides/clickhouse/) has everything you need to set it up, from the backup command to the full tiering config.

Point your ClickHouse cold tier at Tigris

Keep your stock ClickHouse setup, pay no egress fees, and test restores as often as you like. Your first 5 GB are free.

[Get started](https://console.storage.dev)

**Tags:**

* [Build with Tigris](/blog/tags/build-with-tigris/.md)
* [Object Storage](/blog/tags/object-storage/.md)