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

Amna ManzoorPosted on January 29, 2026

12-13 Min Read TimeAdd as preferred on Google

Most enterprises are not “in one place” anymore. 70% of organizations run a hybrid cloud, and the average enterprise uses 2.4 public cloud providers. That is why data naturally ends up spread across environments, even when nobody planned it that way.

At first, that distribution feels manageable. Teams copy data for reporting, move it during migrations, and stitch systems together as needs change. But once those datasets become large and business-critical, the rules change. Moving data stops being a routine engineering task and turns into something expensive, latency-sensitive, and full of governance constraints.

That shift is where data gravity shows up. As data grows, it becomes harder to move. Over time, it starts pulling applications, services, and compute toward where the data already lives. This quietly reshapes architecture decisions, cloud economics, and how easy it is to switch platforms without pain.

This blog breaks down what data gravity looks like in enterprise environments, why leaders take it seriously, where others push back, and what it should mean for storage choices, data movement, and lakehouse strategy.

The goal is not to prove that data gravity is always right or always wrong. The goal is to understand when it meaningfully shapes decisions, when it creates blind spots, and how leaders should design systems that work with it rather than react to it later.

What Data Gravity Is and Why It Matters

Data gravity is a pattern many enterprises notice over and over again. The larger and more important a dataset becomes, the harder it is to move. In other words, data has a kind of inertia and naturally influences where systems and workloads end up running.

In the real world, this is more than a concept. What might have once been a simple weekend migration can turn into a complex project with higher costs, multiple approvals, and careful coordination across teams. The challenge grows when data is spread across different sources, stored in varying formats, or limited by compliance and residency rules.

Some experts highlight that this effect cannot be ignored. Tony Bishop, Senior Vice President at Digital Realty, points out that failing to account for data gravity can slow decision-making, raise costs, and limit innovation. He suggests planning for it early so teams understand the constraints and systems can stand the test of time.

Chris Sharp, Chief Technology Officer at Digital Realty, adds that many enterprises are still learning how data gravity affects innovation and profitability. Accounting for it helps systems stay adaptable as demand grows.

These insights make it clear that large datasets are not just technical details but important forces that influence architecture, cost, and agility.

At the same time, data gravity is not the whole story. With thoughtful architecture, hybrid deployments, and strong governance, organizations can remain flexible even as data grows. The real question is how much weight to give data location compared to other design priorities. Leaders need to be aware of data gravity while making careful choices about when to move, replicate, or anchor data so systems stay efficient and adaptable.

Why Data Gravity Shapes Storage Strategy

Storage strategy used to feel like a backend decision. That is no longer true. As datasets become large, heavily used, and business-critical, moving them becomes slow, expensive, and disruptive. At that point, storage stops being “where files live” and becomes the anchor point for analytics, AI, and operational workloads.

That means storage decisions cannot be made in isolation. Leaders have to think through where data will live, how it will grow, how it will be accessed, and how close it needs to be to compute and analytics engines.

As data accumulates, it starts to shape system behavior. Workloads move toward the data because moving the data is harder. Instead of treating storage as a supporting component, many leaders now treat it as the entry point to the whole data platform. This is especially true in environments where data volumes can reach petabytes and beyond.

Eric Hanselman, Principal Analyst, 451 Research, explains that “data growth in hard-to-access locations can trap enterprises into spending large sums to free it.” Rob Thomas, Senior Vice President, IBM, frames the goal as “writing data once and accessing it wherever it is,” which points to a different mindset. Optimize for access and locality, not constant relocation.

A serious storage strategy is not only about cheap tiers. It considers what will consume the data (analytics, AI, transactions), what performance those workloads need, what it costs to move or replicate data, and what compliance rules restrict movement.

When storage is treated as an afterthought, inefficiencies pile up. Cloud costs can rise unexpectedly. Analytics can slow down. Real-time use cases get delayed or dropped. A stronger strategy assumes something important: as data grows, it tends to stay put and attract compute. When storage is planned with that reality in mind, it becomes easier to align cost, performance, and business value without constantly fighting the system.

Rethinking Data Movement

Data movement used to be treated as routine. Engineers moved data for reporting, integration, migrations, and analytics, and early cloud projects often assumed moving data was easy. In modern enterprise environments, it is rarely easy.

Three factors make traditional movement practices fall short:

Rising Cost of Data Movement
Cloud providers charge for data leaving storage systems. Egress charges can add up quickly, especially when large datasets move often. Many teams only notice how large this is after the bill arrives.
Latency and Performance Penalties
Moving large data across regions or between clouds adds delay. That delay can break real-time analytics and weaken AI workloads. Many AI systems read the same data repeatedly, and they are sensitive to latency.
Complexity of Governance and Compliance
Every movement crosses a boundary. That increases work for access control, protection, and lineage tracking. In regulated industries, certain data movement may not be allowed at all.

Because of these constraints, a common strategy is to keep data in place and bring compute to it. Instead of dragging data across systems, enterprises align workloads with where the data already lives.

Techniques that support this include federated query models, pushdown processing, and hybrid or edge deployments. The principle is simple: reduce data motion and increase compute locality. Done well, this lowers cost, improves performance, and reduces compliance surprises. That sets up the next question: how lakehouse strategy fits into this reality?

Lakehouse Strategy Must Align with Value

Modern Lakehouses combine data lake and warehouse capabilities in a single platform that can support many workloads. Enterprises adopting lakehouses need to focus on what the platform delivers, not the label.

