Google Cloud’s Real Lock-In Lives in Spanner and Firestore, Not Egress Fees

Egress fees are the part of a Google Cloud bill people can point to. It’s a line item, it has a per-GB rate, and it used to go up when you tried to leave. So it got blamed for lock-in. But if you’ve tried to actually move an application off Google Cloud, you know the egress bill isn’t what stops you. What stops you is that your application talks to Firestore instead of a normal database, your orchestration logic lives in a proprietary Workflows YAML file, and your transactional database depends on hardware Google built that nobody else has.

Egress is the fee you notice. The managed services are the trap you built, one “just use the managed service” decision at a time, over several years. This is the same pattern behind AWS lock-in, and we covered the AWS version of this argument here. GCP’s version is similar in shape but different in some important specifics, and those specifics matter if you’re deciding what to do about it.

Why This Matters Now

Google Cloud actually moved first on egress. In January 2024, Google announced it would waive network data transfer fees for customers migrating their data to another provider or on-premises, ahead of the EU Data Act taking effect and ahead of AWS’s own waiver two months later. The programs are not identical, though, and the difference matters if you’re planning an exit. Google’s waiver requires you to submit a request, get approved, and then terminate your Google Cloud agreement entirely within 60 days to receive the credit.

AWS’s version, by contrast, does not require closing your account, only proving the transfer is a one-time exit rather than routine traffic. If you’re planning to keep some workloads on Google Cloud while moving others off, Google’s all-or-nothing structure matters more to your planning than AWS’s does.

That distinction aside, the larger point holds for both platforms. If egress is negotiable and your workloads are mostly Compute Engine, Persistent Disk, and Cloud SQL, moving is largely a data migration and cutover exercise. The workloads that get stuck are the ones wired into services with no standard interface: Cloud Functions, Firestore, Cloud Spanner, Pub/Sub, Cloud Workflows, and Identity Platform. Each one requires application code written against a Google-specific SDK, data model, or event format. That code doesn’t move on its own. It gets rewritten, and that rewrite is where the real migration cost lives, regardless of what happens to the egress bill.

Cloud Functions: Better Event Portability Than Lambda, Same IAM Coupling

Cloud Functions (2nd gen) is built on Cloud Run underneath, and its event triggers run through Eventarc, Google’s event routing layer. The genuinely good news here: Eventarc delivers events in CloudEvents format, the CNCF’s open, vendor-neutral standard for describing event data, across every event source it supports. That’s a real difference from AWS, where EventBridge requires input transformers to approximate CloudEvents rather than emitting it natively. If your Cloud Functions code is written to consume standard CloudEvents payloads rather than reaching into Google-specific fields, the event-handling logic itself is more portable than the AWS Lambda equivalent.

What doesn’t move, on either platform, is the IAM wiring. Each function’s service account, its IAM role bindings, and the Eventarc trigger configuration connecting it to Pub/Sub, Cloud Storage, Firestore, or Cloud Audit Logs are all Google-specific resources that have to be rebuilt on any other platform. Moving to Knative or OpenFaaS on Kubernetes still means replacing the service-account-based permission model with your new platform’s equivalent and recreating every trigger. The function body and its event-handling logic are the easy part. The permission model and trigger wiring around it are not.

Firestore: The Query Model Breaks Before the API Does

Firestore is Google’s NoSQL document database, and its lock-in shows up first in the data model rather than the wire protocol. Firestore requires composite indexes for any query filtering or sorting on multiple fields, and a default project is capped at 200 composite indexes. Queries need an index that matches them exactly; an index with extra fields doesn’t satisfy a narrower query, so teams with wide, varied query patterns run out of index budget fast. Aggregation queries scale with the number of index entries scanned, not the size of the result returned, which means costs and latency creep up in ways that surprise teams used to relational query planners.

One developer who migrated off Firestore documented the core issue plainly: Firestore is priced and optimized around making individual document reads cheap on Google’s side, which pushes application developers toward over-fetching and client-side filtering rather than expressive server-side queries, and that pattern gets more expensive as an application scales rather than less.

A separate documented migration from Firestore to MongoDB describes the same root cause from the other direction: teams that reach for Firestore’s flexible, schema-on-read document model find that the same flexibility becomes a liability once they need real aggregation and join-like queries, which is exactly the kind of workload Firestore’s index-driven model handles worst. Both migrations required redesigning the data model and rewriting queries against the new database, not just switching a connection string.

Cloud Spanner: The One Google Itself Admits Is Hard to Leave

