What the Service Takes Off Your Hands, and What It Takes Away
Managed Iceberg, held against the seventeen chapters before it: which maintenance jobs each of five services runs for you, which of the book's decisions each one takes away, where the catalog is the lock-in and the format is not, and an operating-model matrix for deciding when to accept the trade. Documentation-verified, dated, and labelled as such throughout.
Chapter 10 found that a tag on a table doubles its storage through every compaction, and set a retention policy with tags on the quarter closes. Amazon S3 Tables, read against that policy:
Snapshot management is disabled when you configure a branch or tag-based retention policy, or configure a retention policy on the
metadata.jsonfile that is longer than the values configured through thePutTableMaintenanceConfigurationAPI. In these cases S3 will not expire or remove snapshots and you will need to manually delete snapshots or remove the properties from your Iceberg table to avoid storage charges.
That is the shape of every trade in this chapter. A managed service runs a maintenance job for you, and in exchange it takes a decision away — and the decision it takes is one this book measured. The service’s snapshot management will not run on a table that carries chapter 10’s tags. The platform chooses: the service’s expiry, or its own retention classes. It does not get both.
This is the one chapter of the book that could not be run. The lab has no managed service in it, and a chapter that ran one vendor’s free tier would have measured that tier. Every claim below is taken from the vendor’s own documentation as it stood in September 2026, quoted where the wording matters, and marked with the chapter it bears on. Book 5 is the run-verified field guide for one of the five; this chapter is the comparison, and it is judgment, labelled.
What “managed” means, in the book’s terms
The platform now has an ownership list: storage and requests (chapter 2), the catalog (3), engine certification (5), table design (6 and 7), and maintenance (8–11). The health pack (13), runbooks (14), authorisation (15) and replica (16) cover operating it. A managed service takes on some of that work, with its own configuration choices and limits. For each item, the comparison asks whether the service runs it, how much control remains, which operations it refuses, and whether the table can leave.
Five services, against the chapters
Amazon S3 Tables. Storage and catalog in one: a table bucket, an Iceberg REST endpoint at https://s3tables.<region>.amazonaws.com/iceberg, and three maintenance jobs. The jobs are compaction, snapshot management and unreferenced-file removal — each with a small set of parameters set through the service’s API rather than table properties. Compaction targets 512 MB with a 64 MB minimum and supports binpack, sort and z-order. The documentation notes what chapter 8 measured: “user and compaction transactions can conflict causing transactions to fail. If conflicts occur, compaction jobs will retry on failure. It is recommended that your pipelines also use retry logic.” Snapshot management keeps a minimum count and a maximum age, one snapshot and 120 hours by default. It “does not support retention values you configure as Iceberg table properties … including branch or tag-based retention”. Set those and it switches itself off. Unreferenced-file removal runs at the bucket level with a three-day default and a one-day minimum — which is chapter 14’s guard in a different place. Priced by storage, requests, an object-monitoring fee per object, and the objects and bytes compaction processes.
Snowflake. Snowflake-managed Iceberg tables, with maintenance the documentation describes as automatic and not disableable. “Snowflake handles all lifecycle maintenance, such as compaction, for the table,” and manifest compaction “is enabled automatically and you can’t disable it.” External engines reach the tables through the Horizon catalog’s Iceberg REST endpoint, with Apache Polaris integrated into it. Reads are generally available. Writes from external engines are documented as available for v2 and v3 tables through the same endpoint, with credential vending on request. The external-writer restrictions are what determine whether the bookshop’s jobs can use that endpoint. No CREATE TABLE AS SELECT. No equality deletes. No creating tags and branches, no rollbacks, no upgrading v2 to v3, and no writes to converted externally-managed tables. Read that against chapter 10 (tags and branches), chapter 11 (equality deletes are what a Flink upsert produces), and chapter 14 (rollback is the recovery). Billing for the external-engine path is documented as starting in the second half of 2026.
Databricks. Unity Catalog managed Iceberg tables, where “Unity Catalog manages all read, write, storage, and optimization responsibilities.” The Iceberg REST catalog gives external clients “read, write, and create access … to managed Apache Iceberg tables and read-only access to Delta Lake tables with Apache Iceberg reads enabled”. The second is the older UniForm path. Predictive optimization “automatically optimizes data layout and compute using AI, without manual maintenance operations”. Automatic liquid clustering “selects and updates clustering keys as query patterns change” — which is chapters 6 and 7 done by the service. Credential vending “provides temporary, scoped credentials that inherit the privileges of the requesting Databricks principal”, which is chapter 15’s mechanism with the identity attached. Iceberg v3, with deletion vectors, row lineage and the variant type, is documented as generally available. The limits the documentation states: external writes to managed Iceberg tables in private preview at the time of reading, no shallow clones, and no path-based access.
Google BigQuery. The Lakehouse Iceberg REST catalog, formerly BigLake metastore, supports “read and write operations” from Spark, Flink, Trino and Terraform. Credential vending is described as “a storage access delegation mechanism that lets Lakehouse runtime catalog administrators control permissions directly on Lakehouse runtime catalog resources”. Two limits bear on this book directly. “You can’t create or modify tables in the Apache Iceberg REST catalog endpoint using BigQuery data definition language (DDL) or data manipulation language (DML) statements”, which splits the platform’s tables by which engine may write them. And a one-megabyte limit on the metadata file — which is chapter 9’s 558 KB table with a hard ceiling two hundred snapshots away. Parquet only, no row or column security, v2 generally available and v3 with deletion vectors in preview. Automatic optimisation is documented as generally available for tables in the BigQuery catalog and in preview for the REST catalog’s.
Microsoft OneLake. Not a managed Iceberg service but a virtualisation. “Delta Lake tables now include virtual Iceberg metadata, allowing compatibility with Iceberg readers,” generated by the service. Iceberg tables written or shortcut into OneLake get virtual Delta metadata the other way. The Table APIs, in preview, expose an Iceberg REST catalog. The conversion limits matter directly to a streaming workload. Iceberg v2 only, with v3 “coming”. “Source tables must have fewer than 5,000 transactions or commits for the table format conversion to take place” — which chapter 11’s five-second writer reaches in seven hours. Conversion latency of “between 5 seconds and 2 minutes”, with a warning that updates more frequent than once per two minutes produce “an inconsistent view”. The bucket, truncate and void partition transforms unsupported — which removes chapter 7’s redesign A. And, stated plainly: “the metadata files of an Iceberg table refer to each other using absolute path references. If you copy or move an Iceberg table’s folder contents to another location without rewriting the Iceberg metadata files, the table becomes unreadable”. That is chapter 16’s finding in a vendor’s words.
The matrix
Each cell is the service’s documentation read against the chapter that measured the item. “Service” means the service runs it and the platform configures at most a parameter; “yours” means the platform still owns it; “refused” means the service’s version will not do it.
| Item | Chapter | S3 Tables | Snowflake | Databricks | BigQuery | OneLake |
|---|---|---|---|---|---|---|
| store and request bill | 2 | service, priced per object and request | service | service | service | service |
| catalog | 3 | service, REST | service, REST (Polaris inside) | service, REST | service, REST | service, REST (preview) |
| compaction | 8 | service; binpack, sort, z-order; conflicts retried | service, not disableable | service (predictive optimisation) | service (GA in one catalog, preview in the other) | not applicable: Delta underneath |
| manifest and metadata | 9 | service | service, not disableable | service | metadata file capped at 1 MB | regenerated by conversion |
| retention with tags and branches | 10 | refused: tags disable snapshot management | refused for external writers | yours | yours | not applicable |
| streaming writers, equality deletes | 11 | yours | refused: no equality deletes from external engines | yours | yours | refused: 5,000-commit limit, 2-minute conversion |
| rollback | 14 | yours | refused for external writers | yours | yours | not applicable |
| credential vending | 15 | yes | yes | yes, with the principal’s identity | yes | not documented |
| bucket transforms | 7 | yours | yours | yours | yours | refused |
| format v3 | appendix | yours | v2 and v3 | v3 GA | v3 preview | v2 only |
| the table can leave | 16 | files are yours; catalog is the service’s | files are yours after export; catalog is the service’s | files are yours; catalog is the service’s | files are yours; catalog is the service’s | files are Delta; the Iceberg is virtual |
Where the lock-in is, and where it is not
Every row of the last line says the same thing: the files are portable and the catalog is not. The format is open, and chapter 16 showed that a table is its metadata files plus a pointer. The pointer lives in the service. So do the maintenance schedule, the grants, and the audit log chapter 15 wanted. Leaving is chapter 16’s recovery run against the service’s storage — and it recovers the tables. It does not recover the retention classes, the compaction policy, the health pack’s history or the principals, because those were never in the format.
The ownership list makes the trade concrete. The service takes the jobs of chapters 8, 9 and sometimes 10 and 13 off the platform’s hands. It takes away the parts of chapters 7, 10, 11 and 14 that its version refuses. The chapters it refuses are the ones this book spent the most pages measuring — which is not a coincidence. They are the ones where the right answer depends on the workload, and a service has to pick one answer for everyone.
When to accept it
A restriction matters when it blocks something your platform needs. The matrix becomes useful when you mark those overlaps, rather than treating every supported feature as an equal benefit.
Accept the service when its refusals are things the platform does not do. A fleet of batch tables with no tags, no streaming writers, no bucketed keys and no rollbacks in its runbooks loses nothing to S3 Tables. It gains three maintenance jobs and a catalog. The bookshop is not that fleet: chapter 10 tagged the quarter closes, chapter 11 streams the events, chapter 7 bucketed the orders, chapter 14 rolled back twice.
Keep the platform when the workload is the point. Chapters 6 and 7 found that layout decisions are workload-specific and that the folklore answer lost twice. Chapter 8 found that the compaction strategy the documentation recommends did nothing on small partitions. A service’s “automatic” is a policy chosen for the median table, and a platform whose tables are not median pays for that in the chapters it can no longer run.
Read the refusals list before the feature list, because an unsupported operation can rule out the service even when the rest fits. The S3 Tables considerations page and Snowflake’s unsupported-operations list expose those constraints. Chapter 5’s rule was that compatibility is a test result; here — where the test cannot be run — the refusals list is the nearest thing to one.
Plan the exit before the entry. Chapter 16’s game day against the service’s storage, run once, tells the platform what leaving costs. If the answer is “the tables, and none of the policies”, the policies had better be in version control somewhere the service is not.
What was not run
This chapter, entirely. Every claim is documentation, dated September 2026, quoted where it decides something and paraphrased where it does not. Prices are described and not computed. Book 5 runs one of these services end to end and is where the measured version of this comparison lives for that service. The other four remain judgment, and this chapter says so at the top and here.
Exercises
1. Fill the matrix for your platform. Take the eleven rows above and, for each, write what your platform does today and which chapter’s artifact holds the decision. Then mark the rows a candidate service would refuse.
Show answer
The rows the service refuses that your platform uses are the cost of moving — and they are always the workload-specific ones. If the marked rows are empty, the service is a good trade and the exit plan is the only thing left to write. If they include tags, streaming or rollback, the service is asking the platform to give up the chapters it needed most.
2. Read one refusals page. Pick the service closest to your platform and find its equivalent of the S3 Tables considerations page. List every “not supported” and “disabled when” against the chapter it bears on.
Show answer
The list is longer than the feature page and shorter than this book, and every item on it maps to a chapter, which is the test of whether the book covered the right ground. An item that maps to no chapter is either a feature the book missed or a limitation nobody measured, and either is worth an edition note.
Final thoughts
A managed service is the book’s maintenance chapters run by someone else, on their schedule, with their defaults. And a page in their documentation listing the chapters they will not run. The files stay open and the decisions do not — and the decisions are where the seventeen chapters before this one spent their measurements. The bookshop keeps its platform, reviews the matrix yearly, and keeps its exit rehearsed, because the one thing every row agrees on is that the way out is chapter 16.
The last chapter puts a price on every line the book measured and names who owns it.
Next: The Bill Is a Table Too
Comments