Why is the size of the SQL database different after exporting to a file than on the server?

When administering a website or application on mybox, downloading a database backup often reveals a confusing technical quirk: the downloaded .sql file is significantly smaller than the database size displayed in your hosting panel, even if you didn’t compress it into a .zip or .gz file.

This difference is completely normal and represents a fundamental operational reality of how Relational Database Management Systems (RDBMS) like MySQL or MariaDB store data live on a server versus how they represent it in a file.

1. Overhead and Allocated Free Space (Unused Slack Space)

Live databases are designed for speed, which means they prioritize quick data insertion over tight space saving.

• The Server Reality: When data is deleted or modified on your mybox server, the database system doesn’t instantly shrink the physical file on the disk (doing so is highly resource-intensive). Instead, it leaves those sectors empty, creating “holes” or unallocated free space marked for future write operations.
• The Export Reality: When you trigger an export (a database dump), the system only reads the active data rows. The empty, pre-allocated spaces and internal overhead are stripped away, instantly dropping the file size.

2. Binary vs. Plain Text Representation

The format of a live database is drastically different from a backed-up script.

• Binary Storage (On Server): On your server, data is written in a highly complex binary format (such as InnoDB .ibd files). This includes page layouts, system tablespaces, row tracking IDs, and transaction logs.
• Text Script (Exported File): A .sql file is just a plain, flat text file. It contains human-readable string commands like CREATE TABLE and INSERT INTO. It completely disces the heavy binary storage wrappers.

3. Indices are Outlined, Not Stored

Indexes are a mechanical necessity for keeping search queries fast, but they take up substantial room.

• On the Server: Indexes are fully compiled, raw binary trees cached on the disk to map out where data sits. For complex application tables, indexes can easily take up 30–50% of the total server space.
• In the Exported File: The export tool does not save the structural map of the index. Instead, it writes a single text line detailing how to rebuild it:SQLALTER TABLE `wp_posts` ADD KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`); When you eventually import this file onto a new database, the server reads that single instruction line and builds the heavy indexes from scratch.

Comparison Matrix