Guide Databases & MySQL

How to export a database

Turn a live database into a single portable SQL file, ready to back up, move, or hand to a developer.

iFastHosting Support Team Updated 26 August 2026 6 min read Beginner

An export turns everything in a database — its table structure and every row of data — into a single SQL file: plain text made up of CREATE TABLE and INSERT statements that can rebuild the whole thing from nothing. It is the basis of a manual backup, the first half of moving a database to another server, and usually the fastest way to hand a working copy of a site's data to a developer.

Exporting with phpMyAdmin

phpMyAdmin is reached through the databases section of your control panel and handles this well for anything up to a moderate size.

Quick versus Custom

After selecting the database and opening the Export tab, you are offered two export methods:

Method	Use it when
Quick	You want the whole database, structure and data, with sensible defaults. Correct for most backups and migrations.
Custom	You need to export only some tables, exclude data and keep just the structure, or change the output format.

Leave the format as SQL in either case — it is the format nearly every import tool, including phpMyAdmin's own, expects.

Compress anything but a tiny database

The Custom export screen offers a compression option — gzip is the widely supported choice. A compressed export can be a fifth of the size of the raw SQL, which matters both for how long the download takes and for whether the file fits under an import size limit later.

Exporting with mysqldump

If you have SSH access to the server — available on some hosting tiers and standard on a VPS or dedicated server — mysqldump does the same job from the command line and handles large databases more comfortably than a browser upload does on the way back in.

mysqldump -u dbuser -p dbname > dbname.sql

You will be prompted for the password rather than typing it on the command line, which keeps it out of your shell history. To compress the output as it is written, pipe it through gzip:

mysqldump -u dbuser -p dbname | gzip > dbname.sql.gz

For a WordPress or other InnoDB-based database that is being written to while you export it, add --single-transaction. It takes a consistent snapshot at the moment the dump starts, rather than potentially capturing a table that changed halfway through the export:

mysqldump -u dbuser -p --single-transaction dbname | gzip > dbname.sql.gz

--single-transaction only helps with InnoDB

It relies on a transactionally consistent read and has no effect on the older MyISAM storage engine. Most modern WordPress and application databases are InnoDB by default, but if you are working with an older site it is worth checking rather than assuming.

What an export does and does not include

A standard export captures every table's structure and data in the database you selected. It does not capture:

Files. Uploaded images, themes, plugins and application code live on disk, not in the database, and need their own copy.
Users and privileges. Database-level user accounts are stored outside the database itself. Recreate the user and re-attach it on the destination — see creating a MySQL database and user.
Other databases. An export is scoped to the one database you selected. An account with several sites needs a separate export per database.

Checking the export actually worked

A failed or truncated export usually looks fine at a glance — you get a file, it has a plausible size, and it is only when you try to import it that something is missing. Two quick checks catch most problems before they cost you a wasted import:

Open the file in a text editor. A complete SQL export ends with a final INSERT or UNLOCK TABLES statement, not mid-sentence. A file that stops abruptly partway through a line was cut off, usually by a timeout or a lost connection during a very large export.
Compare the file size to what you expect. If the database normally holds a reasonable amount of data and the export comes back a few kilobytes, something went wrong — most often the wrong database was selected, or the export ran against an empty test database by mistake.

For anything you are relying on — a backup you might genuinely need, or a migration where the old server is about to be switched off — it is worth doing one more thing: import the file somewhere disposable and confirm the data is actually there, rather than trusting the export screen's success message alone. An export that phpMyAdmin reports as successful and an export that is actually usable are not quite the same guarantee.

Treat the file as sensitive

An export contains everything the database contains

Customer records, password hashes, order history — whatever the live database holds, the export holds too, in plain readable text. Store exports somewhere access-controlled, never attach one to an email casually, and delete old copies you no longer need rather than letting them accumulate on a desktop.

What to do with the file next

To load an export back into a database, see importing a database with phpMyAdmin. If you are moving a whole site to a different server, moving a database to a new server covers the export-transfer-import sequence end to end, and if this export is part of a backup routine rather than a one-off job, backing up a database on a schedule covers automating it so you are not doing this by hand every time.