mysqldump-php is the mysqldump you can call from inside PHP

A dumper that runs inside the application

mysqldump-php is a PHP version of the mysqldump command line tool that comes with MySQL, without dependencies, output compression and sane defaults, as the readme puts it.

It is not a drop-in replacement for the binary. There is no dependency on the mysql client, compression is a dump setting, and the defaults are its own rather than the ones mysqldump ships with.

What it is for is the case where the dump has to happen inside a PHP process. A backup triggered by a web request, by a queue worker, by a deploy script written in PHP, or by a managed hosting panel that has PHP and nothing else, is a situation where shelling out to mysqldump is either impossible or awkward. This library produces the same shape of output from the same PDO connection your application already uses.

The connection is a standard PDO DSN, and that has been the case since version 2.0. The requirements are PHP 5.3.0 or newer, MySQL 4.1.0 or newer, and PDO. The licence is GPL-3.0, the language is PHP, and the last push to the repository was on 2026-08-02 with the most recent release being v2.13 on 2026-08-25.

Installing with Composer or with a curl pipe

There are two documented installation routes, and they are for two different situations.

The Composer route is the normal one.

$ composer require ifsnop/mysqldump-php

The other route is a curl command that always downloads and decompresses the latest release, and it is worth reading before running it because it is a shell pipeline that pipes a URL out of the GitHub API into a downloader and an extractor.

$ curl --silent --location https://api.github.com/repos/ifsnop/mysqldump-php/releases | grep -i tarball_url | head -n 1 | cut -d '"' -f 4 | xargs curl --location --silent | tar xvz

The Composer route is the one to prefer in an application, since it pins a version and records it in the lock file. The curl route is for a server where you are installing by hand and want the newest tarball without tracking tags.

The repository is small in the way a PHP library usually is, with src/ for the code, tests/ and unit-tests/ for the test suites, a composer.json, a phpunit.xml, a .travis.yml for continuous integration and a .scrutinizer.yml for the quality scoring service that the badge in the readme comes from.

Constructing a dump and writing it to a file

The getting started section gives two forms, one for a Composer or autoloader project and one for plain old PHP with an explicit include.

<?php

use Ifsnop\Mysqldump as IMysqldump;

try {
    $dump = new IMysqldump\Mysqldump('mysql:host=localhost;dbname=testdb', 'username', 'password');
    $dump->start('storage/work/dump.sql');
} catch (\Exception $e) {
    echo 'mysqldump-php error: ' . $e->getMessage();
}

The constructor takes the DSN, the username and the password, and start takes the output path. The plain PHP variant differs only in the include line, which points at the Mysqldump.php file inside the release directory.

The DSN is the same string PDO takes, and the library parses it, so a connection you already have configured in your application can be handed over as is. The constructor also takes a fourth and fifth argument for the dump settings and the PDO settings, and the documentation has a section for each.

The wiki is linked for a fuller usage example and, more usefully, for a comparison between mysqldump dumps and mysqldump-php dumps, which is the reference to read before you rely on the output being restorable.

The features that go beyond the original tool

The readme claims a list of capabilities and says the library is the only one that supports them. The list is worth walking through, because each item answers a specific failure.

Output binary blobs as hex, which is what the hex-blob setting does, and the comment in the default settings says it is faster than escaped content. Resolving view dependencies using Stand-In tables, which is the problem you hit when a view refers to another view and the dump restores in the wrong order. Output compared against the original mysqldump, with the testing linked to a CI system running from PHP 5.3 to 7.3 and hhvm, which is the closest thing to a correctness guarantee in the list.

Then there is the set of objects the original tool handles less conveniently. Stored routines, so functions and procedures, and events. Extended insert and complete insert, so you can choose between a compact multi-row insert and one statement per row. Virtual columns from MySQL 5.7. Insert-ignore, which is like a REPLACE but ignoring errors if a duplicate key exists.

And then the three that are really about the PHP context. Modifying data from the database on-the-fly when dumping, using hooks. Saving directly to Google Cloud Storage over a compressed stream wrapper, the GZIPSTREAM one. And restoring a dump from a file when no mysql executable is available, which turns the library into a restore tool as well as a dump tool.