Cloud Spanner is the deepest lock-in on this list, and unusually, Google’s own documentation says so directly. Spanner offers two SQL dialects, GoogleSQL and a PostgreSQL-compatible dialect, and Google’s guidance is explicit: if portability is your highest priority, choose the PostgreSQL dialect, because it gives you the option of migrating to another PostgreSQL-compatible database later. Choosing GoogleSQL trades that option away for tighter integration with the rest of Google Cloud, including BigQuery.

Even the PostgreSQL dialect doesn’t fully solve the problem. Spanner’s global consistency guarantees are built on TrueTime, Google’s atomic-clock-and-GPS-based clock synchronization infrastructure, which doesn’t exist outside Google’s data centers. Comparisons from competing distributed-SQL vendors make the same point Google’s own docs imply: Spanner’s architecture is tied to hardware that only Google operates, so migrating off Spanner isn’t a matter of translating SQL, it’s a matter of replacing an entire consistency model with something like CockroachDB or a sharded PostgreSQL setup and re-validating every transaction guarantee your application assumed. If your team chose GoogleSQL for the tighter integration, as most Spanner deployments do, you’re migrating both the dialect and the consistency model at the same time.

Pub/Sub: Closer to Portable Than SQS, Still Its Own API

Pub/Sub is a better story than AWS’s SQS/SNS pairing, but it’s not a clean win either. Conceptually, Pub/Sub’s publisher/subscriber model maps closely enough to Kafka’s that application-level abstractions can paper over some of the difference, and Google’s own documentation on choosing between Pub/Sub and its managed Kafka service acknowledges this directly: if portability across cloud providers or on-premises environments matters to you, Google recommends standardizing on its managed Kafka offering instead of Pub/Sub, precisely because Kafka’s API is broadly adopted and Pub/Sub’s is not.

That’s a meaningful, if quiet, admission. Teams that built directly against the Pub/Sub API, its push/pull subscription model, and its GCP-native integrations with Cloud Functions, Dataflow, and BigQuery still have to rewrite every publisher and subscriber to speak AMQP or the Kafka protocol when they leave, the same category of work as an SQS migration. The difference is that Google itself points newer deployments who care about portability toward the open protocol instead of its own proprietary one, which is a more honest position than AWS has taken on SQS or EventBridge.

Cloud Workflows: A Smaller, Newer Version of the Step Functions Problem

Cloud Workflows defines orchestration logic in a declarative YAML or JSON syntax specific to Google Cloud, with steps that call Cloud Functions, Cloud Run, BigQuery, Pub/Sub, and external APIs. It’s a smaller and generally less deeply integrated service than AWS Step Functions, since most Workflows deployments are simpler pipelines rather than deeply branched state machines, but the lock-in mechanism is identical in kind: the orchestration logic lives in a proprietary syntax rather than in your application’s own code, and every step’s integration with a Google service is configuration that only means something inside Google Cloud.

Moving to Temporal, Airflow, or Argo means the same exercise as leaving Step Functions: reimplementing the control flow in code your team owns, rather than in a YAML file tied to one vendor’s runtime.

Identity Platform: The One Real Advantage Over Cognito

This is the clearest place where GCP’s lock-in profile is genuinely lighter than AWS’s. Firebase Authentication and its enterprise tier, Identity Platform, use a modified scrypt hashing algorithm for stored passwords, and critically, Google’s own documentation provides the exact parameters and export tooling needed to export those password hashes and import them into another system, including the project-specific signer key, salt separator, and rounds. This is the opposite of AWS Cognito, which stores password hashes in a way that cannot be exported at all, forcing either a mass password reset or a slow, login-triggered re-hashing migration.

That doesn’t make a Firebase Auth or Identity Platform migration trivial. Everything else that makes an identity migration hard is still present: reconfiguring social provider linkages, rebuilding multi-tenant configurations if you used Identity Platform’s tenancy features, and updating every Firestore security rule that reads a Firebase-issued auth token, since those rules stop working the moment your app stops issuing Firebase tokens.

But the core blocker that makes a Cognito migration a multi-month project, the inability to get your users’ credentials out at all, doesn’t exist here. A well-planned Firebase Auth exit can preserve every user’s existing password with no forced reset, which is a real, documented, and meaningful difference from AWS.

The Pattern Underneath All of These

Across every one of these services, the shape of the lock-in is the same even where the severity differs: a proprietary interface stands between your application and a piece of infrastructure that has an open equivalent elsewhere, and your application code inherits that interface’s specific data model, permission model, or syntax.

GCP is measurably better than AWS in a couple of specific, verifiable places, native CloudEvents support in Eventarc and exportable password hashes in Identity Platform being the clearest two, and about the same or worse in others, particularly Cloud Spanner, where Google’s own documentation concedes the portability trade-off up front.

