Where self-managed ClickHouse keeps its data and for how long: object storage disks, hot, warm and cold tiers, TTL retention and rollups, compression and caching.
Separating storage and compute on self-managed ClickHouse with S3 or S3-compatible disks: storage policies, the local cache, bucket rules to avoid, and which workloads tolerate object storage latency.
Building tiered storage with volumes and TTL MOVE rules: NVMe for recent data, HDD or object storage for older data, storage policy design, and monitoring moves between tiers.
Deleting expired rows and columns automatically with TTL: aligning partitions with retention, conditional deletes, merge timeouts, and proving to auditors that data is removed on schedule.
Keeping aggregated history while discarding detail: TTL GROUP BY rollups, recompression of old parts, and when a materialized view rollup is the better design.
Reducing storage with column codecs: LZ4 versus ZSTD levels, Delta, DoubleDelta and Gorilla for time series, measuring compression per column, and the CPU cost of heavier codecs.
Configuring GCS through the s3 disk type or Azure Blob Storage disks for self-managed ClickHouse on Google Cloud or Azure: credentials, caches, storage policies and replication considerations.
Sizing and placing the local cache in front of S3, GCS or Azure disks: cache paths, maximum size, cache system tables and commands, and what happens to query latency when the cache is cold.
Why zero-copy replication on S3 is off by default and not recommended for production, what it would save, and the supported alternatives for replicated tables on object storage.
Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.