Enterprises running Snowflake, Databricks, and BigQuery side by side no longer struggle with data movement. Data pipeline tools solved that years ago. Now they have a metrics problem: the same “gross margin” or “active users” number means something different depending on which warehouse answered the query, and almost nothing on the market is built to fix it. Accenture found that 47% of CXOs say data readiness, not AI capability, is their top obstacle to generative AI. Inconsistent metrics across platforms are a direct symptom of that gap.
What multi-cloud solved
Ask most tools how to handle multiple data sources, and you’ll get an answer about connectors. Fivetran, Airbyte, and Matillion make it easy to move data between warehouses. But what does the data mean once it lands? A customer count pulled from Snowflake can differ from one pulled from Databricks because two different teams wrote two different definitions of “customer.”
Data movement vs. metric governance: two different jobs
Moving data and defining what a metric means are two different jobs, and most of the market focuses only on the first. Data platforms differ mainly in where compute and storage live. Snowflake, Databricks, and BigQuery each has its own architecture and pricing, with different trade-offs for different workloads. None of that touches how a metric gets defined, and it’s not supposed to.
A semantic layer operates one level up: it defines what “gross margin” means, then enforces that definition regardless of which platform is asked. Skip it, and every warehouse becomes its own silo of business logic.
Why multi-dimensional metrics are the hard part
Not every metric breaks the same way. A simple count, like units sold, can be summed up by any hierarchy and still mean the same thing at every level. A multi-dimensional metric can’t.
Take a metric like gross margin return on inventory investment: margin dollars divided by average inventory at cost. Margin is a rate. You don’t sum a rate, you calculate it. Average inventory is a point-in-time balance, and you can’t just add it across weeks. Both pieces have to be recalculated from scratch for every category, region, and time slice, then divided again to get the ratio right.
Most SQL- and dbt-based metrics layers compute a single formula and let the warehouse’s GROUP BY handle the rest. That’s fine for units sold. It falls apart here: you get a single blended number that averages out the categories actually losing money.
AtScale evaluates the ratio at whatever level you’re looking at, department, region, or week, instead of pre-aggregating a static column, so the same definition holds whether you’re viewing it company-wide or drilled into a single category. If a rate metric like this already breaks within a single warehouse when computed the naive way, it breaks twice as badly when two teams build two separate versions across two different platforms.
What happens when metrics aren’t governed across warehouses
Here’s the scenario that plays out at almost every company running more than one warehouse. Finance builds its gross margin model in Snowflake. Ops, working off a Databricks pipeline for a different initiative, builds their own version. Both are technically correct. Neither matches the other.
One semantic layer, every warehouse
A governed semantic layer sits entirely above the warehouse, so the metric definition travels with the query rather than living inside whichever platform happens to answer it. AtScale’s Universal Semantic Layer provides a single, governed model accessible from Snowflake, Databricks, or other platforms, so “gross margin” means the same thing regardless of where the data physically resides. Our Breaking Data Silos with Cross-Cloud Semantic Layers post goes into more detail on how that works across cloud boundaries.
How AtScale fits with Fivetran, Snowflake, and Databricks
To place it in the stack: Fivetran, Airbyte, and Matillion move data between systems. Snowflake and Databricks store and process it. AtScale sits above both. It governs what the metrics mean once several teams start querying the same data. It’s easy to overlook this layer until two departments report two different numbers for the same thing.
Third-party recognition: GigaOm names AtScale a leader
AtScale was named a Leader and Fast Mover in GigaOm’s 2025 Radar for semantic layers, following the same recognition in GigaOm’s 2024 Sonar report. Independent, analyst-backed confirmation that a governed semantic layer is the right tool to keep metrics consistent across multiple warehouses.
FAQ
Warehouse versus lakehouse comes down to storage and compute architecture. That’s the easy part. Either way, you’ll still need something above it that defines metrics once and enforces that definition everywhere, or you’ll end up recreating the same inconsistency problem on the new platform.
Platforms that accelerate AI adoption still depend on trustworthy inputs. An AI agent querying ungoverned data across multiple warehouses will confidently return inconsistent answers. A governed semantic layer provides AI and BI tools alike with a single, trustworthy source of metric truth to query against.
Most answers to this question are really about data movement, tools like Fivetran or Matillion that connect sources to a warehouse. While that’s necessary, it doesn’t keep a metric’s definition consistent when several teams and platforms query the same data.
Running more than one warehouse? See how AtScale closes the multi-cloud metrics gap other tools miss.
Reviewed by: Dave Mariani
SHARE
Guide: How to Choose a Semantic Layer