Egress and data gravity

When should data travel and when should the answer, and where does gravity really come from?

Egress → gravity: does the answer travel, or does the data travel?

The decision is whether to copy the data to where the compute is, or to federate (query it where it lives and move only the answer).

• Copying costs bytes × egress once, plus storage forever, plus a permanent consistency liability (the copy can become out of date).
• Federating costs (intermediate-result bytes × query frequency), plus latency, plus whatever the remote engine refuses to push down (run near the data). The last term decides most real cases. A federation that cannot push down the filter transfers the whole table on every query.

Rough rule: copy wins when the total result bytes across the planning horizon exceed the source bytes. Federate wins for rare, highly selective access.

Gravity comes from asymmetry, not from the rate

Ingress is free and egress is charged, so the equilibrium is accumulation: data goes in and stays, and compute has to come to the data. Bandwidth physics would be satisfied by symmetric pricing. The asymmetry is chosen. It is an economic statement dressed as a physical one.

A correction to a common claim. "Egress is why you cannot leave the cloud" is out of date. Exit egress fees were waived by the major vendors in 2024 under regulatory pressure. The lock-in that remains is operational and format-level (your tools, your table formats, your skills). That is a better-founded lock-in, because it does not depend on anyone's price list.