> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dbhost.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Import your own SQL dump with psql or pg_restore

> DBHost does not accept uploaded dumps. Import .sql, .sql.gz or custom-format dumps yourself with psql or pg_restore using the owner role over TLS.

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](/api-reference/backups/restore-upload).
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](/guides/tls-connections) for your client;
  use `sslmode=verify-full`.

For large imports, consider the
[direct migration connection](/guides/direct-migrations). It avoids
transaction pooling and has longer timeouts than the
[query timeout profiles](/guides/connection-limits-and-timeouts).

## 2. Import

Plain SQL (`.sql`):

```bash theme={null}
PGSSLMODE=verify-full PGSSLROOTCERT=system \
  psql -h db.dbhost.app -p 6432 -U YOUR_OWNER_ROLE -d YOUR_DATABASE \
  -v ON_ERROR_STOP=1 -f backup.sql
```

Compressed SQL (`.sql.gz`): decompress first, or stream it:

```bash theme={null}
gunzip -c backup.sql.gz | PGSSLMODE=verify-full PGSSLROOTCERT=system \
  psql -h db.dbhost.app -p 6432 -U YOUR_OWNER_ROLE -d YOUR_DATABASE -v ON_ERROR_STOP=1
```

Custom-format dumps (`.dump`, or `.backup` in PostgreSQL custom format):

```bash theme={null}
PGSSLMODE=verify-full PGSSLROOTCERT=system \
  pg_restore --no-owner --no-privileges --exit-on-error \
  -h db.dbhost.app -p 6432 -U YOUR_OWNER_ROLE -d YOUR_DATABASE backup.dump
```

`--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](/guides/database-roles)
  access to the imported tables if they need it.
* If your app gets `permission denied for table ...` after an import, run
  [repair ownership](/api-reference/databases/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](/guides/restore-from-backup); DBHost runs and
verifies that restore for you.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.