Iceberg won the table format war, then left the maintenance layer to you

Take the streaming example the guide itself uses and price it. A Flink job committing every 60 seconds across 100 active partitions writes 144,000 files a day at 1 to 5 MB each, against a read target of 128 to 512 MB ^[5]. Split the difference on both ranges and that is roughly 85 times more files than the same bytes require ^[1]. Then price the line everyone quotes: 144,000 GET requests at $0.0004 per thousand works out to about six cents to touch one day's output once ^[2]. Compaction does not justify itself on request charges. It justifies itself on the Parquet footer parse and the task-scheduling slot behind every file, which is engine compute charged to whoever runs the query rather than to the writer that produced the layout ^[6].

The snapshot arithmetic is sharper. Five-minute commits produce about 288 snapshots a day ^[9], and planning time degrades measurably past roughly 1,000 to 2,000 retained snapshots ^[10]. That threshold arrives in three and a half to seven days ^[3]. The retention window the same guide recommends for most analytics, three to seven days ^[11], therefore parks a streaming table right on the edge of the problem. Financial and healthcare retention of 30 to 90 days puts the same table at 8,640 to 25,920 snapshots, four to twenty-six times over the line ^[4]. The proposed remedy is more aggressive manifest rewriting ^[11], which converts a compliance rule into a permanent background job.

What Netflix's four services describe is the shape of the missing component, not its size ^[3]. Compaction strategy selection, catalog management, garbage collection, cross-service observability: none of those is "call rewrite_data_files on a schedule". The primitives were never the hard part, since Iceberg hands them over and withholds only the decision about when, how, and in what order to use them ^[2]. A nightly maintenance DAG covers the easiest quarter of that work, and it has no way to know that deferral is not linear. A high-throughput table with sub-minute commits can reach a degraded state within hours of going live ^[7], and late compaction conflicts with active writers and runs for hours where it would have run for seconds ^[8].

One caution about every number above. They come from a single guide whose stated conclusion is that you do not need to replicate what Netflix built ^[15], and thresholds are exactly the parameter a management vendor benefits from setting low. The mechanics are checkable against your own tables in an afternoon: count files per partition, count retained snapshots, time an EXPLAIN. The claim that needs no verification is that Iceberg expires nothing on its own ^[12]. Someone writes that schedule, or someone sells it to you.