Logical replication plus continuous CDC lets you shift PostgreSQL with only a brief write drain at cutover. Exact steps, commands, and checks. Read now.
Why logical replication and CDC fit this move
Moving a live PostgreSQL database to a serverless SQL target is less about rewriting queries and more about keeping two systems consistent until the moment traffic flips. Logical replication streams row-level changes from the source without requiring a full physical clone. Continuous change data capture (CDC) keeps that stream current so the target can catch up while the source still serves reads and writes. Together they let you rehearse the migration under real load and shrink the final cutover to a short write drain instead of a long outage.
Serverless SQL platforms usually manage storage, scaling, and connection limits differently than a self-managed instance. Plan for connection pooling, cold starts on idle endpoints, and any differences in extensions, data types, or isolation behavior before you open the replication path. Validate that the target can accept the tables, sequences, and constraints you care about, and decide early which objects will replicate continuously versus which you will reload or rebuild after cutover.
Prepare source and target before you open the stream
On the source, confirm logical decoding is enabled and that the publication (or equivalent change feed) covers the tables you must move. Prefer a stable primary key or unique identity on every replicated table; without one, conflict handling and resume after reconnect get harder. Capture a baseline schema dump, sequence values, and a short inventory of roles, grants, views, functions, and scheduled jobs so nothing essential lives only in application memory.
On the target, create an empty schema that matches the source as closely as practical. Load a one-time snapshot of the data first when your tools support snapshot-plus-stream, then attach continuous CDC so new commits apply in order. Keep the initial load and the ongoing stream on separate, monitored pipelines so a failed bulk load does not silently corrupt the live feed. Document connection strings, credentials rotation, and which side owns DDL during the dual-write window—prefer freezing non-critical schema changes until after cutover.
- Verify publication membership, replica identity, and that excluded tables are intentional.
- Confirm the target schema matches types, nullability, and indexes needed for write traffic.
- Record sequence high-water marks and plan how they will be advanced or reseeded at cutover.
- Establish lag, error, and disconnect alerts before any application points at the target.
Run dual operation, then cut over with a brief write drain
With replication healthy, run application reads against the target in a canary or shadow path if your stack allows it. Compare row counts, checksums on key tables, and a sample of recent updates until lag stays near zero under normal write volume. Treat prolonged lag or repeated apply errors as a hard stop: fix schema drift, oversized transactions, or missing privileges before you schedule cutover.
At cutover, stop application writes to the source (or put the app in a short maintenance mode), wait until the CDC stream reports zero lag and the last known LSN or transaction marker has applied on the target, then flip the connection string or router to the serverless endpoint and resume writes. Immediately check inserts, updates, and deletes on a critical path; advance sequences if the target does not inherit them automatically; and leave the source in a read-only or stopped state long enough to roll back if smoke tests fail. Only after those checks pass should you decommission the old write path and retire the replication slot or change stream.
Checks that prove the migration held
Post-cutover validation should be operational, not ceremonial. Confirm write traffic lands only on the target, lag metrics stay flat with no backlog growing on a drained source, and application error rates for database timeouts or constraint failures remain normal. Spot-check financial or identity tables with known recent changes, and ensure background jobs, webhooks, and reporting jobs use the new endpoint. Keep a documented rollback: re-enable source writes only if the target is still empty of new commits you cannot reconcile, otherwise plan a reverse stream before you need it.
Treat the migration as complete when monitoring, backups, and access control on the serverless side match your production bar—not when the first successful insert returns. Logical replication plus continuous CDC give you a controlled path; the brief write drain is earned by preparation, lag discipline, and explicit go/no-go checks at every stage.