Glossary
Data locality
Data locality is storing data physically or logically close to the applications, compute or users that need it, so that it travels a shorter distance. Placing data nearby reduces latency and network transfer, which keeps expensive processors working instead of waiting.
Why does distance cost time?
Every read crosses some path: a bus, a network switch, a link between buildings, or the internet. Each hop adds delay and consumes bandwidth. For a job that reads a small amount of data once, the delay is irrelevant. For a training run or analytics query that reads the same terabytes repeatedly, the delay accumulates and processors spend time waiting for data, not calculating. Locality shortens the path so the reads finish sooner.
Forms of locality
| Level | What sits close | Typical benefit |
|---|---|---|
| Same node | Data on drives inside the server that processes it | Lowest latency, no network hop |
| Same rack or site | Storage servers reached over a fast local network | High throughput without WAN traffic |
| Same region | Storage in the cloud region where compute runs | Avoids cross-region transfer charges |
| Edge | Copies near users or devices | Short response times for local readers |
Which level applies depends on the workload. A shared pool reached over a fast network gives most clusters locality without binding data to one machine, which is the reasoning behind low-latency designs for AI storage.
Where does locality go too far?
Pushing data as close to compute as possible has a cost. If every copy lives on the same machines as the processing, one rack, one power failure or one site problem removes both. The data is then in a single failure domain, and the latency gain came from giving up the spread that protects it.
The working rule is to keep the hot working set close and the durable copy spread. A cache or local replica serves the active data quickly, while the authoritative copy is distributed across independent failure domains, as described under data durability. Hot data tiered onto fast media near compute, per storage tiering, and the rest held in the wider pool, gives most of the speed with none of the exposure.
Locality and movement
Locality is often the practical answer to data gravity. When a dataset is too large to move, placing the compute next to it achieves the same effect. The cost shows up when workloads change and the compute needs to go somewhere else, so locality choices tend to be revisited as projects shift.
Frequently asked questions
Is data locality the same as data residency?
No. Locality is about performance and transfer cost. Residency is a legal requirement that data stay within a given country or jurisdiction. The two can coincide but have different drivers.
How is locality measured?
By its effect: read latency, throughput and the share of reads served from local copies. Teams track cache hit rates and cross-site traffic to see whether placement is working.
Does locality still matter on fast networks?
Yes, for repeated and latency-sensitive reads. Faster networks narrow the gap but do not remove it, and the cost of cross-region or cross-cloud transfer remains.
Related terms
- Data gravity: Why large datasets pull compute toward them.
- Storage tiering: Putting hot data on fast media near compute.
- Storage latency: The delay that locality is meant to cut.
- Flash cache: A nearby fast copy of active data.
- Data durability: Why the durable copy stays spread out.