# Databases

Source: https://laraport.app/docs/databases/

> Open the database of a Laravel app in Docker: PostgreSQL, MySQL, MariaDB, Percona or SQLite. Browse tables, run SQL, download dumps and restore them.

The **Data** tab lists the databases laraport can reach from the container.

## The app's database

A Laravel container often has the database client (`psql`, `mysql`) while the database runs in another container, reachable only on the internal network, as on Dokploy. laraport reads the connection the app is configured with and offers **PostgreSQL (app)** or **MySQL (app)**:

- It loads only Laravel's configuration (no service providers run, nothing connects), so it honours `config:cache`, `DB_URL` and the real environment over `.env`.
- The client runs in the app container when it has one, or in the database's own container on the same server, found by host name. The entry then says `run in <service>`.
- An *(app)* entry opens the app's configured database directly. Other databases on that server are not listed, so you cannot wander into another app's data by accident. The header shows where you are: `via app · host:port/db`.

The same works for **Redis (app)**.

## Database containers

A container that runs the database server itself gets an entry for it:

- PostgreSQL, when `postgres` and `psql` are there;
- MySQL, MariaDB or Percona, when `mysqld` or `mariadbd` and a client are there;
- SQLite, when `sqlite3` is there: every `*.sqlite`, `*.sqlite3` and `*.db` file in the app is listed as a database.

Credentials come from the container's environment: `POSTGRES_USER` and `POSTGRES_PASSWORD`; `MYSQL_ROOT_PASSWORD`, `MYSQL_USER` and `MYSQL_PASSWORD` or their `MARIADB_*` versions. System databases are hidden.

## What you can do

- **Browse tables** and **run SQL** in the [table view](https://laraport.app/docs/table-view/), with editing.
- **Info and stats**: size, version, uptime, largest tables, row counts, cache hit ratio, connections, long-running queries.
- **Schema**: tables, schemas, views, sequences, functions, columns, foreign keys, routines.
- **Indexes**: unused and duplicate indexes, index usage, tables without a primary key.
- **Maintenance**: bloat, locks, replication lag, `VACUUM ANALYZE`, `ANALYZE TABLE`, integrity checks.
- **Dumps**: `pg_dump` (plain, with inserts, or custom format), `mysqldump`, `sqlite3 .dump`, compressed and saved to your downloads folder.
- **Restore a dump** into a PostgreSQL or MySQL/MariaDB database. See [Restoring a dump](#restoring-a-dump).

For a desktop client such as TablePlus or DBeaver, open a [tunnel](https://laraport.app/docs/tunnels/) to the app's database.

The SQL input keeps a history per database (`↑` `↓`), stored in `~/.config/laraport/history.json`.

## Restoring a dump

**Restore a dump**, under Backup in the actions of a PostgreSQL or MySQL/MariaDB database, loads a dump from your computer into that database. It accepts:

- PostgreSQL: `.sql`, `.sql.gz`, or a `pg_dump -Fc` `.dump`;
- MySQL and MariaDB: `.sql` or `.sql.gz`.

### Turning it on

Restoring is off until you switch on **Allow restoring dumps** in Settings (`s` on the home screen), or set `allow_restore: true`. Until then the action explains how to turn it on.

### The window

The restore window shows:

- what happens on an error;
- the exact command it runs;
- **PRODUCTION**, when this is the production app's database;
- a field for the dump file on your computer, and one for the database's name.

It runs only after you type the database's name. Then `ctrl+s`, or `enter` in the name field, starts it.

### What happens

The file is streamed to the client in the container over stdin, with progress. Nothing is copied to the server's disk, and the password goes over stdin as for every other command.

- **PostgreSQL** restores in one transaction. laraport sends `BEGIN` before the dump and `COMMIT` after it, with `psql -v ON_ERROR_STOP=1`, or runs `pg_restore --single-transaction --exit-on-error --no-owner --no-acl` for a `.dump`. An error, a file cut short or a dropped connection leaves the database as it was.
- **MySQL and MariaDB** run the dump statement by statement and stop at the first error. What ran before the error stays.
- A `.sql.gz` is checked to be whole before anything is sent.
- The restore counts as done only when the client printed laraport's end marker, so a stream that stopped early is never reported as restored.

The dump is restored on top of what the database has. To replace the data, restore into an empty database, or use a dump made with `--clean`.

Restores are recorded in the [journal](https://laraport.app/docs/journal/). A [read-only server](https://laraport.app/docs/read-only/) refuses them.

## Passwords

Passwords are never put on a command line, where any user on the server could read them with `ps`. laraport passes them over stdin, and the shell in the container exports them as `PGPASSWORD` or `MYSQL_PWD` for that one command.