The latest preview adds a native Gemini front‑door to the borderless Lakehouse, letting agents query and generate code against data in external clouds (e.g., Databricks Unity Catalog, Snowflake Horizon) without moving the data. Engineers care because this removes a major data‑movement bottleneck, expands cross‑cloud analytics, and introduces new operational and security surfaces to manage.
New Gemini Integration
Gemini can now connect directly to the Lakehouse catalog federation. In preview, you can register external sources such as Databricks Unity Catalog or Snowflake Horizon and issue natural‑language queries that are resolved against the remote tables. The integration also enables agents to ground their reasoning and emit code that operates on those tables, all while the data remains in its original location.
GA Features Expanding the Lakehouse
- Cross‑cloud Interconnect and caching for AWS and Azure.
- BigQuery support for Apache Iceberg V3 specifications.
- Read‑write interoperability on Iceberg tables for BigQuery and Managed Service for Apache Spark.
- AlloyDB lakehouse federation.
- Bi‑directional caching with AWS Glue, Databricks Unity Catalog, and Snowflake Horizon Catalog via runtime federation.
- Integration with Knowledge Catalog.
- Zero‑copy data integration with Salesforce, SAP, Workday, and Confluent Tableflow.
- Synchronization of Databricks Delta Lake assets through the Lakehouse console using Dataflow.
Architectural and Operational Considerations
Implementing the Gemini‑Lakehouse link requires configuring catalog federation entries for each external source and ensuring network connectivity through the cross‑cloud interconnect. Because data is accessed in place, you must verify that IAM or equivalent access controls on the source systems are correctly mirrored in the Lakehouse federation layer. The bi‑directional caching mechanisms introduce a cache‑coherency consideration: updates in the source may need to be flushed or invalidated to keep agent results fresh.
From an operations perspective, the new read‑write Iceberg support means you can treat Lakehouse tables as both source and sink for Spark jobs and BigQuery workloads, simplifying pipeline orchestration but also requiring monitoring of write‑path latency and consistency across services. The zero‑copy connectors for SaaS platforms reduce ETL overhead, yet they still depend on the source APIs being available and correctly scoped.
Related CloudNinjas coverage: Google Cloud.
What This Means For Practitioners
- Evaluate which external catalogs you need to federate and set up the corresponding Lakehouse catalog entries before enabling Gemini agents.
- Review and align access policies across Google Cloud, AWS, Azure, and SaaS sources to avoid accidental over‑exposure.
- Test the bi‑directional cache behavior in a staging environment to understand latency and staleness characteristics.
- Leverage the read‑write Iceberg capability to consolidate Spark and BigQuery pipelines, but instrument observability for cross‑service write failures.
- Monitor the preview rollout of Gemini integration for any breaking changes before moving production workloads.
