Skip to main content
DBHost does not restore files that you upload. The dashboard and API reject customer-uploaded .sql, .sql.gz, .dump and .backup files with 409 CUSTOM_RESTORE_UPLOAD_DISABLED; see Customer restore upload unavailable. Instead, run the import yourself with standard PostgreSQL tools.

​
1. Prepare

  • Use the owner role’s credentials from the database page. On a single-login database, use that login. Runtime and read-only roles cannot create tables.
  • Take an on-demand backup of the target first, so you can go back.
  • Review the dump. It runs with your owner’s privileges, and anything that needs superuser (for example CREATE ROLE, ALTER SYSTEM or unsupported extensions) will fail.
  • Use the TLS settings for your client; use sslmode=verify-full.
For large imports, consider the direct migration connection. It avoids transaction pooling and has longer timeouts than the query timeout profiles.

​
2. Import

Plain SQL (.sql):
Compressed SQL (.sql.gz): decompress first, or stream it:
Custom-format dumps (.dump, or .backup in PostgreSQL custom format):
--no-owner makes your owner role own every restored object, and --no-privileges skips grants to roles that do not exist on DBHost. PGSSLROOTCERT=system needs libpq 16 or newer; with an older client, point it at your system CA bundle. When you create the dump on the source server, pg_dump --no-owner --no-acl avoids most ownership and grant errors up front.

​
3. Fix grants and ownership

  • Grant your runtime, read-only and additional roles access to the imported tables if they need it.
  • If your app gets permission denied for table ... after an import, run repair ownership or dbhost databases repair-ownership <database-id> to give the owner role ownership of every table, sequence and view.

​
Restoring a DBHost backup instead

If the dump is a backup that DBHost made of the same database, use Restore from a DBHost backup; DBHost runs and verifies that restore for you.