What is data gravity and where should workloads run?
Data gravity is the observation that applications tend to move towards large accumulations of data rather than the other way round, because moving the data is slower, costlier and more regulated than moving the compute. It is a description of a cost, not a physical law, and treating it as a law leads to a common error: keeping a workload on-premise because the data is there, when the workload reads a tiny slice of that data and could perfectly well run anywhere.
What does data gravity actually mean?
That the larger a body of data becomes, the harder it is to move and the more it pulls related services towards it. Analytics, reporting, machine learning and integrations all end up next to the store because each of them needs to read a great deal of it, and once several services sit there the whole cluster becomes harder to relocate than it was a year ago.
The pull comes from three separate forces that people tend to blend together. Volume makes the transfer slow and, on the way out of a cloud, expensive. Latency makes a chatty workload unusable at distance. Regulation can make the move illegal regardless of how easy it would be technically.
Separating them matters because the remedies differ. A volume problem can be answered with compression, a summary or a nightly extract. A latency problem is answered by moving compute or redesigning the access pattern. A regulatory problem is not answered by engineering at all, and treating it as though it were is how projects get very far before someone in legal reads the design.
How do you tell which side the gravity is on?
Measure two numbers for the workload: how many bytes it reads, and how many bytes it produces. If it reads far more than it emits, the compute belongs next to the data. If it reads a small slice and emits something comparable in size, it can live anywhere and the gravity argument does not apply to it.
A nightly job scanning a large history to produce a small report is the clearest case of high gravity: the read side is enormous and the output is a rounding error, so running that job across a link means shipping the entire history every night to produce a file you could have emailed. A web application fetching a handful of records per request is the opposite, and moving it to the cloud costs almost nothing in transfer.
The ratio also tells you what to build when the answer is inconvenient. If the read side is large but the workload only needs recent data, replicating a rolling window is cheap. If it needs everything, either the compute moves or the design changes, and pretending otherwise produces a system that works in testing on a subset and fails on the real volume.
| Workload | Bytes read | Bytes returned | Where the compute belongs | Escape route |
|---|---|---|---|---|
| Nightly reporting over full history | Very high | Tiny | Next to the data | Pre-aggregate on-premise, ship the summary |
| Model training on historical records | Very high | Small, the model artefact | Next to the data | Train on a sample, or replicate once and keep it in sync |
| Transactional web application | Low per request | Low | Either side | Read replica near the application |
| Document or image processing | High per item, but per item | Similar to input | Wherever the items arrive | Process at the point of capture, store the result centrally |
| Search and lookup services | Low | Low | Near the users | Index in the cloud, source of truth on-premise |
| Real-time control of a physical process | Low | Low | Next to the machinery | None, latency decides it |
Why do analytics and AI projects hit this first?
Because they are the workloads with the most extreme read-to-output ratio, so they are where a distance that nobody noticed becomes the entire cost of the project. Every other system reads what it needs; analytics reads everything.
There is a second reason specific to model work. Training is not a single pass over the data, it is many passes, and any arrangement that streams the training set across a boundary repeats that cost on every epoch and every experiment. The practical result is that teams quietly copy the data to the cloud, which is fine if it was a decision and a problem if it was a workaround nobody recorded.
This is also why analytics is the usual trigger for a serious hybrid conversation. The operational systems were tolerable across the link. The moment someone wants to analyse them together, the placement question can no longer be deferred.
Is keeping a copy in both places a reasonable answer?
Often yes, and it is underused because it feels like a compromise. A read replica in the cloud, fed by change data capture or native replication, gives cloud workloads local reads while the on-premise system remains the source of truth. Reads are the overwhelming majority of most access patterns, so this removes most of the crossing without moving anything that matters.
The conditions to check are the ones that make a copy dangerous rather than merely expensive. How stale is the replica allowed to be before an answer is wrong, and does anyone know? Who is allowed to write, and is that enforced technically rather than by convention? And what happens to the copy in a failover, because a replica promoted by accident during an incident is how two divergent sources of truth are created.
Cost is the easy part of this decision and the part people over-weight. Storage is cheap in both places. The expensive parts are the operational discipline to keep the copy honest and the incident where someone read a stale figure and acted on it.
When is the gravity worth fighting?
When the data is growing where it should not be, and every month of delay makes the move harder. A store accumulating on hardware you intend to retire is a bill that compounds, and the cheapest moment to relocate it is always now rather than after another year of growth.
It is also worth fighting when the gravity is an accident of history rather than a requirement. Plenty of large stores exist where they do because that is where the first application ran, and nothing about them is bound to the location. The test is whether anyone can name a constraint that is not habit: a regulator, a physical process, a licence or a piece of hardware.
It is not worth fighting when the constraint is real and permanent. In that case the correct move is to stop trying to relocate the data and instead reduce what needs to cross: aggregate on-premise, expose a coarse API rather than raw records, and keep the fine-grained work on the side where the bytes live.
What should you check before placing a workload?
Four things, all answerable from existing monitoring in an afternoon. How many bytes per day does this workload read, and how many does it produce? How many separate calls does it make per unit of work? Does it need current data or is a lag of minutes acceptable? And is there any legal or contractual reason the data cannot be copied?
The second question catches more problems than the first. A workload reading a modest total volume in a very large number of small calls suffers from distance far more than one reading a large volume in a few sequential passes, and the two look identical on a bandwidth graph.
Write the answers down next to each candidate workload before the placement discussion, not during it. Placement arguments that run long are almost always arguments between people holding different assumptions about these four numbers, and the numbers are usually available.
Common questions
- What is data gravity?
- The tendency for applications and services to accumulate around large bodies of data, because moving the data is slower, costlier and more constrained than moving the compute. It is a description of cost rather than a physical law. Three separate forces produce it: sheer volume, latency for chatty access patterns, and regulation that may forbid the move entirely regardless of technical feasibility.
- How do you decide whether a workload should run on-premise or in the cloud?
- Compare bytes read against bytes produced. A workload that reads far more than it emits, such as a nightly report over a full history, belongs next to the data. A workload reading a small slice per request can run anywhere. Then check the number of separate calls per unit of work, because many small calls suffer from distance far more than a few large sequential reads of the same total volume.
- Why do AI and analytics projects trigger hybrid cloud decisions?
- They have the most extreme ratio of data read to output produced, so a distance that operational systems tolerated becomes the dominant cost. Model training compounds it, since training makes many passes over the data rather than one, and any design streaming the training set across a boundary repeats that cost on every epoch and every experiment.
- Is it acceptable to keep the same data in both on-premise and cloud?
- Frequently yes. A read replica in the cloud fed by change data capture or native replication gives cloud workloads local reads while the on-premise system stays the source of truth, and since reads dominate most access patterns this removes most of the crossing. The risks are operational rather than financial: define how stale the copy may be, enforce which side may write, and make sure a failover cannot promote the replica by accident.
- When should you move data to the cloud despite data gravity?
- When the store is growing on infrastructure you intend to retire, since every month of delay makes the move larger, and when the location is an accident of history rather than a requirement. The test is whether anyone can name a constraint that is not habit: a regulator, a physical process, a licence tied to hardware, or capital equipment with remaining book value. If nobody can, the gravity is not real.