The work required to undo any of this follows the same steps regardless of which platform you’re leaving: rewrite the SDK calls, redesign the data model or event format where one exists, replace the IAM- or service-account-based permission model, migrate the data itself, and re-test everything downstream of the old integration. None of that shows up as a line item on a Google Cloud invoice. All of it shows up in engineering time, which is why it’s easy to underestimate when a team first reaches for a managed service and expensive to discover only once leaving is on the table.

Where OpenStack Avoids This Trap Entirely

The reason this pattern doesn’t repeat on an OpenStack-based private cloud is architectural, not just a different price sheet. Nova, Cinder, Neutron, and Swift are open, community-governed APIs with multiple independent implementations, so there’s no single vendor’s SDK to get welded to in the first place. For a fuller comparison of how these map to hyperscaler services, see What Your Cloud API Choice Is Actually Costing You.

What runs on top of that infrastructure is the bigger point. Instead of Firestore, you run PostgreSQL, Cassandra, or ScyllaDB. Instead of Spanner, you run CockroachDB or a sharded PostgreSQL setup, without needing hardware Google won’t sell you. Instead of Pub/Sub, you run Kafka or RabbitMQ, speaking a protocol Google itself recommends for portability. Instead of Cloud Workflows, you run Temporal, Airflow, or Argo, with orchestration logic in your own codebase. Instead of Identity Platform, you run Keycloak or another standard OIDC provider. Instead of Cloud Functions, you run Knative or OpenFaaS on Kubernetes, consuming the same CloudEvents standard Eventarc already uses, so that part of the migration is closer to a redeploy than a rewrite. Every one of these speaks an open protocol rather than one vendor’s interface, which removes the lock-in at the source instead of managing around it.

The honest caveat is the same one that applies to any hyperscaler exit. Google’s managed services are managed for a reason, and running PostgreSQL, Kafka, or Keycloak yourself means your team owns the operational work Google was doing for you. OpenMetal’s assisted management options cover hardware and platform support, not full management of every application-layer service you choose to run on top of it.

If your team doesn’t already have that operational depth, budget for building it, rather than treating it as a footnote. For the fuller version of what a hyperscaler-to-OpenStack migration actually takes, see Migrate from GCP to On-Premises and A Practical Guide to a Successful Public Cloud Exit Strategy.

Deciding What to Untangle First

Not every Google Cloud dependency deserves the same urgency. A reasonable way to sequence this:

• Start with Compute Engine, Persistent Disk, and Cloud Storage. These are close to commodity, egress is waivable if you’re leaving entirely, and there’s no proprietary data model standing in the way.
• Audit the managed services next, ranked by how hard they actually are to leave rather than by monthly cost. Cloud Spanner and Firestore are the hardest, because they involve a data model rewrite. Pub/Sub and Cloud Workflows are a rewrite of integration code, but not a redesign of your core data. Identity Platform, despite being an identity system, is comparatively lighter than it looks, because the credentials themselves are exportable.
• Budget the hard dependencies in engineer-months. A Spanner migration in particular is a project with its own consistency-model validation phase, not a data transfer task with a deadline.
• And be honest about which workloads should stay. Genuinely global, elastic, or Spanner-dependent workloads that need TrueTime-grade consistency across regions are a legitimate reason to remain on Google Cloud. This isn’t an argument for leaving everywhere. It’s an argument for knowing which of your Google Cloud dependencies are actually load-bearing versus which ones were the easiest option at the time. If you want help sizing that for your own environment, you can start with a proof of concept.

FAQ

Is Google Cloud egress still a major lock-in cost?

Less than it used to be. Since January 2024, Google Cloud waives network data transfer fees for customers moving all their data off the platform, but unlike AWS’s version of this policy, Google requires you to fully terminate your Google Cloud agreement within 60 days of approval to receive the credit.

Is GCP’s lock-in the same as AWS’s?

The pattern is the same, but the severity differs by service. Eventarc’s native CloudEvents support makes Cloud Functions’ event handling more portable than AWS Lambda’s, and Identity Platform allows password hash export where AWS Cognito does not. Cloud Spanner is arguably worse than any single AWS service on this list, since it depends on Google-specific hardware infrastructure that has no equivalent anywhere else.

Which GCP managed service is hardest to migrate away from?

Cloud Spanner, by a clear margin. Its consistency guarantees depend on Google’s TrueTime infrastructure, and even choosing its more portable PostgreSQL-compatible SQL dialect doesn’t remove that underlying dependency. Firestore is the second hardest, because its query model has to be redesigned, not just translated.

Can I export my Firebase Authentication users if I leave Google Cloud?

Yes, including their password hashes. Firebase Authentication uses a documented, project-specific scrypt variant, and Google publishes the export and import tooling needed to move users to another identity provider without forcing a password reset.