TL;DR
“Analytics without data movement” is an architectural approach where your business intelligence (BI) layer queries data where it already lives in your warehouse, lakehouse, or operational database instead of copying raw, granular records into a separate analytics platform or the vendor’s cloud. The most sensitive layer of your data, often called level-zero data (the raw, row-level source of truth), never leaves the source system.
Why it matters. Every copy of raw data you create is a new place it can leak, a new system to govern, and a new jurisdiction it might cross. The traditional “extract everything into the analytics tier first” model quietly expands your attack surface and complicates data residency compliance. The average data breach now costs $4.88 million globally, and cumulative GDPR fines have passed €7.1 billion — so an extra unguarded copy of your customer data is not a small liability.
Key takeaways.
Copying level-zero data into a BI platform creates a second, often less-governed, attack surface.
Query-in-place (zero-copy) analytics sends the query to the data instead of moving the data to the query.
Keeping data in source preserves existing permissions, encryption, and residency boundaries if a user can’t see a row in the source, they can’t see it in analytics.
This is a defensible, technical-buyer message: fewer copies, less leakage surface, simpler compliance.
Who should read this. Security and compliance leaders, data platform owners, and architects who need analytics to be useful and safe — and who are tired of choosing between the two.
Ready to see how it works?
Table of Contents
What “Analytics Without Data Movement” Actually Means
The Hidden Cost of the Traditional BI Copy Model
What Is Level-Zero Data — and Why It’s the Real Risk
How Query-in-Place Analytics Works
Data Residency: The Compliance Case for Keeping Data in Source
Security Benefits: Shrinking the Attack Surface
Architecture Patterns and How to Choose
Implementation: A Practical Migration Path
Real-World Scenarios
Common Mistakes to Avoid
Advanced Insights and Future-Proofing
Frequently Asked Questions
Conclusion
Introduction
Here’s a question most analytics buyers never ask their BI vendor: Where does my raw data physically go the moment I connect you?
For most traditional business intelligence tools, the answer is uncomfortable. To make dashboards fast, the platform ingests your data — it copies granular, row-level records out of your warehouse and into its own analytics engine, its own cache, and frequently its own cloud. You connected a reporting tool. What you actually did was create a second full copy of your most sensitive data in a system your security team may not fully control.
For years this was treated as the unavoidable cost of doing analytics. Fast dashboards required local copies; local copies required data movement; data movement was just how BI worked. But that assumption is now expensive in three different currencies: security risk, compliance exposure, and operational drag.
The regulatory environment has made the stakes concrete. Global enterprises now navigate 120+ data protection regulations across 190+ countries, GDPR penalties can reach €20 million or 4% of global turnover, and the average breach costs nearly $5 million. In that world, every redundant copy of raw customer data is a standing liability — not a convenience.
This article makes the case for a different default: analytics without data movement. We’ll define what level-zero data is and why it’s the part that actually matters, walk through how query-in-place analytics works, and lay out the security, residency, and architectural reasons to keep raw data in its source. By the end you’ll have a clear framework for evaluating any analytics tool through a single lens — does this make another copy of my data, or not?
What “Analytics Without Data Movement” Actually Means
Analytics without data movement is exactly what the name implies: you analyze data without first relocating it. Instead of the data traveling to the analytics engine, the query travels to the data. The raw records stay in their system of record; only the computed result — an aggregate, a chart, a number comes back.
It helps to contrast two mental models.
The traditional model: move data to the query. You build pipelines (ETL/ELT) that extract raw data from source systems, transform it, and load it into a separate analytics store. Your BI tool then queries that copy. The data has physically moved, often multiple times, and now exists in more than one place.
The query-in-place model: move the query to the data. Your analytics layer connects above the data, issues a query directly against the source (or a governed semantic layer over it), and retrieves only the result set. Raw data is read where it lives and is never persisted into a separate analytics platform.
The core idea in one sentence: Don’t bring the data to the question — bring the question to the data.
You’ll encounter several overlapping terms for this approach, and it’s worth knowing how they relate:
Term
What it emphasizes
Zero-copy analytics
No duplicate physical copy of the raw data is created
Query-in-place / query data in place
Computation happens against data in its original location
No data movement BIThe BI tool reads but does not relocate source data
Query federationA single query interface spans multiple distributed sources without consolidating themData residency analyticsAnalytics that respects where data is legally required to stay
These aren’t identical, but they share one governing principle: the authoritative, granular data stays put. That principle is the entire point and the source of every benefit that follows.
The Hidden Cost of the Traditional BI Copy Model
The conventional analytics stack looks reasonable on an architecture diagram. Source systems on the left, pipelines in the middle, a warehouse and BI tool on the right. Clean arrows, left to right. The problem is what those arrows actually represent: every arrow is a copy of your data crossing a boundary.
Consider what a single dashboard often requires under the traditional model:
Raw data extracted from an operational database into a staging area.
Transformed and loaded into a central warehouse.
Extracted again into the BI tool’s own engine or in-memory cache for speed.
Sometimes replicated into the BI vendor’s managed cloud for processing.
That’s potentially four locations holding row-level data, each with its own access model, encryption posture, logging, and — critically — its own breach blast radius. As industry analysts of federated architectures put it, centralizing everything “creates a larger consolidated attack surface through data duplication and movement.”
The costs compound across four dimensions:
Security. Each copy is an independent thing to secure, patch, monitor, and eventually decommission. The BI vendor’s cloud becomes, in effect, an extension of your own data perimeter — but one you don’t operate. As one zero-copy proponent bluntly notes, copying data to the analytics tier “creates yet another point of security failure.”
Compliance. A copy in a different region can silently breach data residency rules. And under regulations like GDPR, your deletion obligations don’t stop at the source — deletion must propagate to “backups, logs, analytics systems, and ML training data.” Every copy you made is now a copy you must prove you erased.
Cost. You pay to store the same data multiple times, pay to run the pipelines that move it, and pay engineers to maintain those pipelines when schemas change.
Freshness. Data that has to be copied is, by definition, stale between syncs. By the time it lands in the warehouse and then the BI cache, “the data is stale by the time it reaches the warehouse.” Decisions get made on yesterday’s numbers.
The uncomfortable summary: the traditional model treats making more copies of sensitive data as the foundation of analytics. Everything downstream the governance burden, the residency headaches, the breach exposure flows from that one starting decision.
What Is Level-Zero Data and Why It’s the Real Risk
Not all data carries equal risk. To understand why “no data movement” matters so much, you have to distinguish between the layers of an analytics stack.
Level-zero data is the raw, granular, row-level source of truth — individual transactions, customer records, line items, event logs. It’s the most detailed and therefore the most sensitive form your data takes. A single level-zero row might contain a named customer, their purchase, their location, and a timestamp. It is precisely the data that regulators care about and attackers want.
Above level zero sit the things analytics actually delivers:
Aggregates -“total revenue by region this quarter.”
Metrics and KPIs – derived numbers, often stripped of personal identifiers.
Visualizations – charts and dashboards that present those aggregates.
Here’s the crucial insight: business users almost never need level-zero data itself. They need answers derived from it. A regional sales leader asking “how did we do last quarter?” needs a number, not a download of every customer transaction.
Yet the traditional BI model copies all of level zero into the analytics tier just so it can compute those aggregates locally. You move the riskiest possible data every raw row in order to produce results that contain almost none of that risk.
The asymmetry that defines the problem: the data that’s dangerous to move (raw level-zero rows) is rarely the data anyone actually wants to see. The data people want (aggregates and answers) is comparatively safe. Analytics without data movement exploits this asymmetry: keep the dangerous layer in source, and let only the safe layer travel.
This is why “keeping level-zero data in source” is not a minor technical preference. It’s a direct reduction of the single largest category of data risk in your analytics pipeline.
How Query-in-Place Analytics Works
If the data isn’t moving, how do you actually get an answer? The mechanics are more straightforward than they sound.
A query-in-place analytics platform sits above the data layer rather than ingesting from it. When a user asks a question, the platform:
Interprets the request and resolves it against a semantic understanding of where the relevant data lives which tables, which sources, which joins.
Generates the correct query (typically SQL) for the underlying source system.
Pushes that query down to the source, where the source’s own engine executes it against level-zero data in place.
Returns only the result set the aggregate, the rows that match, the computed metric to be rendered for the user.
The raw data is read and processed inside the source’s security perimeter. As one federation architecture describes it, queries are “retrieved dynamically and processed in memory without being stored locally,” and “the data never crosses the perimeter.”
Here’s the flow as a diagram:
TRADITIONAL BI (data moves)
┌──────────┐ copy raw ┌──────────┐ copy raw ┌──────────┐
│ Source │ ─────────────▶│Warehouse │ ────────────▶│ BI Engine│
│(level-0) │ rows out │ (level-0)│ rows out │ (level-0)│
└──────────┘ └──────────┘ └────┬─────┘
3+ copies of raw data, 3 attack surfaces │ charts
▼
👤 User
QUERY-IN-PLACE (query moves)
┌──────────┐ ┌─────────────────────┐
│ Source │◀──── query pushed down ──────│ Analytics Layer │
│(level-0) │ │ (sits above data) │
│ stays │───── only results back ─────▶│ │
└──────────┘ (aggregates, not rows) └─────────┬───────────┘
1 copy of raw data, 1 attack surface │ charts
▼
👤 User
A modern natural-language analytics layer adds one more capability on top: it lets users ask questions in plain English, then translates those into the correct query for the source. As Quaeris describes its own approach, an “agentic layer turns natural language into the correct query,” learning the structure of the SQL housing your data so that “if you can think of a question to ask,” the system can answer it directly against your source without that source data ever being copied to the analytics platform or its cloud.
The result is the best of both worlds in principle: the accessibility of self-service BI, without the data-duplication tax that normally comes with it.
Data Residency: The Compliance Case for Keeping Data in Source
Data residency is where “no data movement” stops being an architectural nicety and becomes a compliance necessity.
Data residency refers to the physical or geographic location where data is stored and processed. Data localization is the stricter cousin — a legal requirement that certain data must remain within a specific territory and cannot be transferred outside it at all. Both are enforced with growing seriousness: in 2025, regulators began penalizing organizations “not just for breaches but for improper data transfers or lack of proper localization strategies.”
Now overlay the traditional BI model on this. The moment your analytics tool copies EU customer data into a US-region processing cluster or into the vendor’s globally distributed cloud you may have created a cross-border transfer you never intended. You didn’t change your storage policy; you just connected a dashboard. But the data moved, and movement is exactly what residency law governs.
Query-in-place analytics sidesteps this category of problem structurally. Because raw data never leaves its source:
Data stays in its required jurisdiction. If your EU data is in an EU-region warehouse, queries run there and only aggregated results travel. The level-zero records never cross the border. Running live queries “maintains data residency, sovereignty, and compliance, especially across complex, distributed IT landscapes.”
Deletion obligations shrink. GDPR’s “right to erasure” requires deletion to propagate to every system holding the data, including analytics. If analytics never held a copy, there’s nothing extra to find, delete, and prove deleted.
Audit scope narrows. Fewer copies means fewer systems an auditor has to inspect to confirm where regulated data resides.
The financial stakes make this worth designing for. GDPR penalties reach €20 million or 4% of global turnover, enterprises report $500K+ annual costs just for handling data-subject requests, and a single complex request can consume 40–80 hours of manual work. An architecture that simply doesn’t replicate regulated data into new locations removes whole branches of that workload before it starts.
Compliance reframed: The cheapest data to keep compliant is the copy you never made.
Security Benefits: Shrinking the Attack Surface
Security teams have a useful instinct: the safest data is data that doesn’t exist where it doesn’t need to. Analytics without data movement is a direct application of that instinct.
1. A smaller attack surface. Every copy of level-zero data is a target. Eliminate the analytics-tier copy and you eliminate an entire class of breach scenario the one where attackers exfiltrate raw records from a BI cache, an export, or the vendor’s cloud rather than from your hardened source. Federated, no-movement designs “reduce the attack surface by minimizing data copying.”
2. Existing controls are preserved, not re-implemented. When data stays in source, your existing encryption, network controls, and access policies continue to apply unchanged. You don’t have to rebuild — and keep in sync a parallel security model inside the BI platform. As zero-copy advocates note, the approach keeps data “in its original source… while preserving existing security controls and encryption.”
3. Permission inheritance closes the “shadow access” gap. One of the quiet dangers of copied data is permission drift: a user who can’t see certain rows in the source system can see them in the BI tool because the copy was loaded with broader access. A true query-in-place model inherits source permissions. In Quaeris’s framing: “If a user cannot see the data in the source system, they cannot see it in Quaeris.” That single property keeps security and compliance teams confident that analytics can’t become a backdoor around source-system access controls.
4. Fewer credentials and pipelines to secure. Each ETL pipeline is itself an attack path it holds credentials to your source systems and writes data somewhere new. Removing the need to move data removes those pipelines and the standing credentials they require.
The honest counterpoint, worth stating plainly: federated and query-in-place models introduce their own complexity. Pushing queries across multiple sources means managing “multi-cloud IAM policies” and reconciling “inconsistent security policies across different sources.” No-movement isn’t free of governance work — it relocates that work to the query layer. But it relocates it to a layer you control, against data that never multiplied, which is a far better problem to own than a sprawl of unguarded copies.
Architecture Patterns and How to Choose
“No data movement” is a principle, not a single product. It shows up in several architectural patterns, and choosing well means matching the pattern to your constraints.
PatternHow it worksBest whenWatch out forQuery-in-place / push-downBI layer pushes queries to a single source (warehouse, lakehouse); only results returnYou’ve consolidated into one strong warehouse and want safe BI on topSource must handle analytical query loadQuery federationA virtual layer spans multiple distributed sources in one query, no consolidationData is genuinely siloed across systems/regions and can’t be mergedCross-source joins can be slow; needs governance at query layerZero-copy data sharingSource grants governed read access to a consumer without copying (e.g., warehouse-native sharing)Both sides use compatible platformsTighter platform couplingSemantic / metrics layer over sourceA governed model defines metrics; queries resolve to source at runtimeYou want consistent KPIs without a physical martModeling effort up front
A few decision principles cut through the options:
Start from your residency map. If regulated data must stay in specific regions, any pattern that copies it out is disqualified before you evaluate features. Let compliance constraints filter the field first.
Match the pattern to your data’s distribution. One consolidated warehouse points toward query-in-place push-down. Genuinely scattered sources point toward federation.
Govern at the query layer. Whatever pattern you choose, the place to enforce access, masking, and audit is the layer issuing queries — because that’s the only place all requests pass through when data itself doesn’t move.
Prefer permission inheritance over permission re-creation. A tool that reuses source permissions is structurally safer than one asking you to redefine who-sees-what inside the analytics platform.
Implementation: A Practical Migration Path
Moving from a copy-everything model to analytics without data movement doesn’t have to be a big-bang rewrite. A staged approach lets you prove value and de-risk as you go.
Step 1 – Inventory your copies. Map every place level-zero data currently lands: staging areas, the warehouse, BI caches, vendor clouds, exports, spreadsheets. You can’t reduce copies you can’t see. This inventory alone is often eye-opening for security teams.
Step 2 – Classify data by residency and sensitivity. Tag which datasets are regulated, which are residency-bound, and which are genuinely low-risk. This tells you where no-movement is mandatory versus merely beneficial.
Step 3 – Pick a high-value, high-sensitivity pilot. Choose one dashboard or use case built on sensitive data — ideally one where a stray copy would be a real compliance problem. Re-implement it query-in-place against the source.
Step 4 – Validate permission inheritance. Before trusting the new layer, test the critical property directly: confirm that a user restricted in the source system is equally restricted in analytics. This is the linchpin of the security argument; verify it, don’t assume it.
Step 5 – Measure freshness and performance. Compare query latency and data freshness against the old copied model. Push-down queries hit live data, so freshness usually improves; latency depends on source capacity, so size accordingly.
Step 6 – Decommission the redundant copies. Once the no-movement path is proven, retire the pipelines and caches feeding the old copy — and document the deletion for your auditors. This is where the cost and compliance savings actually land.
Step 7 – Expand and standardize. Roll the pattern out to additional use cases, and make “does this require moving level-zero data?” a standing question in every new analytics request.
Best practice: Treat each retired copy as a security win worth recording. “We eliminated three redundant copies of customer PII” is exactly the kind of sentence that resonates in a board-level risk review.
Real-World Scenarios
Multinational retailer residency by design. A retailer operates in the EU, US, and APAC, each with its own regional data store and its own localization rules. Under a traditional BI model, building a global revenue dashboard meant copying regional sales data into one central cloud a cross-border transfer nightmare. With query-in-place analytics, each regional query runs locally against in-region data; only aggregated revenue figures (which contain no personal data) are combined for the global view. Residency is preserved structurally, not policed after the fact.
Healthcare provider minimizing PHI exposure. Healthcare breaches are the most expensive of any sector, averaging $10.93 million. A provider wants clinical analytics without spreading protected health information into yet another system. By querying patient data in place and surfacing only de-identified aggregates to analysts, the raw PHI never enters the analytics tier shrinking both breach exposure and HIPAA audit scope.
Financial services permission inheritance as a control. A bank’s source systems enforce strict row-level access: a relationship manager sees only their own clients. With copied-data BI, those controls had to be painstakingly re-created in the reporting tool, and drift was a constant audit finding. With permission-inheriting query-in-place analytics, the source rules apply automatically an analyst literally cannot query rows they’re not entitled to see in the source.
SaaS startup analytics without a data-engineering team. An early-stage company wants self-service analytics but has no one to build and babysit ETL pipelines. A natural-language layer that queries the production warehouse in place lets non-technical staff ask questions directly, with no pipelines to maintain and no second copy of customer data to secure a meaningful reduction in both engineering load and risk surface for a small team.
Enterprise data mesh federation across domains. A large enterprise with a data-mesh strategy has dozens of domain-owned data products across clouds. Rather than re-centralizing them (defeating the mesh), a federated query layer spans them in place, enforcing governance at the query layer while each domain retains ownership and residency of its own level-zero data.
Common Mistakes to Avoid
Even teams sold on the concept stumble in predictable ways. Watch for these:
1. “Zero-copy” that quietly caches. Some tools claim no data movement but maintain a hidden extract or aggressive cache of raw rows for performance. If level-zero data is persisted anywhere outside the source, you haven’t actually eliminated the copy — you’ve just hidden it. Ask vendors precisely what is stored, where, and for how long.
2. Re-creating permissions instead of inheriting them. Rebuilding access rules inside the analytics tool reintroduces drift and the shadow-access risk. If the tool can’t inherit source permissions, you’ve kept one of the worst problems of the copy model.
3. Ignoring source query load. Push-down analytics means your source now serves analytical queries on top of its day job. Without read replicas or adequate capacity, you can degrade the very system of record you were protecting. Plan for the load.
4. Treating federation as free. Cross-source federated joins can be slow and can expose inconsistent security policies between systems. No-movement reduces copy risk but demands real governance discipline at the query layer. Don’t mistake “no copies” for “no work.”
5. Forgetting result-set sensitivity. Aggregates are usually safe but not always. A filtered result that returns a single row can be as identifying as raw data. Apply masking and minimum-aggregation thresholds at the query layer, not just at the storage layer.
6. Skipping the deletion-of-old-copies step. Teams adopt query-in-place for new dashboards but never decommission the legacy pipelines and caches. You only realize the security and compliance benefit when the redundant copies are actually gone.
Advanced Insights and Future-Proofing
Analytics is converging with AI and AI raises the stakes on copies. As organizations feed data into LLMs and AI agents, the “where did the raw data go?” question gets sharper, because AI systems are notorious copy-multipliers (training sets, embeddings, vector stores, logs). The same principle applies and matters more: let the AI query layer reason against governed source data in place rather than vacuuming level-zero records into yet another store. Natural-language analytics that generates queries against the source rather than ingesting the source is a preview of how AI and data residency can coexist.
Make “no new copy” an architectural default, not an exception. The most future-proof posture is to invert the old assumption. Instead of “copy data into analytics unless there’s a reason not to,” adopt “never copy level-zero data unless there’s a compelling, documented reason to.” This single default change cascades into simpler compliance, smaller attack surface, and lower cost across every future project.
Govern the query layer like you’d govern a database. When data stops moving, the query layer becomes the chokepoint where all access, masking, and audit must live. Invest there: centralized policy, full query logging, and consistent enforcement across every source. The payoff is that you get one place to govern instead of N copies to chase.
Watch the regulatory trajectory. Data localization rules are tightening, not loosening the count of regional regulations keeps climbing. Architectures that assume free cross-border data movement are accumulating technical and legal debt. No-movement analytics is a hedge against a regulatory future that is clearly heading toward more restriction on where data can go.
Strategic takeaway: The organizations that will move fastest under tightening regulation are the ones that designed their analytics to not move data in the first place. Constraint becomes an advantage when you’ve built for it.
Frequently Asked Questions
What is analytics without data movement?
It’s an analytics architecture where the BI or AI layer queries data in its original source system instead of copying raw records into a separate analytics platform. The query travels to the data; only the computed result (an aggregate or answer) comes back. Raw, level-zero data never leaves the source.
What does “level-zero data” mean?
Level-zero data is the raw, granular, row-level source of truth individual transactions, customer records, event logs. It’s the most detailed and most sensitive form of your data. Most analytics consumers need aggregates derived from it, not the level-zero rows themselves, which is why keeping that layer in source dramatically reduces risk without limiting insight.
How is this different from a traditional data warehouse setup?
A traditional setup copies raw data through pipelines into a warehouse, and often again into a BI tool’s own engine or cloud — creating multiple copies and multiple attack surfaces. Query-in-place analytics reads data where it lives and returns only results, so no additional copy of level-zero data is created.
Is “zero-copy analytics” the same as “no data movement BI”?
They’re closely related and often used interchangeably. Both describe analyzing data without creating a duplicate physical copy of the raw data. “Query federation” is a specific flavor that spans multiple distributed sources in a single query without consolidating them.
Does keeping data in source make analytics slower?
Not necessarily. Push-down queries run on live data, so freshness usually improves over copied models. Latency depends on the source’s capacity to serve analytical queries — which you can address with read replicas or appropriate sizing. The key trade-off is provisioning source compute, not accepting stale data.
How does query-in-place analytics help with data residency and GDPR?
Because raw data never leaves its source region, you avoid unintended cross-border transfers, and regulated data stays in its required jurisdiction. It also shrinks GDPR deletion obligations — there’s no extra analytics copy to find and erase — and narrows audit scope to the systems that actually hold the data.
What is permission inheritance and why does it matter?
Permission inheritance means analytics honors the source system’s access rules: if a user can’t see certain rows in the source, they can’t see them in analytics either. It prevents the “shadow access” problem where a copied dataset exposes data the user was never authorized to see, and it removes the need to rebuild and sync a parallel permission model.
Does no data movement reduce my security risk?
Yes, structurally. Eliminating the analytics-tier copy removes an entire class of breach scenario and preserves your existing encryption and access controls instead of forcing you to re-implement them. It does shift governance work to the query layer, so you must secure that layer well but you’re governing one controlled chokepoint instead of multiple uncontrolled copies.
Can I query data across multiple systems without moving it?
Yes that’s query federation. A federated query layer issues a single query across multiple distributed sources (different databases, clouds, or regions) and combines results without consolidating the underlying data. It’s ideal when data is genuinely siloed and can’t or shouldn’t be merged.
What are the downsides of analytics without data movement?
The main trade-offs are managing query load on source systems, handling cross-source query performance in federated setups, and reconciling security policies across different sources at the query layer. These are real but manageable and generally preferable to maintaining and securing many redundant copies of sensitive data.
How do I evaluate a BI or analytics vendor for this?
Ask one anchoring question: Does connecting you create a copy of my raw data, and if so, where does it live? Then probe specifics does it cache or extract level-zero data, does it inherit source permissions, can it keep data in-region, and what exactly is stored in the vendor’s cloud. The answers reveal whether “no data movement” is real or marketing.
Is this approach suitable for AI and natural-language analytics?
Yes, and it’s arguably more important there. Natural-language and agentic analytics can translate plain-English questions into queries that run against governed source data in place delivering self-service insight without vacuuming raw records into new stores, embeddings, or logs that multiply your exposure.
Conclusion
For most of BI’s history, “move the data first” was an unquestioned default. Fast analytics seemed to require local copies, and local copies required movement. But that default was quietly expensive — it multiplied attack surfaces, complicated residency compliance, inflated storage and pipeline costs, and served users stale numbers.
Analytics without data movement inverts the default. By sending the query to the data instead of the data to the query, you keep level-zero data — the raw, sensitive source of truth — exactly where it already lives, governed by controls you already trust. Users still get their dashboards and answers; what they don’t get is a redundant copy of your most sensitive data sitting in a system you don’t fully control.
The benefits stack cleanly:
Security: a smaller attack surface, preserved encryption and access controls, and permission inheritance that closes the shadow-access gap.
Compliance: structural data residency, smaller deletion obligations, and narrower audit scope.
Cost and freshness: fewer copies to store, fewer pipelines to maintain, and live data instead of stale extracts.
Recommended next steps: inventory where your level-zero data is being copied today, classify it by residency and sensitivity, and re-implement one high-sensitivity dashboard query-in-place as a pilot validating, above all, that source permissions carry through. Then make “does this require moving level-zero data?” a standing question for every new analytics request.
The outlook: as data localization rules tighten and AI multiplies the temptation to copy data everywhere, architectures that simply don’t move sensitive data will hold up best. The cheapest data to secure, and to keep compliant, is the copy you never made. Build your analytics so you never have to make it.