Hooks are where the library earns its keep

Three hook points cover the things you actually need from a backup tool, and each one is a callable you register.

The first transforms values during the export. The readme's example use-case is removing sensitive data from database dumps, and the hook receives the table name and the row and returns the row.

$dumper->setTransformTableRowHook(function ($tableName, array $row) {
    if ($tableName === 'customers') {
        $row['social_security_number'] = (string) rand(1000000, 9999999);
    }

    return $row;
});

That is a genuinely useful capability, because a dump that contains real customer data is a liability, and the usual alternatives are to scrub the database before dumping it or to scrub the file afterwards.

The second hook reports on the progress of the dump, receiving an object and an info array, and the example checks whether the object is a table and prints its name and row count. The third is not a hook but a pair of setters that restrict what is exported, per table.

setTableWheres takes an array of table name to where clause, and these override the default where setting, so you can take the last three months of a users table and the last day of a logs table. setTableLimits does the same for row counts. Between the three, a dump can be both smaller and safer than a straight copy, which is the difference between a backup you can move around and one you cannot.

The CLI flags become a settings array

The dump settings array is the mysqldump option set translated into PHP, and reading the defaults tells you what the library decided to change.

$dumpSettingsDefault = array(
    'complete-insert' => false,
    'databases' => false,
    'default-character-set' => Mysqldump::UTF8,
    'disable-keys' => true,
    'extended-insert' => true,
    'events' => false,
    'hex-blob' => true, /* faster than escaped content */
    'insert-ignore' => false,
);

The keys are the mysqldump option names with the dashes preserved, which makes them easy to look up in the mysqldump manual, and the values are booleans and constants rather than the strings the command line takes.

The defaults tell a story. extended-insert is on and complete-insert is off, so a dump is compact by default. disable-keys is on, which is the mysqldump optimisation that omits the unique key checks around a bulk insert. add-locks and no-autocommit are on, so the restore is fast. add-drop-trigger is on, so a restore replaces triggers cleanly. And hex-blob is on with a comment saying it is faster than escaped content.

The readme's promise of sane defaults is doing real work here, since the alternative is a dump that restores slowly or not at all. The PDO settings are a separate fifth constructor argument, so the connection attributes and the dump behaviour do not get mixed together in one array.

A wide compatibility claim and a slow release cadence

The compatibility story is unusually broad, and it is the main reason to consider the library at all.

The requirements are PHP 5.3.0 or newer and MySQL 4.1.0 or newer, and the test matrix described in the readme runs from PHP 5.3 to 7.3 and hhvm, with the output compared against the original mysqldump. The topic tags list php5 and php7 alongside hhvm, linux, macos and windows. A library that still runs on PHP 5.3 is a library you can drop into an old host without a migration, which is a different proposition from the modern rewrite you would otherwise be asked to do.

The release cadence is the counterweight. The recent tags are v2.13 from 2026-08-25, v2.11 from 2023-03-18 and v2.10 from 2023-02-09, so there is a long gap between 2.11 and 2.13, and a shorter one between 2.10 and 2.11. The last push was on 2026-08-02, and the build badge still points at Travis CI while the quality badge points at Scrutinizer, which are both dated services.

So the picture is a project with a wide and carefully tested compatibility range, occasional bursts of releases, and a codebase that is small enough to read in an afternoon. That combination suits an organisation that has old PHP on old servers and needs its backups to keep working, and it suits nobody who wants a roadmap.

Editorial conclusion

Adopt mysqldump-php when the backup has to run inside a PHP application, on a host without the MySQL client tools, or when you need features the shipped mysqldump does not offer, such as row transformation on export or a restore from a file. Do not adopt it as a general purpose database migration tool, since it dumps a MySQL schema and nothing else. Verify first that your server is within the supported range, PHP 5.3 or newer, MySQL 4.1 or newer with PDO, and that the version you install is one you can test against, because the release history shows long gaps between the 2.10, 2.11 and 2.13 tags.

Frequently asked questions

Official sources

1. ifsnop/mysqldump-php on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases