A practical guide for teams using AWS RDS in production who want to move their dev, test, and staging databases to Neon Postgres without a full migration. The approach uses a 'Neon Twin' — a nightly synchronized copy of the RDS database created via pg_dump/restore automated through GitHub Actions. The post covers prerequisites, workflow file setup, key pg_dump/pg_restore flags, storing secrets in GitHub, known limitations (6-hour job limits, IP restrictions, SSL), and Neon's branching model for parallel developer environments. A companion tool called Twin Thing is also mentioned to help generate the GitHub Actions workflow.
Table of contents
What is a Neon Twin?PrerequisitesQuick startKnown limitationsCreating a Neon project to host your dev environmentMigrating data from RDS to Neon automatically: Using pg_dump/restore with GitHub Actions for nightly syncAdding environment variables to GitHub SecretsRun the workflowUse the Twin Thing app to build your workflowWrapping upNext steps1 Impression