---
title: Database management
description: Browse, query, import, and export your database from the browser using the built-in Database Manager. Works for WordPress, MySQL, MariaDB, and PostgreSQL services.
---

The **Database Manager** is a web GUI scoped to one database, accessed straight from the dashboard. Use it to browse tables, run SQL, import or export data, and anything else you'd normally do in phpMyAdmin or Adminer.

It's available for:

- **WordPress services** — manages the site's MariaDB database (paid plans only)
- **Standalone SQL databases** — `mysql`, `mariadb`, and `postgresql` engines (every plan, free and paid)
- **Not available** for MongoDB and Redis services — see the [Databases guide](/guide/databases#database-manager-web-gui) for the desktop-client path instead

## Opening the Database Manager

1. Open your service in the [dashboard](https://console.zevcloud.net).

2. **WordPress services:** click the **Database** tab. **Standalone databases:** open the service's **Overview** tab.

3. Click **Open database manager**. A new browser tab opens into the GUI.

4. The host, driver, and database name are pre-filled. Sign in with the database credentials shown on the same tab — username and password. You can only sign into your own service's database.

The session lasts for the browser tab's lifetime. If you close the tab and come back later, click **Open database manager** again — it issues a new short-lived URL (30 minutes) so you don't need to copy URLs around.

## Common tasks

### Browse and edit data

The left sidebar lists every table in the database. Click a table name to see its rows in a paginated grid. **Edit** modifies a row; **New item** inserts one. Use **Search** at the top of the row view to filter — it generates a `WHERE` clause behind the scenes.

For WordPress this is most useful for `wp_options` (changing `siteurl`, `home`, mail-from address, anything stored as a key/value), `wp_users` (resetting a stuck account), and `wp_posts` (rescuing an autosave that the admin won't load).

### Run SQL

Click **SQL command** in the left sidebar. The query runs against your service's database only — there's no way to escape into another service or another tenant.

Useful examples:

```sql
-- See your current siteurl after a migration
SELECT option_name, option_value
FROM wp_options
WHERE option_name IN ('siteurl', 'home');

-- Find every post that mentions an old domain
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%olddomain.com%'
  AND post_status = 'publish';

-- Count comments per post
SELECT post_id, COUNT(*) AS comments
FROM wp_comments
WHERE comment_approved = '1'
GROUP BY post_id
ORDER BY comments DESC
LIMIT 20;
```

> **Warning: Don't run a plain UPDATE for URL search-replace**
>
> WordPress stores some option values inside serialised PHP arrays. A plain `UPDATE` (or `sed` on a dump file) corrupts them. For URL replacements across post content, plugin settings, and theme customiser values, use the **WP-CLI search-replace** flow described in the [migration guide](/guide/migrate-wordpress) — it walks serialised data correctly.

### Export a backup

Click **Export** in the left sidebar.

- **Output:** `gzip` (smallest file, recommended)
- **Format:** `SQL`
- Tick **Tables**, **Data**, and either every table or just the ones you need.
- Click **Export**.

Your browser downloads the result. This is the fastest way to grab a quick backup before doing anything risky. For routine off-site backups, run the export on a schedule from a script (most teams use a `cron` job or a CI workflow that calls `mariadb-dump` against the same credentials).

### Import a `.sql` or `.sql.gz` dump

Click **Import** in the left sidebar, pick your `.sql` or `.sql.gz` file under **File upload → Choose files**, click **Execute**. The Database Manager streams the dump straight into the database.

The upload limit is **1 GB per file**, which covers virtually every WordPress migration. Both `.sql` and `.sql.gz` work — gzipped files are decompressed transparently, so you don't need to gunzip first.

> **Warning: Don't use 'From server' for migration dumps**
>
> You'll see a "From server" option below the file picker. That reads files from the Database Manager's own filesystem — which is a separate container that doesn't have access to your WordPress site's files. Even if you SFTP'd a `.sql` file into your service, the Database Manager won't see it there. Always use **File upload → Choose files** instead.

A 400 MB dump typically takes 1–5 minutes depending on your upstream connection — most of that is the browser-to-server transfer; the import itself is fast once the file lands.

> **Tip: Importing replaces what's there**
>
> Importing a dump that contains your full schema and data overwrites anything that's already in the matching tables. For WordPress migrations specifically, that's exactly what you want — the dump replaces the fresh install. For other situations (merging data, partial restores), be more careful: export first, then import.

## Permissions and access

The credentials shown on the dashboard give your service its own database user with full rights inside its own database, and nothing outside it. The Database Manager logs in as the same user. There's no way to reach another service's data — neither via the GUI nor via direct credentials.

By default the database is reachable only through the Database Manager URL or the service's internal hostname (from other ZevCloud services). If you need to connect from your laptop or an external service, turn on **Public Access** on the service's Overview tab (paid plans only) — see [Databases → Connect from your laptop](/guide/databases#connect-from-your-laptop-or-an-external-service).

## Database manager URL details

A few things worth knowing about the URL the dashboard opens:

- **Short-lived.** The URL contains a signed token that expires after 30 minutes. After that, requests inside the manager start returning 401 — close the tab, click **Open database manager** again, and you get a fresh URL.
- **Service-scoped.** A URL signed for one service won't work on another service's subdomain, even if you copy it across.
- **Don't share it.** While it's valid, anyone with the URL can reach the login page (they still need the database password). The 30-minute expiry limits the blast radius, but treat the URL as semi-sensitive.

## Troubleshooting

### "Invalid or expired token" when I open the manager

The signed URL has expired (30-minute limit) or you're trying to reuse a URL from yesterday. Close the tab, go back to the dashboard's **Database** tab, click **Open database manager** again. You'll get a fresh URL.

### Adminer's login form rejects my password

You're using your ZevCloud account password instead of the **database** password. The Database Manager logs into the database directly, not into ZevCloud. Open the **Database** tab on your service and copy the password under **Database Connection** (the masked one with the eye icon).

### "From server" doesn't show the file I just uploaded

Two common causes:

- The file landed in `wp-content/uploads/` rather than the root of your home directory. Adminer's "From server" looks in the home directory only. SFTP the file to the top level — `put old-site.sql.gz` without changing directories first.
- The file isn't named `.sql` or `.sql.gz`. Adminer filters for those extensions. If your dump is named `dump` or `dump.txt`, rename it to `dump.sql` or `dump.sql.gz`.

### Nothing happens when I click Open database manager

Browser popup blocker. The button opens the manager in a new tab; if your browser is set to block all popups, the new tab gets killed before it can navigate. Allow popups from `console.zevcloud.net` and try again. Most browsers also let you click an "allowed?" indicator in the address bar to permit the popup just-blocked.

## When to ask for help

Write to **support@zevcloud.net** if:

- You see a 500 error inside the Database Manager (rare; usually means the database container is misbehaving).
- You're trying to do something that needs cross-service database access (which we don't expose by design — we'll discuss the right approach).
- You broke the database with a bad query and don't have a recent export. We keep nightly backups for paid plans; we can restore one for you.

Include the service URL, the time the issue started, and what you were doing.
