Lock-in through data does not concern the data itself, but what it attracts; making the data alone reversible leaves the structure that retains it intact.

McCrory (2010) establishes the direction of movement: past a certain volume, compute migrates toward the data. His model does not, however, formalize what happens when that compute operates continuously on a stream rather than on a stock queried periodically. This volume proposes to update data gravity for real-time pipeline constraints through the notion of kinetic inertia: the operational mass of a dataset is no longer measured only by its stored volume, but by the latency break that moving away the compute processing it continuously would cause. This is not a direct consequence of McCrory's original model, but an extension proposed here to account for streaming and near-real-time processing architectures that have emerged since 2010.

Snowflake's historical proprietary format (micro-partitions) long made data unreadable outside the platform. The recent adoption of the open Apache Iceberg format mitigates this constraint without removing it: catalogs remain, in many configurations, managed by Snowflake, and exit costs apply as soon as processing runs elsewhere. The native ecosystem — Marketplace, native applications, identity resolution executed in place — materializes gravity in action: it is compute and third-party services that come to the data, not the reverse.

Databricks counters the lock-in accusation with an argument of openness by design: Delta Lake open source from inception, Unity Catalog itself open-sourced, claimed interoperability with Iceberg and Parquet formats. This argument addresses the right layer but not the right question. Gravity no longer resides in the file extension — that is indeed open — but in the centralization of the governance plane: a single metastore, a single lineage system, access policies defined once for all uses. Leaving the platform leaves the file accessible; it restores neither the lineage graph nor the governance structure that governed its access, which must be entirely rebuilt elsewhere. An open format at the file level does not imply an open center of gravity at the organizational level.

BigQuery's native integration with Vertex AI and Looker enables model training and execution directly in SQL, without prior data export. BigQuery Omni allows querying data located outside Google Cloud, but orchestration of this service remains driven from Google Cloud. The gap is not merely contractual: at 2026 standard rates, internet egress billed by Google Cloud ranges from 0.08 to 0.12 dollars per gigabyte depending on volume tier, and up to 0.23 dollars per gigabyte for intercontinental transit — an order of magnitude of 80,000 to over 200,000 dollars for a petabyte exported. In-place processing, within the same region, on a native Google service via Private Google Access, incurs by comparison no exit fee at all. Transfer time reinforces this finding: at a sustained 10 Gbit/s, moving a petabyte takes on the order of nine days of continuous transfer — a theoretical physical floor, computed without degradation, contention, or interruption, and therefore a lower bound, not an observed average. That this theoretical floor already reaches the scale of a week is enough, by itself, to ruin the operational viability of any external pipeline built on this dataset: no realistic improvement in transfer conditions will bring this delay down to the millisecond scale that in-place processing requires. The resulting lock-in is then no longer a reversible pricing policy, but a consequence of the physics of transfer itself. Vertex AI and Looker are therefore structurally incentivized to operate on data already resident in BigQuery not by contractual choice, but because the cost and time of any other scenario are measurable and prohibitive at the petabyte scale.

The switching-cost mechanism formalized by Klemperer (1987) rested, in its most directly quantifiable component, on the incumbent provider's ability to charge for exit itself — the network extraction tax documented in I.2 for Snowflake, Databricks, and BigQuery. Article 29 neutralizes precisely this component: from 12 January 2027, no platform will be able to oppose an order of magnitude of 80,000 to over 200,000 dollars per petabyte exported to deter a change of provider. On this specific tariff dimension, the regulatory shield works.

Chapter I.2 established, for Databricks, that gravity no longer resides in the file format — already open — but in the centralization of the governance plane: a single metastore, a single lineage system. For BigQuery, gravity stems from native integration with Vertex AI and Looker. Neither the metastore and lineage graph of a governance catalog, nor the machine learning models trained on the data in place, nor the dashboards and pipelines built on this native integration fall within the "base service" that Article 30 requires to be made functionally equivalent elsewhere. The exit-fee freedom obtained through Article 29 applies to data transport; it does not extend to rebuilding what has been aggregated around it.

The mechanism documented in I.1 assumes mass accumulated at a single point. The first architectural response consists of preventing such a single point from forming: distributing the data estate along business-domain boundaries rather than consolidating it in a single analytical warehouse, so that no subset alone crosses the critical volume that triggers the gravitational dynamic.

Each domain's data is stored in an open table format, directly queryable by any compatible compute engine, without prior duplication into a given platform's proprietary format. Chapter I.2 established, for Databricks, that opening the file format alone is not enough to remove gravity if the governance catalog — metastore, lineage, access control — remains hosted and operated by a single vendor. This proposal therefore holds that the governance layer itself must be hostable independently of any single vendor, failing which decoupling at the file level merely shifts gravity one layer up, without removing it — exactly the mechanism documented in I.2.

Fragmenting data by domain degrades cross-domain queries: a join spanning several domains requires traversing multiple catalogs rather than a single instantaneous source of truth, at a latency and engineering cost unknown to a consolidated warehouse. Decoupling compute from data also deprives the organization of proprietary optimizations — advanced indexing, integrated caching, native acceleration — that a single vendor can offer precisely because it controls the entire stack. Each domain must finally maintain its own integration and governance effort, duplicating work that a centralized platform would pool.

Chapter I established that accumulated data exerts a physical and economic attraction on the compute and services surrounding it, independent of any clause addressing the data alone. Chapter II established that the European Data Act genuinely neutralizes the tariff component of this mechanism, but leaves outside its scope the governance, metastore, and model layer aggregated on top of the base service. Chapter III responds specifically to this limit through deliberate fragmentation and decoupling compute from data by design, at the cost stated in III.3: sacrificed cross-domain performance and global consistency.

The only point left open at framing stage concerned Chapter I.2: should the three actors be named from the first draft, or should a generic mechanism be kept until a later Gemini framing? Amine settled on naming them immediately, which triggered, before any drafting, an independent search on each of the three actors — their storage format, their governance catalog, their network egress rates — rather than integration from memory.

The requested correction covered two distinct points. First, the explicit requalification of kinetic inertia as an extension proposed by this volume rather than a direct consequence of McCrory. Second, the injection of an empirical order of magnitude on BigQuery: rather than advancing a figure from memory, an independent search verified 2026 Google Cloud egress rates (0.08 to 0.23 dollars per gigabyte depending on destination) and the reference throughput of 10 Gbit/s, allowing a calculation of an order of magnitude of 80,000 to over 200,000 dollars per petabyte exported, then a theoretical transfer time of about nine days, smoothed in a second pass to be explicitly qualified as a physical floor rather than an observed average.

This global audit produced a recommendation to enrich section I.1 theoretically — an additional reference intended to strengthen the passage from individual software dependency to third-party ecosystem capture. An independent search could confirm neither the year nor the exact content of the proposed reference. Rather than integrating it under reservation, the reference was explicitly abandoned: unlike Volume VII, where the global audit produced an enrichment that was in fact integrated (Teece, 1986), this volume's global audit was here followed by a withdrawal, the factual-verification rule applying to a global-audit recommendation just as it applies to any other named example.