Data Gravity Is Back: How Enterprises Should Rethink Storage, Movement, and Lakehouse Strategy

Amna ManzoorLast Updated on November 4, 2026

11-12 Min Read TimeAdd as preferred on Google

Key Takeaways

Enterprises should keep large datasets in place and bring compute to them, replicating only curated slices and migrating only when a move is permanent.

• Data gravity makes large, heavily used datasets harder to move as they grow, and where a dataset lives shapes architecture and cost for years.
• Flexera's 2026 State of the Cloud Report (March 2026) found 73% of organizations combine public and private cloud and 88% use more than one provider.
• Moving data at enterprise scale adds transfer fees and latency, plus governance work at every system or region boundary.
• A lakehouse earns its place by cutting copies and easing governed reuse.
• Without a catalog, ownership, access control and quality checks, a lakehouse is just a bigger mess.
• Residency rules, latency targets and team structure can outweigh data gravity, making a regional or domain-based lakehouse the better choice.

Run our eight questions on your three most-used datasets to see where cost and risk are building.

Flexera's 2026 State of the Cloud Report (March 2026) found that 73% of organizations combine public and private cloud, three points more than a year earlier, and 88% use more than one cloud provider.

Data ends up scattered across all of those environments. Once a dataset grows large and the business starts depending on it, shifting it becomes expensive and slow, and every transfer gets tied up in governance approvals. Applications and compute end up running next to the data instead. That pull is data gravity.

Data should stay where it is by default. The exceptions are narrow. Replicate only the curated slices other regions or teams actually need, and migrate a dataset only when the move is permanent and nobody expects to ship it back next quarter. This article helps you decide where storage should sit, when moving data actually pays off, and how three lakehouse patterns hold up against the way companies are organized.

What Data Gravity Is and Why It Matters

Data gravity is the tendency of large, heavily used datasets to become harder to move as they grow, which pulls applications, services and compute toward where the data already lives. The bigger and more important the dataset, the stronger that pull.

In practice, a migration that once took a weekend can turn into a project of its own. Costs climb. Every step needs approval rounds and coordination between teams, and it gets messier still when the data comes from different sources in different formats, or when compliance and residency rules apply to it.

Tony Bishop, then SVP of Platform, Growth and Marketing at Digital Realty, warned in the company's 2020 Data Gravity Index materials that unchecked data gravity can limit innovation and push costs up. He tied it to slow decision-making as well.

Where a large dataset lives decides which platforms can use it cheaply and quickly. That placement then shapes architecture and cost decisions for years.

Still, gravity is one factor among several. Hybrid deployment and clear governance can offset some of the pull. The harder call is how much weight data location deserves against latency and residency rules, and against the way teams are organized. Leaders need to know where gravity is building and treat every move or copy of a large dataset as a deliberate choice.

Why Data Gravity Shapes Storage Strategy

Once datasets become large and business-critical, storage stops being a backend choice. It becomes the anchor that analytics, AI, reporting and operational workloads have to be built around, because relocating the data later is slow and expensive, and the bill lands on every team downstream. A move means downtime, too. Then every system that reads the data needs re-testing.

That changes how storage gets planned. Leaders have to decide where data will live, how it will grow, how people and systems will reach it, and how close it needs to sit to compute and analytics engines. Workloads drift toward the data because shifting the data is harder. Petabyte volumes show this most clearly.

An analyst quoted in Digital Realty's 2020 Data Gravity Index release warned that when data grows in clouds an enterprise cannot easily access, the enterprise "will be trapped into spending exorbitant sums to free it." The better design choice optimizes for access and locality and stops relocating data again and again.

A storage strategy starts with whoever consumes the data, whether that's analytics and AI or transactional systems, and the performance those workloads need. It also counts what it costs to move or replicate data and checks which compliance rules restrict movement. Cheap storage tiers matter. They're one input among these.

