Standard migrations are included with every database. You see the exact
plan before anything runs, your source keeps serving traffic the whole
time, and most cutovers need only a brief window.
$ curl -O https://pgrun.dev/discovery.sql discovery.sql 100%[==================>] 12.0K$ shasum -a 256 discovery.sql bf33edf04e14da086437788eb7a851964103fc06312808380528f863976b1646 discovery.sql✓ matches the hash printed below$ psql -q -f discovery.sql "$DATABASE_URL"$ ls -la pgrun-discovery.json -rw-r--r-- 1 you staff 9.2K pgrun-discovery.json✓ written locally. nothing was uploaded. drop it on this page to see your report.$
$ curl -O https://pgrun.dev/discovery.sql discovery.sql 100%[==================>] 12.0K$ shasum -a 256 discovery.sql bf33edf04e14da086437788eb7a851964103fc06312808380528f863976b1646 discovery.sql✓ matches the hash printed below$ psql -q -f discovery.sql "$DATABASE_URL"$ ls -la pgrun-discovery.json -rw-r--r-- 1 you staff 9.2K pgrun-discovery.json✓ written locally. nothing was uploaded. drop it on this page to see your report.$ $ head -3 discovery.sql -- pgrun.dev discovery — captures the SHAPE of your database -- for a migration assessment. Read-only: SELECTs over -- pg_catalog/pg_stat_*. It never reads a row of your data.$ grep -cE "^(SELECT|SET)" discovery.sql 16 16 statements: SELECTs plus one SET statement_timeout. 12KB of SQL — audit it yourself before running.$ $ jq 'keys[0:6]' pgrun-discovery.json [ "fks", "pgss", "role", "server", "tables", "indexes" ]$ jq '.tables.top[0] | {name, total_bytes}' pgrun-discovery.json { "name": "orders", "total_bytes": 43578368 } table names, sizes, index defs, settings — never a row of your data.$
The assessment checks
extensions, replica identities, large tables, sequences, replication
settings and more — fifteen checks — then recommends the exact
migration path we'd use. Analysed on your machine; nothing is uploaded
unless you choose to attach it.
[02]
Where you're coming from
Every source has its quirks. We've met them.
+
Heroku Postgres
No logical replication allowed — so it's a maintenance-window dump, or trigger-based sync run with our team.
+
AWS RDS / Aurora
Flip rds.logical_replication in the parameter group and the near-zero-downtime CDC path opens up.
+
Supabase
We map auth/storage schemas and extensions first, then migrate the parts that are actually yours.
+
Neon
Logical replication works; branch storage quirks show up in sizing, and the assessment accounts for them.
+
Google Cloud SQL
cloudsql.logical_decoding on, then CDC. The assessment confirms your instance is ready.
+
Self-hosted
You control wal_level, so every path is available — usually the fastest migrations of all.
[03]
The four paths
The assessment picks one of four migration paths from your database's
actual facts — size, replication settings, replica identities:
+
pg_dump / pg_restore
One-shot copy in a maintenance window. Simplest; best for smaller databases or sources that don't allow replication.
+
native logical replication
Continuous sync, brief cutover. A good fit for smaller databases that are already replication-ready.
+
pgcopydb --follow
Parallel copy plus change streaming (CDC) — near-zero downtime regardless of size. Our default for most migrations.
+
remediate first, then CDC
Some tables lack a replica identity? We fix those first — with per-table instructions — then run the CDC path.
Whatever the path: sequences are synced at cutover, materialized views
refreshed, and row counts verified before your application moves.
Nothing is ever deleted from your source.
[04]
What it costs
Standard migrations are included with every database — planning and
execution, no per-GB fee, no consultants. Unusually large or exotic
setups get a plan and a straight answer before anything is committed.
[05]
Questions
?Will my application have downtime?
Most migrations need only a brief cutover window. The exact shape depends on size, write volume, and what your current provider allows — the assessment characterises it for your database before anything runs.
?What access do you need?
For a dump path: a connection string. For CDC paths: a replication user on the source. You create both, you revoke both, and the assessment itself needs neither — it runs on your side.
?What about my extensions?
The assessment compares your installed extensions against what we ship, version by version. Gaps are flagged before migration, not discovered during it.
?Can I run the migration myself?
Yes — the plan shows every step in standard tooling (pg_dump, logical replication, pgcopydb). Or drop pgrun.dev/migrate.md into your repo and your coding agent can run the whole migration from that one file, with hard safety rules built in. We're here when you'd rather not.
?What happens if something goes wrong mid-migration?
Your source stays live and untouched until the moment you point your application at us — the copy runs alongside it. Worst case, you simply don't cut over.
