How to pick the Iceberg catalog before you pick the engine

Every lakehouse assessment we run this year contains the same unmade decision. The team has chosen Apache Iceberg, has chosen an engine, sometimes two, and has accepted whatever catalog came in the box. Nobody chose it. It is the one component the platform cannot run without, and the credible options, from Polaris to Unity Catalog to the managed services wrapping both, differ exactly where an exit hurts.

Your engines find tables by asking a catalog. The catalog decides who can read what, which engine committed last, and whether an outside writer is welcome. Files in your bucket are portable. The commit path through the catalog is the relationship, and whoever operates that catalog holds it. Open source code says nothing about where yours runs, per the layer-by-layer switching costs we priced before.

So choose the catalog first, deliberately, the way you would choose a database. The method takes an afternoon.

Inventory the writers, not the readers

List every system that will commit to a table, not just query one. Warehouse jobs, Spark, streaming ingestion, the odd Python script finance runs. Readers are easy; every engine speaks the Iceberg REST protocol now. Writers are where catalogs disagree, and a catalog that accepts commits from only its own vendor's engine has made your architecture decision for you.

Ask the three exit questions

For each candidate, in writing, from the vendor or the docs:

• Can an external engine commit through the REST API, or only read? Managed catalogs differ here more than their marketing does, and the v3 feature table shows how fast the details move.
• Can we export the full catalog state, namespaces, table pointers and grants, in a form another catalog can import?
• If we leave, do the tables keep working from the files alone, and what is lost? Usually the answer is grants and history. Know that before the negotiation, not during it.

Decide who operates it

Three honest options. Use the managed catalog inside the platform you already trust most, and accept that its edges are that vendor's edges. Run an open one yourselves and accept an operations bill measured in real on-call hours, sized against the platform team you actually have. Or pay a third party to host the open one, which is the middle price for the middle risk. None of these is wrong. Picking one by default is.

Write the decision down

One page: the writers list, the three answers per candidate, the operator, and the date you will revisit. The revisit date matters. Catalog capabilities changed more in the last eighteen months than warehouse SQL changed in ten years, and a choice made this September deserves rechecking next.

A caution from recent assessments: teams pick the engine first, inherit whatever catalog it favors, and discover the boundary two years later when a second engine shows up. The order is the whole method. Catalog, then engines, plural, because the plural is the point of paying for open in the first place.