Late storage planning gets expensive. Cloud bills climb, and real-time use cases get delayed or dropped because the data they need sits in the wrong region or on the wrong platform. A better plan assumes growing data tends to stay put and attract compute. That assumption makes it far easier to match cost and performance to business value.

Why Is Data Movement So Costly at Enterprise Scale?

Moving large datasets costs money in transfer fees and slows down the workloads waiting on them, and each crossing of a system or region boundary creates governance work on top of that. Early cloud projects often treated movement as easy, as if a few terabytes were just a bigger email attachment. At enterprise scale it rarely is.

1. Transfer fees add up. AWS's Amazon S3 pricing page, as of October 2026, says customers pay for all bandwidth into and out of S3, with listed exceptions, and AWS gives customers 100 GB of free data transfer out to the internet each month. Those allowances are small next to enterprise volumes, and datasets that move often can produce large monthly charges. Plenty of organizations only notice how big these charges are after the bill arrives.
2. Distance adds delay. Moving large data across regions or between clouds adds latency that can break real-time analytics and slow AI workloads, many of which read the same data repeatedly.
3. Every move crosses a boundary. On the other side, someone has to handle access control and data protection and keep lineage tracking intact. Under EU rules, transfers of personal data outside the European Economic Area require special safeguards. In regulated industries, some data movement may be restricted or need extra approval before it can happen.

Because of these constraints, the common fix is to bring compute to the data. Workloads run where the data already lives, and data crosses systems only when there is a clear reason, which keeps the transfer bill and the governance paperwork from growing every time someone launches a new workload.

Federated query models, pushdown processing and hybrid or edge deployments all support this approach by cutting how far data travels and running compute closer to where it is stored. Done well, this lowers transfer costs. Fewer moves also mean faster queries and fewer compliance surprises, and lakehouse strategy has to work within these same limits.

How Should a Lakehouse Strategy Fit a Data Gravity World?

A lakehouse earns its place by reducing copies and making governed reuse of anchored data easy. Modern lakehouses combine data lake and warehouse capabilities in one platform. That lets several engines query the same stored data for analytics and machine learning, and no team has to keep its own copy. Tie lakehouse decisions to outcomes such as faster insights and lower cost.

What Does a Value-Driven Lakehouse Strategy Include?

• Access controls, auditing, lineage tracking and quality monitoring are built into the platform and scale with the data.
• Multiple compute engines run against the same storage, which cuts unnecessary copies and their cost.
• Continuous ingestion and event processing support real-time and streaming workloads and reduce reliance on slow batch ETL pipelines.
• Deployments that run on-premises or at the edge as well as in the cloud, including hybrid and multi-cloud setups, reduce lock-in and put performance where it matters.

With these in place, storage stays anchored and the lakehouse becomes the governed layer where teams reuse the same trusted data without moving it.

Balancing Data Gravity and Architecture Flexibility

Enterprise data strategy has to hold two things at once. Large datasets do create a strong pull, and Digital Realty's 2020 warning about rising costs and slower decisions applies to any team that ignores where its data lives.

Gravity still leaves room for choice, though. Hybrid deployment and good data modeling can loosen its constraints, and so can governance, which means not every dataset has to follow the same pattern or sit in the same place.

Taking data gravity seriously helps teams plan for performance and cost. Designing for flexibility lets systems adapt over time. In practice, that means placing high-value data where it matters most and keeping a hybrid design with clear governance, so the architecture can evolve without turning into chaos.

How to Plan Storage, Movement and Lakehouse Decisions Together

Storage, movement and lakehouse decisions belong to one system. Enterprise data platforms get expensive when any of them is planned in isolation.

Start With Eight Questions About Your Data

Use these to choose a direction before buying tools or launching migrations.

1. Where must this data legally live?
2. How fast do people and systems need it?
3. Who uses it most?
4. How often does it move today, and why?
5. What is the biggest cost risk if this data moves?
6. What is the biggest compliance or security risk?
7. What breaks when data is late or wrong?
8. Can teams find and trust the data today?

