Set a snapshot expiration policy before old versions eat your storage bill

Every snapshot from every write is still sitting in storage. Nobody ever told it to stop.

IntermediateRead 4 minDoing: under an hour to size and apply the policy; the count doesn't finish dropping until the first scheduled run actually clears the backlog6 steps

▶ Start

What you'll have at the end

An expireSnapshots schedule with a fixed retention window and a measured drop in stored file count

Before you start

You need

An Iceberg table already taking regular writes, plus a query engine such as Spark connected to it with permission to alter its properties and run its maintenance procedures.

Not covered

Retention for a branch or tag, a separate named pointer to an older snapshot used for staged writes or long-lived audits, which expires under its own separate rule, not the plain snapshot policy this recipe sets.

Leans on

6 steps

Where to go next

A bad write on a lakehouse table, rolled back with time travel

When you need to jump straight to restoring a specific snapshot after a bad write, rather than setting the everyday retention schedule this recipe covers.

A lakehouse query keeps slowing down as manifest bloat builds up

When the same table's queries are slowing down from manifest sprawl rather than its storage bill from unexpired snapshots.

Checked 26 Aug 2026

Part of the Data Lakehouse cookbook