We just released a new Postgres import feature that will be available with Flyctl
Notable use cases:
- Import your data from an external Postgres offering.
- Migrate away from Stolon and onto our new Flex implementation.
- Migrate to the latest major version of PG.
- Seed a staging environment.
$ fly pg import $SOURCE_URI --app <target-pg-app> ? Choose a region to deploy the migration machine: Boston, Massachusetts (US) (bos) ? Select VM size: shared-cpu-1x - 256 Waiting for machine 217811106f0d89 to start... Connecting to fdaa:0:2e26:a7b:ea:5375:c5b6:2... complete [info] Running pre-checks [info] Source connnection is healthy [info] Target connnection is healthy [info] Source PG version: 14.7 (Ubuntu 14.7-1.pgdg20.04+1) [info] Target PG version: 15.2 (Debian 15.2-1.pgdg110+1) [info] Migration pre-checks have completed without issues [info] Starting migration [info] Postgres migration has completed Waiting for machine 217811106f0d89 to stop... 217811106f0d89 has been destroyed
Note: We currently only support single database imports.
For clarity, the
source-uri should be in the following format:
Usage: flyctl postgres import <source-uri> [flags] Flags: -a, --app string Application name --clean Drop database objects prior to creating them. -c, --config string Path to application configuration file --create Begin by creating the database itself and reconnecting to it. If --clean is also specified, the script drops and recreates the target database before reconnecting to it. (default true) --data-only Dump only the data, not the schema (data definitions). -h, --help help for import --image string Path to public image containing custom migration process --no-owner Do not set ownership of objects to match the original database. Makes dump restorable by any user. (default true) --region string Region to provision migration machine --vm-size string the size of the VM
There are a few different knobs you can tweak with this feature and it’s important that you read through them carefully. If you’re intending to import data into a live production database, always make sure to test in a staging environment first.
If you need to define your own custom migration process, you are welcome to fork the following repo and do whatever you need to do:
The import process takes a custom image in case you need to do anything fancy. For issues, bug fixes, etc. please issue a PR against the repo.