The value of a lakehouse comes from consolidation and reuse. It can reduce duplicate storage, allow multiple engines to query the same data, provide integrated governance, and support both analytics and machine learning workloads. To keep the strategy grounded, leaders should tie decisions to outcomes like faster insights, lower cost, and better agility.

A successful lakehouse strategy embodies:

Shared Governance and Security
Embedded access controls, auditing, lineage tracking, and quality monitoring help governance scale as data grows.
Efficient Access Without Replication
Multiple compute engines can run against the same storage, reducing unnecessary copies and cost.
Support for Real-Time and Streaming Workloads
Continuous ingestion and event processing reduce reliance on slow batch ETL pipelines.
Hybrid and Multi-Cloud Flexibility
Support for on-premises, edge, and cloud deployments reduces lock-in and improves performance where it matters.

When these principles guide deployment, lakehouses fit naturally into a data gravity world. Storage stays anchored, movement is minimized, and the lakehouse becomes the governed layer that helps turn data into business outcomes.

Balancing Data Gravity and Architecture Flexibility

Enterprise data strategy must balance two important realities. Large datasets create a strong pull. Experts like Tony Bishop and Chris Sharp point out that ignoring where data lives can increase cloud costs, slow down analytics, and make systems fragile. A. William Stein adds that early placement decisions shape long-term efficiency and innovation, making data location a strategic concern.

At the same time, data gravity is not the only factor. Hybrid cloud, edge computing, and careful platform design can reduce these constraints. David Linthicum and Chris Tabb emphasize that using hybrid deployments, strong data modeling, and good governance can keep enterprises agile without forcing all data to follow a single pattern.

The question leaders face is how to balance these forces. Treating data gravity as real helps plan for performance and cost, while designing for flexibility ensures systems can adapt over time. The best approach is to place high-value data where it matters most while maintaining a hybrid design, clear governance, and architectures that can evolve without creating chaos.

Making Storage, Movement, and Lakehouse Work Together

Enterprise data platforms work best when storage, movement, and lakehouse strategy are designed as one system.

Strategic storage placement ensures high-value data is located where it delivers maximum business benefit.
Optimized data movement keeps compute close to data, reduces latency, and avoids unnecessary cloud egress or replication.
Lakehouse platforms that deliver value allow multiple engines to query the same data, support real-time analytics, and embed governance and lineage controls.

When these three pieces are designed together, enterprises can reduce cost, improve analytics performance, and scale AI effectively.

How to Rethink Storage, Movement, and Lakehouse in 2026: A Practical Playbook

This is the part most teams miss: storage, movement, and lakehouse are not three separate projects. They are one system. If one piece is “freewheeled,” the other two will get expensive.

Step 1: Start with 8 simple questions

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

Where must this data legally live?
How fast do people and systems need it?
Who uses it most?
How often does it move today, and why?
What is the biggest cost risk?
What is the biggest risk?
What breaks when data is late or wrong?
Can teams find and trust the data today?

If you cannot answer these, you are not ready for a “lakehouse strategy.” You are still in data hygiene mode.

Step 2: Pick the right default for data movement

Most enterprises end up using one of these three moves. Choose based on the questions above.

Option A: Keep data in place, 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

Option B: Replicate a small, useful 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, not raw everything.

Option C: Move the data only when the reason 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.

Step 3: Make storage decisions like an operating decision, not a backend choice

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 cheaper and simpler, but still governed.

Step 4: Choose a lakehouse approach that matches how the company works

A lakehouse is useful when it reduces duplication and makes governed reuse easy. But the “right” setup depends on how centralized your org is.

Pattern 1: One main lakehouse, 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

Pattern 2: 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

Pattern 3: 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

Step 5: Avoid these 3 common mistakes

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

As enterprises work to reduce unnecessary data movement and maintain governance, they also face similar challenges in scaling AI responsibly; understanding how structured platforms bring clarity to complex AI workflows can provide practical insights for aligning data strategy with AI initiatives.

If you are also trying to scale analytics and AI, this is the same problem in another form. Models and dashboards do not fail first. The data foundation fails first. Data gravity makes that foundation harder to change after the fact, which is why getting storage, movement, and governance right upfront matters.

Key Takeaway for Enterprise Leaders

CIOs, CTOs, and Chief Data Officers need a simple mental model, which is that data gravity is not a trend. It is what happens when distributed data becomes large, valuable, and heavily used. Once that happens, “we can always move it later” becomes an expensive assumption.

The goal is not to fight gravity. The goal is to design with it. That means three things:

Treat storage placement as a strategic decision. Put high-value datasets where the workloads that depend on them can run with the least friction, cost, and risk.
Minimize unnecessary data movement. Move compute to data whenever possible, replicate only curated slices when it clearly pays off, and migrate large datasets only when the destination is the permanent home.
Make the lakehouse earn its keep. A lakehouse strategy is not a label. It is a commitment to governed reuse: shared controls, shared definitions, and multiple engines working off the same trusted data without turning duplication into your default.

If you get those fundamentals right, you do not just reduce cloud bills and migration drama. You give the business a data platform that can keep up with change, without breaking every time the data gets bigger, more regulated, or more widely used.

If you are building or modernizing on Databricks, Arbisoft can help you turn this into an execution plan. As a Databricks partner, we help enterprise teams assess where data should stay anchored, where compute should run, what should replicate versus migrate, and how to implement governance (catalog, access control, lineage, and quality checks) so the lakehouse scales without turning into a bigger mess. Connect with our experts today.