Teams that cannot answer these aren't ready for a "lakehouse strategy" yet. They're still doing data hygiene, and that work comes first.

Pick a Default Data Movement Approach

Most enterprises end up using one of these three moves, and the answers above should decide which.

Keep Data in Place and Bring Compute to It

Use this when:

• Data is large and accessed often
• Residency rules are strict
• Latency matters
• Egress costs are a concern

Common techniques:

• Pushdown processing
• Federated queries for light join cases
• Workloads deployed near the data

Replicate a Small Curated Slice of Data

Use this when:

• Many teams need fast access to different places
• You can define "gold" datasets clearly
• You can afford controlled duplication

Rule of thumb:

• Replicate curated, high-value datasets and leave raw data where it is.

Migrate Data Only When the Move Is Permanent

Use this when:

• A business unit is fully shifting platforms
• The target environment is clearly the long-term home
• You have a clean cutoff plan

Rule of thumb:

• If the reason is temporary, do not migrate petabytes for it.

Treat Storage Placement as an Operating Decision

Storage placement should follow use and risk.

Good storage choices do three things:

• Put high-value data close to the workloads that use it most
• Reduce repeated copying
• Respect compliance boundaries from day one

Simple storage rule:

• If a dataset is used every day by many systems, treat it like core infrastructure.
• If it is used rarely, keep it cheap and simple. It still needs governance.

Which Lakehouse Pattern Fits Your Organization?

The right setup depends on how centralized your organization is. All three patterns below aim at the same thing: fewer copies and easy governed reuse.

One Central Lakehouse for Many Teams

Best when:

• Governance is centralized
• Teams share data often
• You want one place for the core truth

How it works:

• One storage foundation
• Shared catalog, access control, lineage
• Multiple engines query the same data

A Lakehouse per Domain With Shared Rules

Best when:

• Data is owned by business domains
• Teams move fast and need autonomy
• You still want consistent governance

How it works:

• Domain data products
• A shared catalog and common policies
• Clear ownership and definitions

Regional Lakehouses With Controlled Sharing

Best when:

• Residency rules vary by country
• Latency matters across regions
• You need local performance with central oversight

How it works:

• Data stays in-region
• Curated sharing across regions
• Central governance standards, local execution

What Are the Common Lakehouse and Data Movement Mistakes?

1. Copy everything everywhere
   This creates cost explosions and version fights.
2. Federate everything
   Federated queries are great for some cases, but they can become slow and fragile at scale.
3. Call it a lakehouse without governance
   Without a catalog, ownership, access control, and quality checks, you just built a bigger mess.

AI work runs into the same pressure. Scaling it responsibly means cutting unnecessary data movement and keeping governance intact, and for that side of the problem, see our piece on how structured platforms bring clarity to complex AI workflows.

What Should Enterprise Leaders Do Next About Data Gravity?

Default to bringing compute to the data. Replicate only curated gold datasets that several teams or regions need, and migrate a dataset only when the destination is its permanent home. Once a valuable dataset is large and heavily used, "we can always move it later" becomes an expensive assumption.

None of this makes data gravity the only factor. Residency rules, latency targets and how your teams are organized can outweigh it, and when they do, a regional or domain-based lakehouse can be the better choice, even if it means some controlled duplication.

The next step is practical. Run the eight questions from the playbook on your three most-used datasets, then compare the answers with where those datasets are stored, how often they move and who approves each move today. The gaps show where cost and risk are building.

If you are building or modernizing on Databricks, Arbisoft can help you turn this into an execution plan. As a Databricks consulting partner with a team of 25+ certified Databricks experts, we run a data placement and movement assessment that maps where data should stay, where compute should run, what to replicate or migrate, and how to set up governance (catalog, access control, lineage and quality checks) for the lakehouse. Connect with our experts today.