Data Gravity

Data gravity describes the tendency for workloads to locate near the data they use when transfer time, cost, and access latency favor that placement. It is a design observation rather than a law or a guarantee about where work should run.

Moving a small program can be easier than repeatedly moving its large inputs, but the comparison also depends on available compute, service features, security, output size, and operational dependencies.

Three reasons the pull exists

• Transfer takes time. Copy duration depends on data volume and effective throughput. If the source changes during the copy, migration also needs a consistent snapshot or a change-capture and catch-up process. Initial copy and ongoing synchronization have different capacity requirements.
• Transfer costs money, asymmetrically. Moving data out of a provider is generally charged while moving it in is not, so an architecture that reads across a boundary pays repeatedly and the bill grows with usage. The structure of those charges is covered under data transfer cost.
• Distance costs latency on every access. Interactive work and chatty protocols suffer most, since the floor set by distance is paid per round trip rather than per byte — which is why the fundamentals of throughput and latency decide what a remote read costs.

None of the three is absolute, and that matters: gravity is a gradient, not a wall. A small reference table has almost none; an event store with years of history has a great deal.

Where you can watch it happen

The concept earns its keep by explaining four patterns that otherwise look like poor discipline.

• Workloads concentrate near primary data. Repeated large reads can favor local processing, but provider capabilities and other constraints may justify remote computation or maintained replicas.
• A “temporary” copy that becomes a second source of truth. An extract made for one analysis acquires its own consumers, and then its own pipeline, because it is where the data already is.
• Migration stalls at a datastore. Data volume, compatibility, validation, and cutover conditions can make the datastore harder to move than some applications. The relative effort depends on the system.
• Data movement matters to an exit cost. Estimate transfer, synchronization, validation, and parallel operation alongside application and operational changes. None is universally the dominant component.

Designing with it rather than against it

For a job that reads a large dataset, compare executing near the data with transferring inputs to the required compute. Include result transfer, service capabilities, access restrictions, and runtime cost. Local computation is often useful, but it is a choice to measure.

Send filtered or aggregated results when the remote side can compute them correctly and the consumer does not need the full input. Batching can reduce sequential round trips, but adds fill delay and changes failure and retry units. Evaluate those costs against deadlines and consistency requirements.

Decide where a new dataset lands during design. As retained data and its consumers accumulate, changing location can require additional copying, synchronization, validation, and consumer migration. Compare those costs with the available services and constraints, so where does this land is worth asking during design of a new system rather than during its first cost review. The same logic supports stating common placement constraints, such as residency and connectivity, in a landing zone, while leaving workload-level placement to teams within those limits.

Several conditions can reduce the cost of remote work. A small dataset may be cheap to copy. Continuous replication may support local reads on both sides when transfer and apply capacity keep up, lag is acceptable, and recovery and change handling are defined; append-heavy input alone does not guarantee this. A narrow query result reduces transfer only when filtering, pruning, or remote execution avoids moving the larger input. Measure scanned bytes, transferred bytes, and freshness separately.

Two boundaries on the concept. It describes a tendency and is not a justification: data gravity is sometimes offered as a reason not to examine a decision, when the honest version is a measured transfer time and cost. And it says nothing about whether the data may be where it is — data residency is a separate constraint that can override the gradient entirely. How gravity interacts with connectivity, consistency, and availability across environments is worked through in Two Clouds, Twice the Operations.

References:

• Google Cloud Architecture Center, Drivers for hybrid and multicloud architectures
• Google Cloud, Other considerations