Split SQL dump files into import-ready parts.

When do you need to split a SQL dump?

A MySQL or PostgreSQL dump that grew past a few hundred MB stops being importable in a single shot. The destination may impose a max_allowed_packet limit, the import may time out before it finishes, the hosting panel may reject anything above a fixed file size, or a connection blip mid-import may force you to start over with no way to resume. Splitting the dump into smaller import-ready parts solves all of those — each partial imports independently, you can run them in parallel, and a failure in one does not invalidate the rest.

• Hosting panels (cPanel, Plesk) that cap phpMyAdmin imports
• Database migrations where you need to monitor progress per chunk
• Restoring to a new server with a strict max_allowed_packet limit
• Sharing a sanitised dump by email with attachment size limits
• Running ETL jobs that load one partial per worker in parallel
• Recovering from a half-finished import without re-running everything

Why SQL dumps are hard to split manually

A SQL dump is not a CSV. It has a preamble (CREATE TABLE, SET NAMES, LOCK TABLES, ALTER TABLE … DISABLE KEYS) that must appear at the top of every import file, plus thousands of INSERT statements that need to be distributed across partials. A naive line-by-line split breaks two things at once: the preamble is missing from every partial except the first, so the schema is not defined, and an INSERT that spans multiple lines is cut in half, leaving a syntax error in two adjacent files.

MessyMatch parses the dump with a SQL-aware tokenizer that respects string literals, comments and dollar-quoted blocks. It identifies the preamble, distributes the statements across partials, and writes the preamble at the top of every partial so each file imports cleanly on its own.

How the SQL splitter works

The dump is treated as a single raw-text input — no SQL is ever executed, the parser only reads and slices the text. The tokenizer walks the file, recognising statement boundaries (semicolons that are not inside a string or comment), and classifies each statement as preamble or body. The body statements — almost always INSERTs — are distributed across the partials you asked for, by statement count, file count or target byte size. The preamble is copied to the top of every partial.

Cuts only happen between full statements. A multi-line INSERT, an extended INSERT with many tuples, or any statement that spans more than one line stays intact in the partial it lands in. If the dump contains constructs the parser cannot guarantee to split safely (procedures, triggers, functions) it refuses with a clear message instead of producing broken output.

What the splitter handles

• Detects the preamble (CREATE TABLE, SET, LOCK statements)
• Repeats the preamble at the top of every partial
• Distributes INSERT statements evenly across partials
• Splits by statement count, file count or byte size
• Respects string literals, comments and dollar-quoted blocks
• Refuses to split a dump that contains unsafe constructs

Honest limits

This splitter is built for the common case: a dump produced by mysqldump or pg_dump with one INSERT per statement and a standard preamble. If your dump contains stored procedures, triggers, functions, complex DDL or vendor-specific extensions, the parser flags it as too complex and refuses — splitting those safely needs a real SQL engine, not a tokenizer. The fix is usually to regenerate the dump as data-only (--no-create-info for mysqldump) and run the splitter on that.

Browser-first by design

The SQL contents are processed inside your browser via a Web Worker and are not transmitted to our servers. Our servers do not have an endpoint that ingests file contents — the Web Worker reads the file from disk, runs the split locally and hands the partials back to the browser for download. We only record metadata about the operation (row count, file size, format, elapsed time) for abuse limits. See the privacy policy for the full list.

Related tools