Hacker News Reader

From what the migration doc says, it will only support pgdump migration. Meaning it will require downtime, or at least write downtime. Create backup using pgdump, restore the dump to new database. While making sure no changes to the old db before switch over.

View on HN

The ability to replicate from a database service is an extremely important consideration when picking any DBaaS. If you cannot do a no-downtime migration out of a database provider, you are needlessly locking yourself into a vendor.

Ouch that will make migrating anything over a few hundred gigs almost impossible. Our postgres db is about 2TB and pgdump stopped being viable a long time ago.

> Our postgres db is about 2TB and pgdump stopped being viable a long time ago.

Due to the time it takes to export, or because it can't handle a database of that size at all?

I'd assume they mean time to export, while 2TB is a substantial database, it's not pushing postgres limits.

you can use pg_basebackup to kickstart a replication slave. You can then just just down old and use new with ~1sec downtime. If you need to upgrade postgres at same time, you can then cascade to another one slave on same "new" host for safety, and pg_upgrade on that one. This will result in a bit more downtime, but also upgrading postgres version.

Reply on news.ycombinator.com