In modern data architectures, analytics tools often replicate data from the warehouse into secondary systems to improve performance. While this can speed up dashboards, it introduces new problems: duplicated datasets, inconsistent metrics, fragmented governance, and rising cloud costs. Modern analytics architectures increasingly avoid these issues by querying data in place using a semantic layer that standardizes metrics and optimizes performance.
Cloud data platforms were supposed to end the era of fragmented, duplicated data. And yet many modern BI and AI architectures are quietly reintroducing it.
Platforms like Snowflake and Databricks delivered on their core promise. Now the challenge for many organizations is how their various analytics tools connect to them and what to do when those connections feel slow.
The result is a pattern so common it rarely gets questioned: data extracts.
What Is Data Extracts in Analytics?
Data extraction in analytics refers to the practice of copying datasets from a central data platform into secondary systems, BI engines, performance caches, or local extracts to improve query performance. It’s a pattern most data teams are familiar with, and in the short term, it works. Dashboards load faster. End users stop complaining.
The problem compounds quietly over time: duplicated datasets, inconsistent metric definitions, and governance complexity that grows with every new data copy. Understanding why that pattern became so common requires going back to what the modern data platform was actually designed to solve.
How Cloud Data Warehouses Eliminated Data Silos
A decade ago, organizations began consolidating analytics data into centralized cloud platforms. The value proposition was straightforward: a single, governed system of record, consistent access to enterprise data, shared definitions for metrics and dimensions, and far less operational overhead from managing dozens of siloed reporting databases.
Cloud data warehouses eliminated real problems that plagued enterprise analytics for years. Data marts scattered across departments meant every team was working from a different version of the truth. ETL pipelines duplicated business logic in incompatible ways, so the same metric could be calculated a dozen different ways depending on which system produced it. Finance and marketing routinely arrived at different revenue figures because they were working from different copies of the data. The promise of the modern data platform was simple: store data once, query it everywhere.
Performance realities complicated that promise.
Why Replicating Data for BI Recreates Data Silos
BI tools have historically struggled to query large warehouses efficiently at scale. The workaround is familiar: extract the data. Import it into BI tool storage. Replicate it into a secondary engine. Cache it outside the warehouse to speed up queries.
At first glance, this looks like a reasonable trade-off. What happens over time is more onerous.
Each analytics environment develops its own copy of the data. Power BI models, Fabric storage layers, and departmental reporting datasets all start from the same warehouse and gradually diverge from it. Revenue ends up calculated differently in marketing dashboards than in finance. Inventory metrics vary between operations and the supply chain. These small definition gaps compound across teams and over time.
Governance becomes another problem. When data exists across multiple environments, access controls must be duplicated. Security rules drift. Compliance policies that are straightforward to enforce against a single warehouse become difficult to enforce across a distributed landscape of analytics copies. Organizations end up managing governance across five systems instead of one.
There’s a concept in data architecture called data gravity, the idea that large bodies of data naturally attract applications, services, and other data to them. Cloud data warehouses have enormous gravity. Decades of enterprise data, carefully governed and centralized, draw analytics tools, AI systems, and business logic toward it for good reason.
Replication works against that gravity. Every extract, every imported dataset, every BI engine cache creates a smaller, weaker data body with its own gravitational pull and drift trajectory. Over time, those secondary data bodies attract more applications. Teams build reports on top of them. AI agents get pointed at them. Removing them becomes difficult.
What started as a performance workaround becomes load-bearing infrastructure that’s expensive to change.
Why Data Replication Breaks AI and Agentic Analytics
For most of the last decade, metric drift and data replication were expensive inconveniences. A human analyst could catch a discrepancy, reconcile definitions, and course-correct.
AI agents don’t do that.
When an LLM queries a replicated extract or a raw warehouse schema without a governed context, it doesn’t know what “gross margin” means for your organization. It doesn’t know how your fiscal calendar differs from a standard one, how you handle currency conversions, or how your retail inventory logic handles first and last items in a period. It infers. And at query volumes that scale from dozens to millions per day, inference errors compound at machine speed.
We benchmarked this directly using TPC-DS, the industry-standard retail benchmark schema. LLMs querying raw database tables achieved roughly 20% accuracy on complex, multi-fact business queries. Add a governed semantic layer, one that provides the LLM with pre-defined joins, business logic, and metric definitions, and accuracy reaches 100%. That gap is the difference between a system that works in production and one that doesn’t.
When AI agents are in the loop, data movement degrades analytics quality at scale.
The Lock-In Hidden Inside Platform-Native Semantics
There’s a related architectural decision that’s worth examining closely. Snowflake and Databricks have both introduced native semantic layers, Semantic Views and UC Metrics Views, respectively. Their argument is that semantic logic should “shift left” and live inside the data platform itself.
The appeal is obvious. Less infrastructure to manage. Tighter integration with platform-native tools.
The tradeoff is harder to see until it’s expensive. Consider a large enterprise with a dozen downstream applications, BI tools, custom chatbots, AI agents, all relying on a single metric like “gross margin.” If that definition lives inside Snowflake, every application that consumes it is coupled to Snowflake. Migrating to Databricks means retooling every downstream system. Switching BI tools means rebuilding the logic from scratch against a new platform.
An independent semantic layer acts as a firewall between the data platform and the tools that consume it. Business logic stays constant regardless of what’s behind it or in front of it. Organizations can change their data platform, add a new BI tool, or connect a new AI agent without dismantling the semantic foundation they’ve built. That portability is the only model that scales without creating new dependencies.
“Shift left” semantics is a reasonable choice for organizations fully committed to a single vendor. For most enterprises, it trades one fragmentation problem for another. With the growing popularity of open storage formats like Iceberg, it makes even less sense today to bet the farm on a single data warehouse engine.
How a Semantic Layer Enables Agents and Analytics Without Moving Data
Modern power infrastructure solved an analogous problem decades ago. Rather than building a miniature power plant next to every factory, office complex, or neighborhood that needed reliable electricity, engineers centralized generation and optimized distribution. The grid delivers power efficiently wherever it’s needed without duplicating the source.
Analytics architecture should follow the same model. Cloud data platforms already act as the centralized generation layer for enterprise data; they store and govern the system of record. Replicating warehouse data into BI engines is like building miniature power plants next to every building that needs electricity. Local performance improves, but costs multiply and control fragments.
A semantic layer solves the distribution problem the same way the grid does. It sits between the data platform and the tools that consume data, handling performance, governance, and metric consistency without requiring replication. It’s not a cache that copies data. It’s a query translation layer that allows AI agents and BI tools to query the warehouse in real time, with the performance of a native caching and the governance of a single source of truth.
The semantic layer standardizes metric definitions across all tools that connect to it. Revenue, customer lifetime value, active users, and inventory levels are defined once, centrally, and exposed consistently to Power BI, Tableau, Excel, custom AI agents, and any other tool in the stack. When those definitions change, they change in one place, not in a dozen replicated models scattered across environments.
Because every query passes through the semantic layer, governance is enforced centrally as well. Role-based access control, row-level security, data masking, and audit logging apply uniformly, whether the query is coming from a dashboard or an autonomous AI agent. That’s a meaningful constraint when agents are making decisions at scale, and it’s nearly impossible to retrofit afterward.
There’s also a cost dimension. Agents without governed query paths tend to generate expensive, open-ended warehouse scans. A semantic layer routes queries to pre-aggregated structures, caps compute consumption, and prevents agents from triggering runaway queries. The result is lower cloud costs alongside better performance.
What Modern BI Architecture Should Look Like
The traditional BI pattern looks like this:
Warehouse → Extract → BI Engine
Each step in that chain introduces a copy of the data, a new governance perimeter, and a new source of potential drift.
The modern pattern is simpler:
Warehouse → Semantic Layer → AI Agents + BI Tools
Centralize the data. Optimize the distribution. Every analytics tool and every AI agent is connected to the same governed foundation. No copies. No reconciliation meetings. No divergent metric definitions discovered mid-quarter.
This is the only architecture that makes production AI work.
Architecture Decisions Compound
The decisions organizations make about analytics infrastructure tend to compound. Architectures built around replication introduce duplicated storage, fragmented governance, metric inconsistency, and, as AI enters the stack, unpredictable agent behavior and escalating compute costs.
Architectures built around a semantic layer do the opposite. They compound leverage: live connectivity to governed data, consistent metrics across every tool and agent, performance without data movement, and the organizational flexibility to change platforms without rebuilding downstream logic.
Modern BI and AI start with keeping the warehouse as the system of record and routing everything through a governed semantic layer.
If you’re curious how it works in practice, register for our webinar: “The Enterprise Alternative to Fabric: Scale Power BI and Excel Directly on Snowflake.”
SHARE
Guide: How to Choose a Semantic Layer