3. GCP Pattern 1 — BigQuery-Managed Iceberg
Data files in the customer's GCS bucket; catalog and engine are BigQuery. The pattern that gives up the least warehouse functionality — though less governance than it first appears.
Google's current name is Apache Iceberg managed tables (formerly "BigLake tables for Apache Iceberg in BigQuery", and before that "BigQuery tables for Apache Iceberg"). Tables in the Lakehouse runtime catalog (Module 04) are also called managed Iceberg tables in some Google docs — always say which catalog owns the table. Claims below were checked against the Iceberg managed tables documentation and the Lakehouse feature comparison.
The shape of the pattern
The three layers from Module 02, with the catalog sitting inside BigQuery. Modules 04 and 05 reuse this exact frame, so the differences between the patterns are the parts that move.
The catalog being inside BigQuery is the pattern. It buys full DML, column-level governance, and automatic maintenance — and it is why the other engines get a dotted line instead of a solid one.
Component placement
Storage in customer-owned GCS. Table format is Iceberg. Catalog is BigQuery itself. Primary engine is BigQuery.
What BigQuery manages
Commits, snapshot lifecycle, file layout and compaction, statistics, and the write path. This is the distinguishing property of the pattern.
What you own
The bucket, its IAM and encryption, the location, and the lifecycle policy.
How it differs from a native BigQuery table
The bytes are in your bucket in an open format, and an external Iceberg reader can be pointed at them. Everything else feels like BigQuery.
How it differs from Pattern 2
BigQuery is the catalog, not a client of one. External engines can read but never write — BigQuery is the only engine that can write these tables. Google now recommends Pattern 2 over this one "for most modern, open lakehouse workloads" (checked on 2026-09-25).
Setting it up
Creating the table
CREATE TABLE ... WITH CONNECTION {name | DEFAULT} OPTIONS(file_format='PARQUET', table_format='ICEBERG', storage_uri='gs://...'), with optional CLUSTER BY (up to four columns) and PARTITION BY. Give each table an empty, unique prefix — BigQuery's garbage collection deletes files in the prefix that it does not track.
The BigQuery connection and its service account
Why a connection exists, what identity it runs as, and which bucket permissions it needs.
Loading data
DML, the Storage Write API, Pub/Sub BigQuery subscriptions, and load jobs (append-only, no schema changes) all work. The table cannot be a query-result destination and TRUNCATE is unsupported — migrate a native table with CTAS or INSERT INTO ... SELECT. Load and export jobs run on Enterprise pay-as-you-go slots rather than the free shared pool native tables use.
What you get
Full BigQuery DML
INSERT, UPDATE, DELETE, MERGE, and streaming writes. Only one mutating statement (UPDATE, DELETE, MERGE) runs per table at a time; the rest queue — design high-frequency upsert pipelines around that.
BigQuery governance, partially
IAM, policy tags, column-level security, and dynamic data masking work. Row access policies and authorized views do not (checked on 2026-09-25). A client whose governance relies on row-level security or authorized views needs a workaround here too — the same problem as Module 04, in a milder form.
Near-native query performance
The benchmark measured managed Iceberg at 1.13x native elapsed time — its best run was actually faster than native's best run.
Automatic maintenance
Adaptive file sizing, automatic clustering, garbage collection, and metadata optimization are handled by the service, removing the largest operational burden of Chapter 2. It is billed separately, per DCU-hour of background compute (checked on 2026-09-25).
What it costs
The compute premium
The same benchmark measured 2.01x native slot-ms, with the overhead concentrated almost entirely in the input stage (351,726 vs 111,191 slot-ms — 3.16x). Relational processing was unaffected.
Reading the benchmark honestly
Three repetitions, one two-table join, one file layout. Directional, not conclusive. Cost impact depends on whether the client is on-demand (bytes) or editions (slots) — the premium lands very differently.
Storage cost shape
GCS rates on customer-owned Parquet, including time-travel history, with no BigQuery storage fee and no long-term storage discount — use GCS Autoclass instead. The console reports these tables as 0 bytes, so storage cost has to be read from the bucket.
Limitations
Feature parity gaps
Checked on 2026-09-25. Supported: time travel (7 days), multi-statement transactions, time-unit partitioning (no partition evolution), BigQuery ML and AI functions, EXPORT DATA. Not supported: row access policies, authorized views, materialized views, search and vector indexes, fail-safe, table clones, snapshots, copy and extract jobs, rename, managed disaster recovery, and the BIGNUMERIC, INTERVAL, JSON, RANGE, and GEOGRAPHY types. BI Engine is not documented either way — test it.
External write access
External engines cannot write these tables at all. Needing them to is the constraint that most often pushes an engagement to Pattern 2.
How external engines read
Two routes, both read-only. EXPORT TABLE METADATA writes Iceberg v2 metadata, run manually or on a schedule (per-mutation auto-refresh is by request to Google, and every refresh is billed). Or BigQuery catalog federation: the Lakehouse REST endpoint pointed at a bq://projects/... warehouse — GA, but without credential vending, and Google itself recommends Pattern 2 instead for most workloads. Either way, rows streamed through the Storage Write API in the last 90 minutes may be missing from the exported metadata.
Everything in this section is a moving target. Re-verify against Google's documentation and date-stamp the claim before putting it in a client deliverable.
The adjacent option — BigLake external Parquet tables
Three things a client will call "our data in GCS", and what actually sits between BigQuery and the files in each:
Only the middle one is a lakehouse. The right-hand option is the one most engagements start from and the one clients most often call a lakehouse — it has open files and no table format, which is a different thing entirely.
Why it belongs in this module
It is the pattern most Aliz engagements actually start from, and clients frequently call it a lakehouse. It is not one: plain Parquet in GCS has no table format, so no transactions, no snapshots, and no schema or partition evolution.
What you give up versus managed Iceberg
Read-only from BigQuery, no clustering, Hive-style directory partitioning only, no time travel or fail-safe, no BI Engine acceleration, no search or vector indexes, and no consistency guarantee if files change mid-query.
What you keep
GoogleSQL access, authorized views, row-level security, column policy tags, dynamic masking (enforced through the Storage Read API too), BigQuery ML, materialized views over cache-enabled tables, and Sharing. Ironically this is more of the governance surface than managed Iceberg keeps — one reason this pattern persists.
Metadata caching
max_staleness of 30 minutes to 7 days (off by default), automatic refresh roughly every 30–60 minutes or manual via BQ.REFRESH_EXTERNAL_METADATA_CACHE, cache expiry after 7 days without refresh, and refresh billed as bytes (on-demand) or slots (editions) — checked on 2026-09-25. The benchmark found caching made this workload 61% slower with 38% more slot-ms — benchmark it, never assume it.
Measured overhead
1.23x native elapsed, 1.63x native slot-ms, with 2.40x the native input-stage cost.
When it is the right call
Open file ownership and avoiding a duplicate managed copy matter more than write support and physical optimization, and the ingestion pipeline can own file publication, layout, and schema quality.
When to choose Pattern 1
Decision gates
BigQuery is the only writer; column-level governance is enough (row-level security and authorized views are not available); the team wants minimal maintenance operations; open storage ownership matters; external engine access is read-only.
When to move to Pattern 2 instead
Multiple engines must write; a live Iceberg REST catalog is required; or cross-cloud Iceberg migration is a committed roadmap item.
Migration path out
Because the files are already Iceberg, the exit to another Iceberg platform is a metadata and catalog migration rather than a full export.