Cross-cloud conversational analytics made simple with open standards
The reality for most organizations is that data lives everywhere. As engineering teams expand and adopt specialized platforms for their workloads, enterprise data naturally disperses across multiple clouds and operational systems.
The reality for most organizations is that data lives everywhere. As engineering teams expand and adopt specialized platforms for their workloads, enterprise data naturally disperses across multiple clouds and operational systems.
Traditional architectures address this fragmentation with scheduled extraction pipelines that copy remote datasets into a central staging warehouse. This approach creates synchronization lag, adds recurring storage costs, and triggers variable network egress fees. When schemas change upstream, pipelines break, and teams spend hours reconciling metrics across out-of-sync dashboards.
BigQuery and Google Cloud’s borderless Lakehouse offer a streamlined way to solve this challenge with a foundation based on the open Apache Iceberg REST catalog specification. Rather than moving data to the compute engine, you can bring Google Cloud compute and generative AI directly to your data, querying it in place across Databricks, Snowflake, and AWS Glue.
In this post, we walk through how to configure Databricks Unity Catalog for federation into BigQuery (AWS Glue and Snowflake set up in appendix), run a single query joining data across all three external catalogs, and use conversational analytics in BigQuery to explore the consolidated data with natural language.
Figure 1: BigQuery federates metadata across external Apache Iceberg REST catalogs through Lakehouse, enabling in-place conversational analytics without data migration.
The borderless lakehouse architecture This solution uses Lakehouse runtime catalog to synchronize metadata from other cloud providers, allowing you to query data with BigQuery or external open source engines through the Apache Iceberg REST catalog endpoint, all without migrating the data. Because Databricks Unity Catalog, Snowflake Horizon Catalog, and AWS Glue Data Catalog support the open Apache Iceberg REST catalog specification, you can apply a consistent connection pattern across all three platforms.
In context
- Topic: Cloud y Arquitectura — Nube pública, híbrida, costos y decisiones de infraestructura.
- Source: Google Cloud Blog
- Published: 13/10/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
The cloud stopped being a technical decision a long time ago. Today it is a financial decision with technical consequences: capital investment gets swapped for monthly spend, and that swap suits some companies very well and others very badly.
I separate what moves for cost from what moves for capability. Migrating to save money almost never works; migrating to be able to do something you could not do before does. When the argument is only savings, it is worth checking the numbers again because they are usually incomplete.
What usually goes wrong
What I see fail most is the literal migration. The system gets moved exactly as it was, nothing redesigned, and you end up paying hourly for what used to be paid once. It works the same, costs more, and two years later somebody asks why it was done. Lift and shift is not modernising.
What to watch
- Who sees the bill and in what detail: with no owner for the spend, the spend grows on its own.
- Where the data physically sits and what local regulation demands about that.
- What happens when the provider has an outage, because it will, and what keeps running meanwhile.
How I read this entry
If this fed into an infrastructure decision, I would ask for the three-year total cost with real growth built in, not year one with the entry discount. Most cloud surprises live in year two, when the discount ends and the volume has already gone up.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
