Google's borderless lakehouse wires AWS, Databricks and Snowflake catalogs into one Iceberg REST surface

The scene I keep replaying is from earlier this month. An agent in one of our data pipelines needed a metric that lived in Snowflake, a fact table that sat in an AWS bucket behind Glue, and one Delta table in Databricks that was the source of truth for a currency conversion. Three catalogs, three IAM stories, three flavours of "please copy this into BigQuery first." That copy step is the whole reason your data engineers quietly stopped enjoying weekends. Google Cloud's announcement this week, filed under the name "borderless Lakehouse," is a bet that the copy step can go away, at least for reads, and that it should go away first for the agents already wired into your pipelines.

What actually landed, in one paragraph

Google Cloud is putting three things into preview and one thing into general reach. Catalog federation for AWS Glue, Databricks Unity Catalog and Snowflake Horizon is in preview, sitting on top of an Iceberg REST catalog. A Knowledge Catalog, described as an agentic context engine that syncs with those same three external catalogs, is in preview. Cross-cloud interconnects gain a flat-rate pricing tier from 1G to 100G, and Google says variable egress for AWS reads over that link goes to zero. The one thing outside preview language is the Data Agent Kit, an open-source toolkit with Model Context Protocol tools for BigQuery, Managed Service for Apache Spark and Cloud Storage. Everything else in the post reads as extensions of these primitives.

The piece that changes the wiring

I care most about the Iceberg REST catalog underneath. If your data warehouse can be reached through an Iceberg-shaped API, then the federation story stops being "please install this connector." BigQuery, Managed Spark and, per Google, transactional systems like AlloyDB via Lakehouse Federation can point at that surface and see tables that live in the other clouds' catalogs. The company also names Spanner Omni, a Spanner deployment that runs outside Google Cloud, as part of the same story. There is also an intelligent cross-cloud caching layer that keeps repeatedly-read fragments warm on Google's side so you are not paying the round trip on every query.

The practical version is that a pipeline task that used to be "copy from Snowflake into BigQuery, then read" becomes "read." That is the whole design intent. Whether it is that clean in production is what previews are for.

Where the agents come in

The Data Agent Kit is where this stops being a data-warehouse story and starts being a CI-adjacent one. The kit is open source and ships MCP tools for BigQuery, Managed Spark and Cloud Storage, which is the same protocol your coding agents and IDE hosts already speak. Google also mentions a Conversational Analytics API for building your own agents, and a Gemini Enterprise integration that lets business users query across the federated set in natural language. On the guardrail side, BigQuery gains pre-query token estimation, per-query limits and a cost-optimised mode selector for AI functions. Google claims a 230x reduction in token consumption when the cost-optimised mode is picked. I would treat that number as a vendor claim until you have run it against your own workload.

The rough edges I would want you to see

Three of them, plainly. First, "preview" is doing a lot of work in this post. Catalog federation, the Knowledge Catalog metadata ingestion for external catalogs, and the runtime catalog auto-sync are all in preview at launch, so pinning production reads to any of those is a bet, not a decision. Second, cross-cloud interconnect pricing is flat-rate on the link itself, but the announcement is careful about which egress bill it zeroes out and which it does not. Read the fine print before you tell finance the AWS bill is about to drop. Third, the Knowledge Catalog is pitched as agent-facing context: it auto-translates raw schemas to business terminology and indexes column-level lineage. That is exactly the layer where a wrong synonym or a stale lineage edge turns into a wrong answer with a very confident tone. Whatever review flow you have for prompt context should apply here from day one.

What I am watching next

Two things. Whether the Iceberg REST layer stays honest as more external systems bolt onto it, because REST catalogs that quietly grow proprietary extensions are how portability dies. And whether the Data Agent Kit's MCP tools stabilise fast enough that a CI job can lock a specific tool version the way it locks an SDK, so an agent-driven pipeline does not surprise you on a Monday. If those two hold, the "copy first" step is on its way out for a lot of us, and my next long weekend gets a little more likely.