Collapsing three copies into one Iceberg table moves the conflict into an HTTP 409

An Iceberg commit does not edit the table in place. The writer lays down new Parquet and new metadata files, then asks the catalog to make its version the current one. The REST catalog is the single arbiter of which version is current ^[3], and the transaction guarantee is all-or-nothing: the whole write lands or nothing changes ^[4]. Two writers that both started from the same snapshot both ask, the catalog moves the pointer once, and the second gets HTTP 409 ConflictException ^[2].

The same write-up describes the failure this replaces. Keep the data as loose Parquet in a storage folder, let two processes write at once, and one can silently overwrite the other ^[6]. Updating a single row in a Parquet file means rewriting the whole file ^[6].

Contention rates are a property of your workload. The setup is one retail orders table, orders_iceberg, in Cloud Storage with three applications on it ^[11], and the write-up does not report table size, commit rate, how many commits collided, or whether the losing writer retried ^[13]. For a 409 rate measured here to say anything about a production pipeline, the overlap would have to match: the same table, the same window, writers that do not coordinate with each other. The run does show that all three engines can commit through the one catalog ^[1], and that the rejection comes back as a status code a client can branch on ^[2].

After a 409, the losing writer cannot resend the same commit. Its base version is no longer current, so it has to re-read the current snapshot and redo the work against that ^[3]. Time travel means the older snapshots are still queryable, because Iceberg keeps the version history ^[5].

Only the prose got the new product name. Google renamed BigLake to Lakehouse for Apache Iceberg ^[7], and the identifiers still spell biglake: the API endpoint, the gcloud subcommand, the gcp.biglake.* table properties, the blirc-* managed service account, CATALOG_TYPE_BIGLAKE, and the bl:// warehouse scheme ^[9]. Anyone searching Google's docs for "Lakehouse" and their own Terraform for the same word gets two different answers.

I like the authorization design. Access goes through Workload Identity, using the workload's own execution identity, so there is no service account .json key file to download and rotate per engine ^[10]. The catalog itself is the open Iceberg REST standard, with read and write interoperability across BigQuery, Google's managed Spark service, and OSS engines including Spark, Trino and Flink ^[8].

The billing case is simple. Three teams keeping three copies paid double or triple storage on the same terabytes and watched one copy update while the others kept the old value ^[12]. Consolidating to a single copy removes two of those three storage charges ^[14].