Zero opsmaintenance.

Keep your Iceberg tables healthy with Starburst. Automatic compaction, snapshot expiration, and orphan file removal, with full observability across your lakehouse estate. No clusters to size, no cron jobs to babysit.
The LakeOps dashboard: summary tiles for registered catalogs, managed tables, healthy tables, and files compacted, above a compaction efficiency panel showing a 62% file reduction and its effect on query file scans, and a storage savings breakdown attributing 2.4 TB saved to snapshot expiry, orphan file removal, and deleted files. Callout labels read 'Keep Iceberg fast', 'Scale table health', and 'Control storage costs'.
Files compacted, tracked automatically over timeHealthy vs. at-risk tables, at a glanceStorage reclaimed from expired snapshots & orphan filesQuery file-scan impact, before vs. after compaction

What zero ops looks like

Every table, watched and kept healthy on its own

Every managed table gets this view automatically: how much it's shrunk, what ran, and what's next. Nobody configured a job to get here.

Maintenance across tables (shown right) written by Apache Spark, Apache Flink, Trino, and Starburst.
Two stacked LakeOps panels. "File compaction" plots daily files compacted as bars against daily delete files as a line over the last seven days; "Snapshot history" plots total snapshots against expired snapshots per day over the same period. Callout labels read "Continuous, threshold-based compaction" and "Snapshot expiration with configurable retention policies".

A table's life, two ways

Ten tables is a cron job. A thousand is a platform.

The same table, maintained by hand versus maintained by LakeOps. One gets worse until someone notices; the other doesn't.

Manual

A table maintained by hand

  • Small files accumulate, unnoticed. Every streaming commit adds files. Nobody's watching for it.
  • Query times quietly get worse. Scans slow down before anyone connects it back to file count.
  • Someone schedules an OPTIMIZE job. A cron job or Airflow DAG is written, sized for this one table.
  • Repeat, per table, forever. Multiply by every table in the lakehouse. Ten is manageable; a thousand is not.
Zero ops

A table maintained by LakeOps

  • LakeOps watches table state. Every table is asked continuously: is there work to do?
  • Compaction runs the moment it's needed. Not on a clock — only when file count or delete ratio crosses a threshold.
  • Snapshots and orphan files clean up automatically. Retention policy applies itself; storage doesn't quietly grow.
  • Stays this way, at any scale. The same platform handles ten tables or ten thousand, without more headcount.

The four operations

Native support for the Iceberg spec, not a workaround around it

Compaction, snapshot expiration, manifest rewriting, and orphan file removal, handled the way Iceberg intends, automatically.

Data compaction

Merges small files into fewer, larger, sorted ones so scans cover more data with less overhead.

Snapshot expiration

Expires old snapshots on your retention window, freeing files no longer needed for time travel.

Manifest rewriting

Consolidates small manifests so query planning opens fewer objects, not more.

Orphan file removal

Reclaims storage from files left behind by expired snapshots or failed operations.

Who this runs for

What teams keep healthy with Icehouse LakeOps

01

Query performance recovery

Bring scan times back down after small files and delete files pile up from streaming ingestion.

02

Storage cost control

Reclaim storage from orphan files and expired snapshots that are quietly billed every month.

03

Compliance-safe retention

Expire snapshots on your own retention policy instead of keeping every version indefinitely.

04

Multi-engine lakehouses

Keep tables healthy no matter which engine — Spark, Flink, Trino, or Starburst — wrote them.

05

Scaling past a thousand tables

Move from a per-table cron job to a platform that watches every table's state on its own.

06

AI & ML feature freshness

Keep feature tables compacted and current so pipelines and agents aren't scanning stale files.

Further reading

More on Icehouse LakeOps from the Starburst blog

Data Maintenance With Icehouse LakeOps

How LakeOps maps each way Iceberg degrades to a specific, automatic fix.

Read the post

How Table Maintenance Affects Iceberg Snapshots

What happens to metadata when you compact, expire, and remove orphan files.

Read the post

Iceberg Data Maintenance with Starburst

Why Iceberg's flexibility for fast writes comes with an ongoing maintenance need.

Read the post

Visualizing Iceberg Snapshot Linear History

A working, visual deep dive into how Iceberg snapshots relate to one another.

Read the post

Iceberg Snapshots Affect Storage, Not Performance

Why a long tail of snapshots costs storage, not query speed, until you expire them.

Read the post

Best Practices for Optimizing Apache Iceberg Performance

Scheduled compaction, snapshot expiration, and orphan file removal, kept query-ready by default.

Read the post

Starburst unveils Icehouse LakeOps and Icehouse Ingest

The announcement introducing Managed Icehouse's two core capabilities.

Read the post

Go deeper on Icehouse

Icehouse Overview

The full Icehouse architecture: Starburst, Iceberg, and metastore optionality.

Explore the Icehouse Overview

Icehouse Ingest

Stream Kafka topics and land S3 files into query-ready Iceberg tables.

Explore Icehouse Ingest

Stop scheduling maintenance. Start ignoring it.

Free on Starburst Galaxy. Point LakeOps at a catalog, and watch your tables get healthier on their own.