Live transfer failed: "produced no tables" or "could not read the source"

A live transfer connects straight to your source and target databases over the network instead of working from an uploaded dump file. When it stops early, it almost always shows one of two messages:

• Could not read the source database — we could not reach or query the source you pointed us at.
• The migration produced no tables in the target database — the source was reachable, but we found nothing to copy.

Both are connection-and-permissions problems, not data problems. Here is how to find the real cause in a couple of minutes. If you would rather skip the networking entirely, export a dump and use the file converter — it never needs to reach your database.

First: confirm the source is reachable from outside

Run the same connection from your own machine. If it fails for you, it will fail for our servers too.

# PostgreSQL source — list tables in the public schema
psql "postgresql://USER:PASS@HOST:5432/DBNAME?sslmode=require" -c "\dt"

# MySQL source — list tables
mysql -h HOST -P 3306 -u USER -p DBNAME -e "SHOW TABLES;"

• Connection refused / timeout — the host or port is wrong, or a firewall blocks external access. Cloud providers usually require you to allow-list the connecting IP or open the database to the internet.
• SSL required / "no encryption" — add sslmode=require to the connection string. Most managed Postgres (Supabase, Neon, RDS) reject plaintext connections.
• Authentication failed — wrong user or password. Copy it fresh from the provider dashboard; a trailing space or an unescaped @ in the password breaks the URL.

Supabase and other IPv6-only hosts

Supabase's direct connection host is IPv6-only, so a server without IPv6 routing simply cannot reach it and the read fails. Use the Session pooler connection string instead — it is reachable over IPv4. In the Supabase dashboard open Project Settings → Database → Connection string and pick the pooler entry (port 5432, host containing pooler.supabase.com).

"Produced no tables": the source connected but looked empty

This means we authenticated and queried, but the schema we read had no tables. The usual reasons:

• Wrong schema. PostgreSQL puts tables in public by default, but yours may live elsewhere. Check where they actually are:

SELECT table_schema, count(*)
FROM information_schema.tables
WHERE table_type = 'BASE TABLE'
GROUP BY table_schema;

• Wrong database. On MySQL it is easy to connect to the server but name a database that has no tables (or doesn't exist). Confirm with SHOW DATABASES; then SHOW TABLES; inside the right one.
• Only views, no base tables. A schema full of views but no real tables copies nothing. Materialize the data you need into tables first.
• The role can see the database but not the tables. Connecting succeeds, yet \dt returns nothing because the role lacks privileges. Grant read access:

-- PostgreSQL: let the migration role read every table in the schema
GRANT USAGE ON SCHEMA public TO migrator;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO migrator;

Target-side checks

If the source clearly has tables but the target ends up empty, the writer could not create them:

• The target role needs CREATE on the target schema. On a fresh PostgreSQL 15+ database, non-owners cannot create objects in public until granted: GRANT CREATE ON SCHEMA public TO writer;
• Point at an empty target database you control. Transferring into a schema that already holds those tables can stop on conflicts before anything new lands.

A reliable fallback that skips the network

Live transfers depend on two databases both being reachable, correctly permissioned and SSL-configured at the same moment. When that is hard to arrange — locked-down VPCs, IPv6-only hosts, short-lived credentials — the file route avoids all of it. Export once and convert the file:

# PostgreSQL source
pg_dump --no-owner --no-privileges "postgresql://USER:PASS@HOST:5432/DBNAME?sslmode=require" > source.sql

# MySQL source
mysqldump --single-transaction --no-tablespaces -h HOST -u USER -p DBNAME > source.sql

The dump runs with your own credentials, on your own network, so none of the connection puzzles above apply. Then upload the file and let the converter handle the schema and data translation.

Tired of fighting connections? Convert a dump file to PostgreSQL instead →