If you have IP restrictions in place on our source database and need to grant a set of IP addresses access, see our Import public IP addresses documentation.
Migration Options Overview
PlanetScale Postgres provides three primary migration approaches to suit different business requirements, database sizes, and downtime tolerances: You can also utilize our migration scripts directly if you prefer. These scripts can be used to migrate straight from any Postgres source that supports logical replication into PlanetScale Postgres.1. pg_dump and Restore
The pg_dump method is the simplest approach for migrating smaller PostgreSQL databases. This method involves creating a full backup of your source database using PostgreSQL’s built-inpg_dump utility and then restoring it to your PlanetScale Postgres database.
How it works:
- Export your entire database schema and data using
pg_dump - Transfer the dump file to PlanetScale Postgres
- Restore the database using
pg_restoreorpsql
2. WAL Log Replication
Write-Ahead Logging (WAL) replication provides a near-zero downtime migration by continuously streaming transaction logs from your source PostgreSQL database to PlanetScale Postgres. How it works:- Set up logical replication between your source database and PlanetScale Postgres
- Stream WAL logs in real-time to keep the target database synchronized
- Perform a quick cutover when ready to switch to the new database
3. Amazon Database Migration Service (DMS)
Amazon Database Migration Service (DMS) provides a managed migration service that can handle complex database migrations with built-in monitoring, error handling, and data validation. How it works:- Configure DMS replication instance and endpoints for source and target databases
- Set up full load and change data capture (CDC) for ongoing replication
- Monitor the migration process through the AWS console
- Perform cutover when the target database is fully synchronized
Migration Method Comparison
| Feature | pg_dump & Restore | WAL Log Replication | Amazon DMS |
|---|---|---|---|
| Best For | Small to medium databases | Production databases requiring minimal downtime | Large, complex databases with transformation needs |
| Downtime | High (hours to days) | Minimal (minutes) | Minimal to none |
| Setup Complexity | Low | Medium | High |
| Infrastructure Requirements | None (built-in tools) | Source DB configuration changes | AWS DMS resources |
| Data Consistency | Point-in-time snapshot | Real-time sync | Real-time sync with validation |
| Cost | Free (built-in tools) | Low (minimal resources) | Medium (AWS DMS charges) |
| Database Size Limit | Limited by storage/time | No practical limit | No practical limit |
| Schema Changes During Migration | Not supported | Limited support | Full support |
| Data Transformation | None | Limited | Extensive transformation rules |
| Error Handling | Manual intervention required | Basic retry mechanisms | Automated error handling and recovery |
| Rollback Options | Manual restore from backup | Stop replication, switch back | Stop DMS task, failback procedures |
Migration Considerations
Before migrating your PostgreSQL database to PlanetScale Postgres, there are several important factors to consider to ensure a smooth migration process.PostgreSQL Version Compatibility
PlanetScale Postgres supports PostgreSQL 18 and PostgreSQL 17. If your source database is running an older version of PostgreSQL, you should verify compatibility and consider upgrading your source database before migration, or plan for potential compatibility issues during the migration process. Version considerations:- PostgreSQL 18: Fully supported
- PostgreSQL 17: Fully supported
- Earlier versions: May require additional testing and validation
- Version-specific features: Newer features may not be available in older versions
Upgrading from PostgreSQL 17 to 18 on PlanetScale
We don’t currently offer an automated in-place major version upgrade from PostgreSQL 17 to 18. You can perform an online upgrade by migrating from your existing PlanetScale Postgres 17 database to a new PostgreSQL 18 database using our import guides:- For near-zero downtime with logical replication: follow the WAL replication guide
- For simpler/smaller databases: use pg_dump/restore
- If you prefer a managed migration service: use Amazon DMS
- Create a new PostgreSQL 18 database (same region and similar configuration).
- Use one of the import methods above to sync data from your PostgreSQL 17 database.
- Validate data and application behavior, then update your application connection string to the new database.
- Decommission the old PostgreSQL 17 database when you’re ready.
Extension Support
PlanetScale Postgres will have limited extension support at launch. Many PostgreSQL databases rely on extensions to provide additional functionality, and not all extensions will be available initially. Important notes about extensions:- Review your current database’s installed extensions using
\dxin psql or by queryingpg_extension - Identify which extensions are critical to your application’s functionality
- Plan for alternative approaches if critical extensions are not supported
- Test your application thoroughly in a staging environment before migrating production data
- PostGIS for geospatial data
- pg_stat_statements for query statistics
- UUID extensions
- Full-text search extensions
Third-Party Enhancements and Tools
PlanetScale Postgres does not support third-party enhancements to PostgreSQL’s core capabilities at launch. This includes: Currently unsupported:- Custom background workers
- Third-party connection poolers (like PgBouncer)
- External procedural languages beyond the standard ones
- Third-party monitoring tools that require database-level access
- Custom shared libraries or plugins
PlanetScale Postgres includes connection pooling by default.
- Migrate custom functions to standard PostgreSQL syntax where possible
- Utilize Metrics, Insights, and 3rd party integrations for monitoring (LINKS HERE)
Pre-Migration Checklist
Before starting your migration:-
Database Assessment
- Document your current PostgreSQL version
- List all installed extensions and their usage
- Identify any third-party tools or enhancements in use
- Review custom functions and stored procedures
-
Compatibility Testing
- Test your application against your target PostgreSQL version (18 or 17)
- Validate that critical extensions are supported or have alternatives
- Identify any custom code that may need modification
-
Migration Planning
- Choose the appropriate migration method based on your requirements
- Plan for testing in a staging environment
- Prepare rollback procedures if needed
- Schedule migration during low-traffic periods if possible

