Designing the Ideal Cadence for Compaction and Snapshot Expiration

Learn how to design an effective schedule for compaction and snapshot expiration in Apache Iceberg to balance cost, performance, and data freshness.

03 Mins readAlex Merced
Designing the Ideal Cadence for Compaction and Snapshot Expiration

Cross-posted. This article’s canonical home is Alex Merced’s Lakehouse Blog.

Designing the Ideal Cadence for Compaction and Snapshot Expiration

In previous posts, we explored how compaction and snapshot expiration keep Apache Iceberg tables performant and lean. But these actions aren’t one-and-done - they need to be scheduled strategically to balance compute cost, data freshness, and operational safety.

In this post, we’ll look at how to design a cadence for compaction and snapshot expiration based on your workload patterns, data criticality, and infrastructure constraints.

Why Cadence Matters

Without a thoughtful schedule:

  • Over-optimization can waste compute and create unnecessary load
  • Under-optimization leads to performance degradation and metadata bloat
  • Poor coordination can cause clashes with ingestion or query jobs

You need a cadence that fits your data’s lifecycle and your platform’s SLAs.

Key Factors to Consider

1. Ingestion Rate and Pattern

  • Streaming data? Expect high file churn. Compact frequently (hourly or near-real-time).
  • Batch jobs? Compact after each large load or on a daily schedule.
  • Hybrid? Monitor ingestion metrics and trigger compaction based on thresholds.

2. Query Frequency and Latency Expectations

  • High query volume tables benefit from more frequent compaction to improve scan performance.
  • Low-usage tables can tolerate more infrequent optimization.

3. Storage Costs and File System Limits

  • Cloud storage costs can balloon with small files and lingering unreferenced data.
  • File system metadata limits may also be a concern at massive scale.

4. Retention and Governance Requirements

  • Snapshots may need to be retained longer for audit or rollback policies.
  • Balance expiration with compliance needs.

Suggested Cadence Models

Use CaseCompaction CadenceSnapshot Expiration
High-volume streaming pipelineHourly or event-basedDaily, keep 1-3 days
Daily batch ingestionPost-batch or nightlyWeekly, keep 7-14 days
Low-latency analyticsHourlyDaily, keep 3-5 days
Regulatory or audited dataWeekly or on-demandMonthly, retain 30-90 days

Use metadata queries (e.g., from files, manifests, snapshots) to drive dynamic policies.

Automating the Schedule

You can use orchestration tools like:

  • Airflow / Dagster / Prefect: Schedule and monitor compaction and expiration tasks
  • dbt Cloud: Use post-run hooks or scheduled jobs to optimize models backed by Iceberg
  • Flink / Spark Streaming: Trigger compaction inline or via micro-batch jobs

Tip: Tag critical jobs with priorities and isolate them from ingestion workloads where needed.

Coordinating Between Compaction and Expiration

Ideally:

  • Compact first, then expire snapshots
  • This ensures snapshots written by compaction are retained at least temporarily
  • Avoid expiring snapshots too soon after compaction to prevent data loss

Example Workflow:

  1. Run metadata scan to detect small file bloat
  2. Trigger compaction on affected partitions
  3. Delay snapshot expiration by a few hours
  4. Run snapshot expiration with a safety buffer

Monitoring and Adjusting Over Time

Cadence isn’t static - adjust based on:

  • Changing ingestion rates
  • New query patterns
  • Storage trends
  • Platform feedback (slow queries, GC delays, etc.)

Use logs, metadata tables, and query performance dashboards to guide adjustments.

Summary

An effective compaction and snapshot expiration cadence keeps your Iceberg tables fast, lean, and cost-effective. Your schedule should:

  • Match your workload patterns
  • Respect operational and governance needs
  • Be flexible and monitorable

In the next post, we’ll look at how to use Iceberg’s metadata tables to dynamically determine when optimization is needed - so you can make it event-driven instead of fixed-schedule.

Go further

Share :

Related Posts

Agent Gateway Control Matrix: What A2A and MCP Gateways Enforce Before an Agent Touches Lakehouse Data

Agent Gateway Control Matrix: What A2A and MCP Gateways Enforce Before an Agent Touches Lakehouse Data

An agent gateway decides which agents get to connect, as whom, and what comes back. On October 27, 2026, three things happened. SAP made inbound Agent2Agent (A2A) calls generally available through its...

The Iceberg Catalog Federation Map, November 2026: Which Platforms Read and Write Whose Catalog

The Iceberg Catalog Federation Map, November 2026: Which Platforms Read and Write Whose Catalog

Catalog federation lets one platform query Iceberg tables registered in another vendor's catalog. Between October 26 and November 2, 2026, Google made federation with Databricks Unity Catalog, AWS Glu...

Iceberg v4's _last_updated_time Column: "Rows Changed Since T" Without Rewriting Manifests

Iceberg v4's _last_updated_time Column: "Rows Changed Since T" Without Rewriting Manifests

Iceberg v4 is voting on a `_last_updated_time` column that records when each row last changed. Steven Wu opened the vote on October 30, 2026, and it was still open on November 3 with eight +1 votes, t...

Work with Alex