Moving a Startup Database Between Clouds: Beyond the Cutover

A migration should solve a named constraint: operational ownership, network distance, service capability, cost or another verified requirement. “Multi-cloud” is not a benefit by itself. Moving a database also changes the failure modes the team must understand.

Our recorded case placed application and database infrastructure under a more aligned operating arrangement. That establishes context, not a claim that every startup should make the same move. Before choosing a target, list the application’s required PostgreSQL features and the managed service’s actual limits. A cheap destination that cannot support the workload is not a useful saving.

A database can carry assumptions from its previous home: role names, authentication helpers, extension schemas, row-level policies and event triggers. A new managed service may not expose the same superuser privileges or extension controls. Copying the tables is only part of preserving behaviour.

The runbook’s useful lesson is to inventory those dependencies before the cutover window. Determine which are required by the current application and which are inherited furniture. Do not delete unfamiliar objects casually, but do not assume every historical platform helper belongs in the target either. Validate the application path rather than treating schema import as a complete migration test.

Logical replication can copy existing rows and continue applying changes while the source remains active. That can move much of the work outside the final pause. It does not eliminate the need to coordinate writers or validate the target.

The source and target versions, permissions, table identities and supported replication features must be checked against current documentation. A historical runbook describes what worked under its recorded conditions. It is not a universal command sequence. I would rehearse on a representative environment and measure lag, errors and capacity before choosing a production cutover strategy.

PostgreSQL’s logical replication documentation describes important limitations, including separately managed sequence state. A target can contain the copied rows while its next generated identifier is still wrong. A successful row count therefore does not establish that new writes will behave correctly after switching.

Likewise, schema changes need coordination. Do not assume that every DDL operation will follow the same path as row data. Keep the source stable where possible during the final phase, verify ownership and constraints on the target, and test an application write in a controlled context. The checklist should cover behaviour, not only table presence.

A connection working from a developer laptop does not establish that the target service can reach the source or that the application runtime can reach the target. Managed networking, egress and firewall rules can differ between those paths.

The migration record’s general lesson is to verify the real direction of each connection. Keep that proof private; public blog examples do not need actual addresses or firewall entries. A sanitised diagram can show source, replication subscriber and application without revealing infrastructure. Network troubleshooting is easier when the expected caller and destination are written down explicitly.

A cutover needs defined conditions: the target has the expected schema, required tables are synchronised, replication errors are understood and the application can authenticate with the intended least-privileged role. The team also needs a clear point at which to stop and return to the original arrangement.

I would record who controls application writes, who checks replication status and who approves resuming traffic. These responsibilities are more useful than an optimistic estimate of how quickly a command will run. The operation should not depend on everyone making a different assumption about whether the system is currently writable.

Scroll the table horizontally to see all columns.

Before the target accepts new application writes, returning to the source can be relatively straightforward if it remains intact. Afterwards, the two databases may diverge. A rollback plan must explain what happens to writes made on the new side, rather than simply say “change the connection back.”

This is why a controlled maintenance interval, limited validation and deliberate reopening matter. The right approach depends on tolerance for downtime and data loss. Do not promise zero downtime without a design and evidence that support it. The historical runbook’s short cutover is a recorded outcome under particular conditions, not a general service level.

The application can start successfully while a background job, reporting connection or unusual write path fails. Check representative reads and writes, scheduled work and operational dashboards. Observe errors and latency without immediately attributing every change to the move.

Also retire temporary migration access and credentials according to the team’s process. The public article does not need those details to teach the lesson. A migration is complete when the product works under the new arrangement and the temporary operating state has been cleaned up, not merely when the last row finishes copying.

Is dump-and-restore always wrong? No. For a small workload with an acceptable maintenance window, a simpler method may be easier to verify. Choose based on constraints rather than prestige.

Should startup credits decide the database architecture? They can affect economics, but expiry, compatibility, operational effort and the paid baseline matter too. A free resource can still be expensive to depend on.

What would I publish as the success metric? A clearly scoped result with its conditions and validation. I would not expose private data volumes or imply a performance gain without comparable before-and-after measurements.