Put the Iceberg catalog in code before the second team joins

The Apache Iceberg community shipped an official Terraform and OpenTofu provider this quarter, and the 0.1.0 release vote cleared in September. It is a small release. Two resources, namespaces and tables, plus read-only data sources for both.

Small is the news. Until now the catalog, the one lakehouse component we tell clients to choose before the engine, was also the one layer with no infrastructure-as-code story at all. Buckets, clusters and warehouses live in reviewed Terraform. Namespaces get created by whoever ran a notebook first. Every estate we assess has a catalog that grew this way, and nobody can say which of its four hundred tables are load-bearing.

A provider does not fix that. A boundary does. Here is the one we draw.

Manage the namespaces, all of them

Namespaces are cheap, stable, and political. Who gets a schema, what it is called, which properties it carries: those are exactly the decisions that benefit from a pull request instead of a Slack message. Import every existing namespace into state in one sitting; the provider's data sources let you read what is there before you claim it. From that day, a new namespace is a reviewed diff with a named requester attached. That single habit gives you the change log the minimum governance set assumes you already have.

Manage the tables that behave like infrastructure

Not every table belongs in code. Analyst scratch tables churn daily and would turn your plan output into noise. The tables to claim are the contract surfaces: the curated marts other teams build on, the tables external partners read, anything with a freshness promise attached. Their schemas change rarely and every change deserves a reviewer from the consuming side.

Leave the rest out, on purpose

Grants stay with the catalog or your access tooling; the provider does not manage them. Data files and snapshots belong to the engines. Compaction and retention belong to your maintenance jobs. And a 0.1.0 deserves 0.1.0 trust: keep it away from tables whose schemas evolve through engine DDL every week, because state that fights the engines is worse than no state. Run terraform plan on a schedule instead and treat unexpected drift as a finding, not a fire.

The afternoon version: import the namespaces, claim your five most-consumed tables, wire the plan into CI, and write one page saying where the boundary sits and why. When the second team arrives with their own engine and their own naming opinions, the argument happens in a pull request, with history. That is the cheapest governance meeting you will ever hold.