Google Cloud detailed the integration of Gemini with borderless Lakehouse on October 15, describing infrastructure that allows companies to work with data distributed across platforms. The integration is in preview and enables access to sources such as Databricks Unity Catalog and Snowflake Horizon to be configured directly from Gemini through data catalog federation.
The feature concerns questions and analyses that use an organization's information. In this architecture, agents identify relevant data and send queries to the engines that process it. Conversational Analytics can work with federated tables alongside BigQuery data and other configured sources. Information access depends on connections and permissions defined in the company's infrastructure.
Data connections retain the role of existing permissions
The BigQuery connector documentation for Gemini Enterprise describes two operating modes. Federated query, which is in preview, sends the request to BigQuery using the user's identity and preserves IAM rules, including row-level access. Data ingestion copies information from a specific table into a Gemini Enterprise data store and requires refreshing to reflect source changes.
These instructions apply to the Standard, Plus, Pay-as-you-go and Frontline editions of Gemini Enterprise. The Business edition has separate documentation. In federated mode, users can analyze the tables and datasets they have permission to access, while running queries incurs BigQuery compute costs. Enabling a connector and having permission to read data are separate requirements.
The Lakehouse runtime catalog centralizes table metadata in a managed, serverless service. Metadata describes the structure and location of information, while data files remain in the storage layer. Engines such as BigQuery and Apache Spark can use the same catalog through interfaces compatible with the open standards used for Apache Iceberg tables.
The catalog architecture separates a table's registration, metadata about its structure and versions, and the files containing the actual data. In configurations that delegate storage access, engines receive temporary, scoped credentials. This separation allows access to resources to be managed without turning the discovery of a table into general permission over the entire storage environment.
Agents receive technical context and business definitions
Knowledge Catalog adds tools to search for accessible data and retrieve context. This context can include table schemas, column descriptions, company glossary terms and previously verified queries. The integration is read-only and can be enabled automatically when a Gemini Enterprise application receives a Data Cloud connector in federated mode.
Catalog searches use the authenticated person's identity. Records that the user lacks permission to access are filtered out of discovery results. Additional metadata and third-party sources have specific catalog permissions. A table's description and access to its contents are therefore controlled according to the resource and identity involved.
Querying external tables also requires permissions on the execution engine. The Lakehouse documentation lists roles for reading BigQuery data, running jobs and discovering metadata. Once a connection is configured, federated tables can be analyzed through SQL in BigQuery or through Apache Spark. Lakehouse handles metadata translation and access to the associated source.
For custom applications with AI integration, programmatic access can use the BigQuery MCP server. It provides tools for queries, metadata and resource inventories, with authentication and authorization through OAuth and IAM. The application using it determines the tools available to an agent within the permissions granted to its identity.
The MCP documentation distinguishes the read-only execution tool from the tool that also accepts modification operations. The query tools have a documented default time limit of three minutes and results capped at 3,000 rows. These are limits on those specific tools; the volume stored and the data platform's processing capacity are separate layers of the system.
Queries across platforms involve transport and regional caching
Cross-cloud access discovers the structure of information in external catalogs and reads the data a query needs. Authentication can use credentials held in Secret Manager or identity federation. Supported connections depend on the provider and source configuration; the documentation lists AWS Glue, Databricks Unity Catalog and Snowflake Horizon Catalog, among others.
As data blocks are read, they can be cached temporarily in Google Cloud for reuse by subsequent queries. The cache resides in the connection's target region, while traffic to the external provider depends on the data that must be retrieved from the source. Querying without migrating an entire set of files therefore includes transferring and regionally storing the blocks needed for processing.
Cross-Cloud Interconnect provides a dedicated connection between Google's network and that of a supported cloud provider. Its configuration involves resources and ports in both environments, while availability design includes redundancy. This component provides the private network path; the catalog, identities and query engine retain their own roles in accessing data.
Connection availability is described through region pairs and interconnect types. For example, the documentation identifies Google Cloud Frankfurt as the closest region to AWS Frankfurt and marks the corresponding interconnect options. The location of infrastructure and cached data is part of the technical data configuration, separate from the language in which a user asks a question.
Importing through Dataflow is a separate workflow
Google separately documents importing Delta Lake tables from Cloud Storage into Lakehouse through Dataflow. In this workflow, data is copied to the destination table through a job that scales its resources with volume. For existing tables, the destination schema must match the source. The feature uses a batch pipeline and has different requirements from federated queries of data held by another provider.
After import, continuous migration can use change data capture, with the required Delta Lake property enabled and subsequent jobs scheduled. The documentation limits this import to valid Delta Lake sources in Cloud Storage; Amazon S3 is not supported as a source for that particular operation. Within Lakehouse, connection, querying and migration remain mechanisms with their own technical requirements.
