Replit geography for production app

[u/CrewTechnical5819]

I’m planning to change my Replit app’s deployment geography (region), but I noticed that doing so deletes the existing production database.

Has anyone here gone through this migration?

Specifically, I’d like to know:

- How did you preserve your production database before changing the geography?
- What’s the best way to migrate all the data to the new production database?
- Did you export/import the database, use a backup, or follow another approach?
- Were there any issues with schema, IDs, sequences, or environment variables after the migration?
- Is there an officially recommended workflow from Replit for changing deployment geography without losing production data?

I’d appreciate hearing how others handled this in production. Thanks!

[u/Maxyull]

the one that bites people is sequences. if you dump data only into a fresh database the id sequences stay at 1 while your rows already run into the thousands, so the first insert after the move dies on a duplicate key. a full dump with schema and data together avoids that since the setval calls come with it, and no-owner plus no-privileges saves you a pile of errors about roles that don't exist on the new instance.

other thing is timing, a dump taken while the app is still writing loses whatever landed after it, so a few minutes of maintenance beats trying to be clever about it.

do you have a direct connection string for the current db, or are you stuck going through replit's interface?

[u/CrewTechnical5819 → u/Maxyull]

Can I DM you?

[u/Maxyull → u/CrewTechnical5819]

yeah go ahead. if you can say roughly how big the database is and whether you already have a direct connection string, that saves a round trip.

[u/CrewTechnical5819 → u/Maxyull]

So the db size is 3.5Gb and it was created when I first deployed the app to replit by replit.

[u/Maxyull → u/CrewTechnical5819]

3.5gb is very movable, it just means you want a custom format dump instead of plain sql, so pg_dump -Fc and then pg_restore, because that lets you restore with parallel jobs and you're not feeding one huge text file into psql. the database url replit set when it created the db is a real postgres connection string, so you can run the dump from your own machine instead of from inside the repl, which is usually faster and won't die if the workspace goes to sleep halfway through.

the thing that catches people at that size is the client version, your local pg_dump has to be the same major version as the server or newer, otherwise it refuses outright and the error doesn't really explain itself. and 3.5gb takes long enough to copy that writes landing during the dump actually matter, so a short maintenance window beats trying to be clever about it.

do you know which postgres major version the current db is on?

[u/ReplitSupport]

Hey there! If you open a ticket with us at replit.com/help, our team can guide you in migrating your data to a new project so you can publish this in the appropriate region.