PostgreSQL Migration and the Walled Garden Effect of Cloud Providers

PostgreSQL has become innovation's darling: it replaces legacy systems, powers greenfield projects, and even serves as backend for AI agents. Given this ubiquity, it would be reasonable to assume that a task as mundane as migrating a Postgres database from one environment to another would be trivial. It isn't. And the reason, as Robert Bernier argues in an article on Percona's blog, has less to do with Postgres itself and more with what has been built around it.

The starting point is a distinction every DBA should have clear before signing a cloud contract: Postgres is open and portable, but the architecture you build on top of it might not be. That's where the problem lies.

The Walled Garden Effect

The article uses the term walled garden to describe the phenomenon: nominally open software over which a vendor, platform, or ecosystem comes to exercise governance, distribution, and compatibility control to the point of making it problematic to interact with the same technology running elsewhere.

In the context of a DBaaS (database as a service), the provider makes three predictable moves. First, it controls the core platform, sets the standards, and hosts the marketplace. Second, it attracts developers, manufacturers, and service providers who build products that add value to that platform. Third, it convinces users to join the ecosystem, and it's the data, attention, and capital of those users that fuel network growth. The cruel detail is that the financial health of satellite vendors is tied to the decisions of whoever controls the platform.

Bernier sums up the feeling by paraphrasing the Eagles: "you can provision Postgres any time you like, but your architecture can never leave." It's the Hotel California effect applied to databases.

The Three Lock-In Mechanisms

The article identifies three concrete gears that turn a theoretically free Postgres into something hard to let go of.

Forks and proprietary features. Many providers offer databases that are "Postgres-compatible." The keyword is compatible, not equivalent. The service may emulate the same SQL syntax, the same drivers, and the same tools, and still introduce backend capabilities or operational dependencies that don't exist in community Postgres. A compatible interface doesn't imply equivalent portability. If you built your application on top of closed performance layers or proprietary auto-scaling, moving back to community Postgres may require a heavy architectural rewrite.

Asymmetry in migration cost. Entering the ecosystem tends to be cheap, sometimes there's even a financial incentive to bring your data in. Leaving is another story: moving the database to an alternative environment later tends to be considerably more complex and expensive.

Ecosystem gravity. A database doesn't live in a vacuum. When the instance is deeply integrated with the vendor's proprietary backup systems, security roles (IAM), and serverless analytics tools, leaving the database means rebuilding the entire infrastructure. The data remains portable; the architecture around it becomes progressively less portable.

What This Means Over the System's Lifetime

The more valuable the ecosystem becomes to the user, the greater the disincentive to leave. And if the exit is actually carried out, two costs show up that rarely enter the initial planning.

There are the switching costs, high because migration starts introducing data integrity risk and extraordinary complexity into a flow that has become tightly coupled. And there are the specialist costs: when vendor-specific features or dependencies exceed the in-house team's expertise, specialized consulting has to be budgeted for.

From the perspective of whoever administers the data, this is the central message: the architecture decision matters more than the provisioning decision. Provisioning is reversible; architecture, if poorly designed, is not.

What to Do in Practice Before Migrating

The article is more of a strategic warning than a step-by-step command guide, but it yields actionable principles for anyone evaluating or carrying out a Postgres migration in Brazil, where dependency on a handful of cloud providers is a concrete reality.

• Map out what is community Postgres and what is a vendor extension. Run SELECT * FROM pg_extension; and list everything that isn't part of the core. Each item on that list is a potential tie-in point.
• Test pg_dump/pg_restore early, not on the eve of migration. If the provider restricts superuser access or access to certain system catalogs, you find out now, not once downtime is already scheduled.
• Check dependencies outside the database. Managed backup, IAM, proprietary logical replication, and serverless cache layers are exactly the points that lock the exit.
• Document version compatibility. A database "compatible with Postgres 15" may not accept the restore of a dump generated from real Postgres 15. Confirm this beforehand.
• Consider logical replication as a low-downtime path. Postgres's native publication/subscription allows you to sync source and destination and flip the switch with a minimal window, as long as the source provider doesn't block the feature.

The Counterpoint: Open Source Values

Bernier doesn't conclude with fatalism. His point is that vendor dependency may seem inevitable in the current landscape, but it isn't. There are organizations that build commercial services on the principles that made open source work in the first place: transparency, interoperability, portability, and the customer's freedom to decide where and how their software runs. Percona, the author's employer, is presented as an example of a commercial model that treats commercial expertise and open source values as reconcilable, which is worth noting as the natural bias of whoever signs the piece.

The lesson that remains, regardless of vendor, is sober and familiar to anyone who has worked with data for a while: portability isn't a feature you turn on at the end, it's a design decision you make at the start. Modeling and integrity first; the freedom to migrate is born in the same place as good performance, the right design done before there's any rush.

The original article is on Percona's blog and references a paper on arXiv on the topic.