Google Cloud Lakehouse Runtime Catalog
The Lakehouse runtime catalog — until April 2026, BigLake metastore — is Google Cloud's fully managed, serverless implementation of the Apache Iceberg REST Catalog API, letting Spark, Flink, Hive, Trino, and BigQuery share the same Iceberg tables without duplicating files.
LicenseCommercial
DeploymentManagedServerless
PricingSubscription
Operational complexityLow
WorkloadInteractiveBatch
Use it when
- The platform is on Google Cloud and BigQuery plus open engines (Spark, Flink, Trino) must share the same Iceberg tables over one serverless catalog.
- You want zero operations: nothing to provision or size, with files staying in your own Cloud Storage buckets.
- Table maintenance should be optional to own; per-table opt-in hands compaction and garbage collection to Google.
- Engines should get short-lived, downscoped storage tokens rather than broad IAM on the bucket.
Think twice when
- Your tables are Delta Lake or Hudi; this catalog is Iceberg only, and Iceberg V1 is not supported at all.
- Catalog portability off Google Cloud matters; Polaris or Lakekeeper keeps that layer neutral.
- You need git-style branching or cross-table commits; versioning is Iceberg snapshots and nothing more.
- Documentation churn is a cost: renamed from BigLake metastore in April 2026, so most existing tutorials use the old name, and BigQuery's own read and write through the REST endpoint is still in preview.
How it runs
A serverless, regional Google Cloud service implementing the Iceberg REST Catalog API, with a Hive metastore endpoint in preview and outward federation to Unity Catalog, Glue, and Snowflake. Governance is IAM roles, with fine-grained controls arriving through BigQuery managed tables. Billing meters catalog operations in two classes with monthly free allowances; for most platforms the catalog layer rounds to nearly nothing.
Details
CompareHow Google Cloud Lakehouse Runtime Catalog answers the questions Table Catalogs turns on.
Table Catalogs
| How it works | |
| Protocol | The Apache Iceberg REST Catalog API, which is the recommended endpoint and the GA one, alongside an Apache Hive metastore endpoint in preview for workloads built against the HMS interface, and a third form that uses the BigQuery catalog directly for BigQuery-managed tables. Federation runs outward as well, borderless Lakehouse, in preview, fronts remote catalogs in Databricks Unity Catalog, AWS Glue, Snowflake and SAP Business Data Cloud over OIDC token federation or OAuth rather than long-lived keys |
| What it catalogs | A catalog, a namespace and a table, three levels and nothing beyond them, no files, functions, models or views. Where Glue enumerates object types because AWS bills by them, this catalog bills by operations instead, so the hierarchy is a modelling decision rather than a price list |
| Branching and versioning | Iceberg snapshots and nothing git-style, no branches, tags or cross-table commits. V3's binary deletion vectors, in preview, address the volume of updates and deletes rather than adding anything to history |
| Running it | |
| Maintenance | Google's own phrasing is the answer, "managed by you, or optionally by Google (Preview)". Opt in per table with a single property and compaction and garbage collection are handled for you, GA for Iceberg tables in the BigQuery catalog and preview for the REST catalog since June 2026, metered at $0.12 a DCU-hour. The same feature as Glue's optimisers, an inch earlier in its life |
| What you run | Nothing: a serverless, regional service. The catalog layer manages transaction commits while metadata files and data files stay in the customer's own Cloud Storage bucket, so there is no cluster, no sizing and no database behind it |
| Connections | |
| Table formats | Iceberg and only Iceberg: V2 at GA, V3 with binary deletion vectors in preview since June 2026, and V1 not supported at all rather than merely discouraged. No Delta Lake and no Hudi. The REST endpoint's documented data limitation is Parquet, where the wider Lakehouse product reads ORC and Avro too |
| Engine support | Spark, Flink and Trino read and write at GA, and anything carrying an Iceberg REST client can connect. The asymmetry worth noticing is that BigQuery's own read and write through the REST catalog is still preview, Google's engine is the one that arrived last, and open-source engines got there first |
| Access | |
| Access control | Three IAM roles (BigLake Admin, Editor and Viewer, granted at project level) with table-level IAM policies in preview since April 2026. Managed Iceberg tables in BigQuery add the fine-grained layer on top: column-level security, row-level security and data masking |
| Storage credentials | Short-lived downscoped storage tokens, and this is the mechanism rather than an IAM delegation, the catalog authenticates the caller, checks IAM, then hands back a token scoped to the table's paths and cut to the minimum permission, read-only where the query never writes. Engines declare support in the X-Iceberg-Access-Delegation header, it is available on REST catalogs and not on Hive ones, and the point is that nobody needs broad IAM on the bucket |
| Cost | |
| Billing unit | Operations in two classes, metered the way Cloud Storage meters requests. Class A covers writes and metadata work (create, register, list, update and setIamPolicy) free to 5,000 a month and $6.00 per million above it; Class B covers reads, deletes and getIamPolicy, free to 50,000 a month and $0.90 per million. A metadata file over 1 MB counts one extra operation per incremental megabyte. Table management is separate at $0.12 a DCU-hour, compute bills through BigQuery or Managed Service for Apache Spark, and the data sits at ordinary Cloud Storage rates |
Alternatives to Google Cloud Lakehouse Runtime Catalog
