9 Min. tiempo de lectura

Google agrupa BigQuery, AlloyDB, Spanner y Apache Spark bajo un mismo nombre y lo llama Agentic Data Cloud. Esto suena a marketing. Pero se vuelve concreto si se observa más de cerca el anuncio de Cross-Cloud-Lakehouse: BigQuery ahora puede consultar tablas Iceberg en Amazon S3 sin tarifas de salida, a través de las líneas de interconexión Cross-Cloud de Google. Esto no es un anuncio de características. Es un argumento de precio contra Databricks.

Lo más importante en resumen

• Cross-Cloud Lakehouse sin tarifas de salida: BigQuery lee y escribe tablas Iceberg en AWS S3 y Azure Data Lake Storage sin tarifas de salida a través de Cross-Cloud Interconnect. Sin movimiento de datos, sin copias, sin pagar dos veces.
• Federación de catálogos bidireccional: Databricks Unity Catalog, Snowflake Polaris y AWS Glue ahora están federados. Los motores leen y escriben directamente en el catálogo de los otros. Compartición sin copias sin ETL.
• Migración en unos 9 meses: Google indica que el promedio para las migraciones de nube a nube es de nueve meses, significativamente menos que el marco de tiempo de varios años comunicado anteriormente.
• Iceberg gestionado GA: BigQuery Lakehouse está generalmente disponible con gestión automática de tablas, transacciones multi-tabla, captura de datos de cambio y optimizaciones basadas en historial.

RelacionadoState of FinOps 2026: Technology Value Management  /  BYOD en la empresa alemana 2026

Lo que Google entiende por Agentic Data Cloud

Google posiciona BigQuery, AlloyDB, Spanner y Apache Spark como una plataforma unificada contra Databricks y Snowflake. Lo que esto significa en la práctica para las arquitecturas DACH se muestra en los anuncios de Google Cloud Next 2026 en detalle.

¿Qué es la Google Agentic Data Cloud? Es el marco estratégico que engloba AlloyDB, BigQuery, Spanner, Bigtable y el servicio gestionado de Apache Spark. Objetivo: preparar los datos empresariales no solo para analistas humanos, sino también como contexto para agentes de IA autónomos. En el centro se encuentra un «Universal Context Engine», una capa que evita que los agentes «alucinen» porque no tienen acceso a los datos empresariales correctos.

Esto está pensado de manera técnicamente consecuente. Los flujos de trabajo de Agentic no necesitan informes estáticos, necesitan acceso a datos en tiempo real, tanto de lectura como de escritura, más allá de los límites del sistema. Hasta ahora, este era el argumento para Databricks: una plataforma abierta basada en Spark que, en principio, puede comunicarse con todo. Google ahora intenta desvalorizar este argumento.

Concretamente, esto significa: los agentes basados en Gemini en Vertex AI pueden acceder directamente a BigQuery sin tuberías ETL manuales. El marco Cortex de BigQuery acelera esto con conectores prefabricados para SAP, Salesforce y Oracle. Esto suena como una solución de catálogo estándar, pero en la amplitud de las integraciones y en la profundidad de la integración con GCP, es realmente nuevo.

Cross-Cloud Lakehouse: el verdadero ataque

La parte que resulta relevante en las conversaciones con clientes de Databricks no es la marca Agentic. Es el Lakehouse multiplataforma. BigQuery ya puede leer y escribir tablas Iceberg que físicamente residen en Amazon S3 o Azure Data Lake Storage. La conexión se realiza a través de Cross-Cloud Interconnect: un enlace privado dedicado, sin uso de internet público ni cargos por salida de datos (egress).

Esto es significativo porque invalida el argumento tradicional sobre los costes de salida de datos. Hasta ahora, migrar a BigQuery solía ser costoso precisamente porque había que mover los datos desde S3 o Azure. Quien hoy opera Databricks en AWS y quiere probar BigQuery al menos en paralelo, ya no necesita planificar grandes movimientos de datos. El Lakehouse permanece en S3 y BigQuery accede directamente a él.

Federación de catálogos y la manzana de la discordia de Databricks

La federación de catálogos es la segunda gran palanca. Google ha anunciado federación bidireccional con Databricks Unity Catalog, Snowflake Polaris y AWS Glue. Los motores pueden leer y escribir directamente en los catálogos del otro sin copias de datos ni pipelines ETL intermedios. Compartición sin copia (zero-copy-sharing).

Para empresas de la región DACH que ya operan con Databricks y se preguntan si BigQuery podría adaptarse mejor a ciertas cargas de trabajo, esta situación cambia completamente la conversación respecto a hace doce meses. Ya no hay que elegir. Se puede empezar a trasladar cargas de trabajo de forma selectiva, mientras la base de datos permanece en S3 o en Databricks.

