When a developer writes client = bigquery.Client(), they are not just choosing a service. They are committing the application to BigQuery's thinking schema — its data types, its extended SQL syntax, its ARRAY_AGG, STRUCT, proprietary partitioning and clustering. Six months later, these idioms are everywhere in the code. The application no longer speaks the business domain language — it speaks BigQuery.

The same dynamic applies to DynamoDB (key-value data model with GSI/LSI secondary indexes, proprietary condition expressions), to Pub/Sub (push/pull subscription model, acknowledgment, retry policy), to Cosmos DB (SQL, MongoDB, Cassandra API depending on the day — but all proprietary in their subtleties). Each hyperscaler service is a dialect. And a developer fluent in BigQuery is not fluent in PostgreSQL — they must learn a new dialect with its own traps, performance characteristics and limits.

The Opération Dindon corpus documented egress fees as an economic capture mechanism. But even if egress fees were zero, migration would remain costly — because the true cost of migration is not data transfer, it is rewriting application code. Zero egress fees on S3 change nothing if the application calls 847 different S3 API endpoints with their nuances of versioning, presigned URLs and event notification. The gentle exit from hyperscaler cloud goes through code architecture, not just the network.

Eric Evans, in Domain-Driven Design (2003), names this pattern the Anti-Corruption Layer (ACL). When a system must integrate an external system with a different domain model, the ACL translates between the two — without letting the external model contaminate the internal model. The application only sees its own model. The ACL handles translation to the external. Changing the external = rewriting only the ACL.

Applied to cloud services: the application only sees its domain interface (DataWarehouse, MessageQueue, ObjectStore). The ACL translates to BigQuery, DynamoDB, S3. Migrating to PostgreSQL, Kafka, MinIO = rewriting the ACL. The business application does not change.

Terraform: infrastructure-as-code abstraction. Same HCL for AWS, GCP, Azure. Limited to infra — not proprietary managed services.
Apache Beam: data pipeline abstraction. Same pipeline on Dataflow (GCP), Flink, Spark. Successful abstraction — but specific to batch/stream pipelines.
Kubernetes: container runtime abstraction. A K8s pod runs on EKS, GKE, AKS or bare-metal without modification.
S3-compatible APIs (MinIO, Ceph, Cloudflare R2): application speaks S3, runs on any compatible backend. The success model to duplicate.
JDBC/ODBC: database access abstraction since the 1990s. Application speaks standard SQL, driver translates to DBMS dialect.

What is missing: abstraction of proprietary managed services — BigQuery, Pub/Sub, DynamoDB, Cosmos DB, Kinesis. No common standard. This is where lock-in is deepest and the Sovereign Interface most necessary.

The application defines its needs in business terms. Behind the interface, concrete implementations for each vendor.

Changing vendor = changing one configuration line. The business application does not know.

An HTTP proxy that receives proprietary API calls and translates them to an open source backend. The application keeps calling the DynamoDB API — but the proxy redirects to ScyllaDB or Cassandra.

Existing projects: DynamoDB Local (testing), Localstack (full AWS emulation locally), dynamo-cassandra-proxy (Apache).

A neutral query language above proprietary dialects. The application speaks a common DSL, the translation layer generates backend-specific code.

Existing projects in this spirit: SQLAlchemy (neutral ORM), dbt (neutral transformation), Ibis (pandas-like API on BigQuery, DuckDB, Snowflake).

Specific lock-in: extended SQL (ARRAY_AGG, STRUCT, UNNEST), partition/clustering, JavaScript UDFs, built-in ML.PREDICT.
Neutral interface: DataWarehouse.query(sql: str) → DataFrame — standard SQL only, no proprietary extensions.
Open source alternative: DuckDB (in-process analytics, same performance on small volumes), PostgreSQL + TimescaleDB (time series), ClickHouse (open source columnar analytics).
Bridge tool: Ibis — same Python API on BigQuery, DuckDB, Snowflake, PostgreSQL.

Specific lock-in: GSI/LSI model (global/local secondary indexes), proprietary condition expressions (attribute_exists, begins_with), DynamoDB Streams.
Neutral interface: KeyValueStore.get(key) / put(key, value) / query(pk, sk_prefix).
Open source alternative: ScyllaDB (DynamoDB API compatible), Cassandra, Redis with modules.
Translation facade: dynamo-cassandra-proxy (Apache) — DynamoDB API as facade, Cassandra as backend. Zero application rewrite.

Specific lock-in: topic/subscription model, push/pull, acknowledgment deadline, ordering keys, dead letter topics.
Neutral interface: MessageQueue.publish(topic, message) / subscribe(topic, handler).
Open source alternative: Apache Kafka, RabbitMQ, NATS. Standard: CloudEvents (CNCF) for message format.
Key tool: CloudEvents + one adapter per broker. Message format is neutral — only transport changes.

S3 is the only hyperscaler service whose API has become a de facto standard. MinIO, Ceph, Cloudflare R2, Backblaze B2 all implement the S3 API. The application speaks S3 and can run on any compatible backend. This is the model to replicate for other services. The lesson: standardise the API, not the service. The Sovereign Interface for S3 already exists — and it has freed thousands of organisations from object storage lock-in.

For a service like BigQuery used in a medium-sized Python application:

Define the domain interface: 2h — identify the operations actually used, reduce them to a minimal contract.
Write the BigQuery adapter: 4h — wrap existing calls behind the interface. Often this is refactoring existing code, not writing from scratch.
Write contract tests: 3h — tests that verify any adapter respects the interface contract.
Write a second adapter (local DuckDB): 3h — proves the interface is truly neutral and accelerates local development (no GCP needed in dev).

Total: 12h of senior engineering — a day and a half. Cost: ~€1,200-2,400 depending on rate.

For the same Python application, BigQuery → PostgreSQL migration without abstraction layer:

Code audit: 3 days — identify all BigQuery calls, all extended SQL idioms, all proprietary functions used.
Code rewrite: 10-30 days depending on complexity — replace each call, adapt each SQL query, handle type and behaviour differences.
Regression testing: 5-10 days — ensure the rewrite breaks nothing in business logic.
Progressive deployment: 3-5 days — switchover with rollback possible.

Total: 21 to 48 days of engineering. Cost: €25,000 to €60,000. And this assumes the migration succeeds on the first attempt — which is rare.

Sprint planning. The backend developer proposes calling BigQuery directly — "it's simpler, we already have the SDK, it will work in two hours". The Principal SRE says "we need an abstraction layer — 12h of work but we'll be free to migrate". The product owner says "we don't have 12h, we have a Friday deadline". Without Technical Primacy, the product owner wins. BigQuery is in the code. The chain is in the code. And in 18 months, when Google raises prices by 40%, the migration will cost 48 days.

This is exactly Scenario 1 of "Technical Primacy" — the suboptimal decision made to meet a deadline, whose debt materialises 18 months later. With the Sovereign Interface, the deadline would have been 12h longer. Without it, it will be 48 days.

The Principal SRE who wants to impose an abstraction layer now has a quantified argument: "12h now, or 48 days in 18 months. Choose." This is no longer a discussion about abstract architectural best practices — it is an ROI calculation presentable to the board. Technical Primacy is easier to exercise when it relies on defensible numbers rather than engineering principles.

If management decides to override the Sovereign Interface recommendation, the Principal SRE documents their veto: "I advise against calling BigQuery directly without an abstraction layer. Estimated risk: forced migration within 2 years, estimated cost €25,000 to €60,000. Recommended alternative: Sovereign Interface, 12h, cost €1,200-2,400." This document protects the engineer. It records the decision. And when the migration arrives, the causal chain is traced.