Data Gravity
Data attracts applications, services, and more data — and the bigger it gets, the harder it is to move.
“As Data accumulates (builds mass) there is a greater likelihood that additional Services and Applications will be attracted to this data.”
To an executive
The more data you accumulate in one place, the costlier and riskier it is to leave. Where data sits shapes supplier lock-in, running costs and migration plans.
To an engineer
Place compute close to the data it uses. Account for bandwidth, egress fees and residency rules when choosing regions or planning migrations, since moving large data is slow.
The idea
Dave McCrory coined the term in a 2010 blog post. He treated data as if it had mass: as it accumulates, it pulls applications and services towards it, and the larger it gets, the stronger the pull. At enough scale, it becomes very hard to move at all.
The forces are practical. Latency and throughput favour compute that sits close to the data. Bandwidth and egress fees make moving large volumes slow and expensive. Regulation and residency rules can forbid moving it at all. So compute moves to the data, and new data lands where the old data already is.
Data gravity quietly drives cloud region choice, vendor lock-in, and the success or failure of migrations.
Why it works
Proximity is cheaper. Applications near their data are faster and cost less to run, so teams keep building them there.
Gravity compounds. Every new service built next to the data adds more data and more dependencies, which makes the whole mass harder to move.
Moving data is the slow part. Code can be redeployed in minutes; copying, validating and cutting over large datasets takes weeks or months.
Where it applies
- Cloud migrations, where the data warehouse or core database decides what can move and when.
- Multi-cloud and hybrid strategies, where egress fees and latency between providers shape what is practical.
- Vendor selection, where a platform that holds your data becomes hard to leave.
- Analytics and machine learning platforms, which are usually best placed next to the largest datasets.
How to apply
- Map the data mass. Know where your largest and fastest-growing datasets live, and what depends on them.
- Decide data placement first. Choose where the data will sit, then place compute near it.
- Price the movement. Include egress, replication, residency checks and cutover time in migration and multi-cloud plans.
- Treat data migration as the critical path. Plan it, test it and rehearse it before moving the applications that depend on it.
Example scenario
An enterprise moved its applications to the cloud but left its large data warehouse on-premises, planning to move it later. Every analytic query now crossed the network link between the two. Reports slowed down, egress bills grew month after month, and several teams quietly copied subsets of data into the cloud, creating inconsistent versions.
The architects reversed the order. They moved the warehouse first, with a tested replication and cutover plan, and then brought the remaining analytic applications alongside it. Query times recovered, egress costs fell, and the unofficial copies could be retired.
Questions to ask
- Where does this data live today, and where will most of its growth happen?
- What would it cost — in latency, egress fees and compliance work — to move it?
- Is this plan moving compute towards the data, or fighting its gravity?
When not to use it
- Small or easily recreated datasets, where moving the data is quick and cheap.
- Stateless workloads, which can run anywhere and simply call the data they need.
How it misleads you
Using data gravity to justify never modernising. Gravity makes migration harder, not impossible: plan for it, phase it and rehearse it. The opposite mistake is ignoring it entirely and moving applications first, leaving them stranded on the wrong side of a slow, expensive link.
In the wild
Further reading
Last reviewed · Suggest an improvement