«La migración ya no es un proyecto de varios años. Los movimientos entre nubes hoy tardan una media de nueve meses. La pregunta ya no es si migrar, sino qué carga de trabajo debe ir primero.»

BigQuery Lakehouse vs. Databricks para arquitecturas DACH

En entornos empresariales DACH, la discusión suele girar en torno a tres ejes: gobernanza y soberanía de datos, costo total de propiedad y conexión con los entornos SAP existentes. Google ha abordado directamente los tres.

Quienes construyen principalmente analítica, BI y contexto de agentes en el ecosistema GCP, encuentran hoy en BigQuery Lakehouse un argumento serio. Quienes operan flujos de trabajo de Machine Learning basados en Spark con equipos de ciencia de datos y desean mantenerse agnósticos a la nube, siguen teniendo mejores cartas con Databricks.

Lo que esto significa para la decisión en 2026

El contexto ha cambiado. Quien en 2024 aún decía «nos quedamos con Databricks porque el cambio a BigQuery cuesta demasiado» – el argumento de salida tiene limitaciones una vez que Cross-Cloud Lakehouse esté disponible en la propia región. El movimiento de datos deja de ser el principal costo.

Lo que queda son las preguntas reales: ¿Qué cargas de trabajo están cerca de GCP? ¿Dónde operamos Machine Learning más allá de la analítica? ¿Qué tan profunda es nuestra integración con SAP? Estas respuestas deciden, no el costo de salida.

Para los arquitectos DACH, esto significa: La próxima licitación de la plataforma de datos vale la pena recalibrarla. No porque BigQuery sea automáticamente mejor ahora, sino porque Google Cloud Next 2026 ha cambiado la base de comparación. Databricks reaccionará. Cómo lo hará, lo mostrará el resto del año.

Preguntas frecuentes

¿Qué es Google Agentic Data Cloud y qué lo diferencia de las ofertas anteriores de BigQuery?

Agentic Data Cloud es el marco estratégico de Google para AlloyDB, BigQuery, Spanner, Bigtable y Managed Apache Spark. La diferencia con las ofertas anteriores de BigQuery radica en el enfoque: dejar de lado el análisis humano y pasar al consumo de datos por parte de agentes de IA. El Universal Context Engine, como nueva capa, debe evitar alucinaciones al proporcionar a los agentes acceso directo y estructurado a los datos empresariales.

¿Cómo funciona técnicamente Cross-Cloud Lakehouse sin tarifas de salida?

BigQuery accede a las tablas de Iceberg a través de Cross-Cloud Interconnect, que se encuentran físicamente en Amazon S3 o Azure Data Lake Storage. Cross-Cloud Interconnect es una conexión de línea privada dedicada entre Google y los otros hiperescaladores, sin pasar por internet público, por lo que no hay costos de salida. Las consultas se ejecutan como consultas nativas de BigQuery, aunque las tablas están en infraestructura externa.

¿Qué significa Catalog Federation para las instalaciones existentes de Databricks?

Catalog Federation permite conexiones bidireccionales entre BigQuery y Databricks Unity Catalog. Los motores de ambos lados pueden leer y escribir directamente, sin copias de datos ni pipelines ETL. Para las empresas con instalaciones existentes de Databricks, esto significa que BigQuery puede utilizarse para cargas de trabajo de análisis seleccionadas sin tocar la base de datos de Databricks.

¿Es cierta la afirmación de Google de que las migraciones ahora solo duran nueve meses?

Google comunica nueve meses como valor promedio para migraciones de nube a nube. Esto se refiere a la migración pura de datos con las herramientas de migración y evaluación de Google para cargas de trabajo de Databricks. El plazo de nueve meses suena convincente, pero debe contrastarse con el propio perfil de complejidad: la integración de SAP, las pipelines de ML existentes y los requisitos de gobernanza pueden requerir significativamente más tiempo.

¿Para qué empresas de DACH tiene sentido cambiar a BigQuery Lakehouse hoy en día?

Tiene sentido principalmente para empresas que ya trabajan intensamente en el ecosistema de GCP y pueden separar las cargas de trabajo de análisis de los flujos de trabajo de ML basados en Spark. Los entornos SAP fuertes se benefician de los conectores Cortex. Sin embargo, aquellas con equipos de ciencia de datos con profunda experiencia en Spark y que operan flujos de trabajo de Databricks MLflow no tienen una razón imperativa para cambiar; hoy en día, la federación permite la coexistencia en lugar de una elección exclusiva.

Fuente de la imagen: Pexels / Noura Zaher (px:33596987)

Foto: Pexels (CC0)