Beyond Logical Replication: Migrating Multi-Terabyte PostgreSQL Databases When Logical Replication alone Isn't Enough

Logical replication is often the preferred approach for achieving near-zero downtime PostgreSQL migrations. However, for very large databases with high-write workloads, relying solely on logical replication can introduce unexpected operational challenges. In this session, I'll share a real-world migration of a multi-terabyte PostgreSQL production database where a conventional logical replication approach led to severe operational issues. During the migration, the initial table synchronization held a long-running snapshot for an extended period, preventing autovacuum from reclaiming dead tuples. This resulted in rapidly growing table bloat, increasing dead tuple counts, transaction ID wraparound warnings, and ultimately a production outage. To overcome these limitations, we designed and implemented a hybrid migration strategy. Instead of relying entirely on logical replication, we created a custom update-tracking mechanism using PostgreSQL triggers for the high-write tables. Existing data was backfilled independently while ongoing updates were captured in a lightweight change table. Before cutover, the captured changes were replayed, allowing the destination database to reach consistency without requiring a long-running initial snapshot. During this talk, I'll cover: - Why standard logical replication became a bottleneck for our workload - How long-running snapshots affected autovacuum and transaction wraparound - The production incident and the lessons learned - The design of the trigger-based change capture mechanism - The backfill and replay process - Operational considerations, trade-offs, and failure scenarios - When this hybrid approach should (and should not) be used Attendees will leave with a practical migration pattern that can be applied when traditional logical replication alone is insufficient for very large, high-write PostgreSQL environments.