I’m not 110% sure that I restored everything just as it was, but I had to delete my blog and recreate it on IONOS, the inept hosting solution I had the misfortune to choose.

This is not the first time that their incompetence has hit me, but this time I had to act:

In August 2024, the DB had 1.26 GB (down from 1.44 GB). In March this year, it had 1.78 GB. Today, it reached 2 GB!

A 2 GB database footprint for 670 posts and 3,160 comments is completely absurd. The database size reported by phpMyAdmin was 202 MB. Exporting it to SQL statements resulted in a 71 MB text file!

Gemini:

The discrepancy you are seeing (202 MB reported by the plugin vs. 2 GB reported by IONOS) is a classic artifact of how the InnoDB storage engine handles data deletion.

When your optimization plugin deletes thousands of old revisions, spam comments, or expired transients, MariaDB removes the rows but does not automatically return that freed disk space to the operating system. Instead, it holds onto that allocated space in its .ibd files (or the shared ibdata1 file) to use for future data. Your plugin is reading the logical size of the data (202 MB), while IONOS is reading the physical high-water mark on the disk (2 GB).

This massive initial bloat is almost always caused by aggressive logging. Security application firewalls (like Wordfence) tracking live traffic in tables like wp_wfHits, or excessive PHP session transients, can balloon a database to 2 GB in weeks. When those logs are eventually cleared, the empty 2 GB shell remains.

Since IONOS support won’t run a compaction script, here are the two ways to force MariaDB to release that space back to the host.

Method 1: The OPTIMIZE TABLE Command

…

Method 2: The Export & Reload (The Guaranteed Fix)

…

Nope. No can do. Gemini again:

If the information_schema query confirms your table data and indexes equal exactly 202 MB, then your tables are completely clean. The logical data is fine.

The remaining 1.8 GB is structural or logging overhead generated by MariaDB itself, sitting at the filesystem level. Because you are on a managed IONOS environment rather than your own bare-metal server, you are jailed out of the directories where this bloat lives.

This ghost space is almost certainly one of three things:

  • The ibdata1 Shared Tablespace: Even if innodb_file_per_table is currently on, historical undo logs, system data, and previous table data get trapped in the monolithic ibdata1 file. This file never shrinks automatically, even when rows are deleted or tables are optimized.
  • Orphaned Temp Files: When an ALTER TABLE or OPTIMIZE TABLE operation fails or times out in the background, MariaDB leaves behind hidden temporary files (e.g., #sql-xxx.ibd). If a previous optimization attempt timed out, that ghost file is still sitting on the disk eating your quota.
  • Binary Logs (Binlogs): When your optimization plugin wiped out thousands of revisions and transients, MariaDB wrote every single one of those deletions to a binary log for replication/recovery. Deleting massive amounts of data paradoxically creates massive log files.

If you had root SSH access, you could just run ls -lh /var/lib/mysql, spot the 1.5 GB mysql-bin.0000X or orphaned #sql file, and wipe it out. But on shared hosting, you don’t have the privileges to run PURGE BINARY LOGS; or clear the file system.

The Bypass (The “New Container” Method)

Since you cannot reach the filesystem to delete the overhead, and IONOS support won’t run a compaction script, you have to abandon the bloated database container entirely.

Dropping the tables isn’t enough, because it won’t shrink ibdata1 or clear the binlogs. You need to spin up a fresh instance.

  1. Export: In phpMyAdmin, export your current 202 MB database as an .sql file. (Select “Custom”, check all tables, and ensure “Add DROP TABLE…” is checked).
  2. Create New: Log into the IONOS Control Panel (not phpMyAdmin). Go to your database section and create a brand-new MariaDB database. It will generate a new database name, username, and password.
  3. Import: Open phpMyAdmin for the new database and import your .sql file. MariaDB will write fresh .ibd files sized exactly to your 202 MB footprint, with no historical logs or temp files attached.
  4. Swap: Edit the wp-config.php file in your WordPress root directory (via FTP or SSH) and update the DB_NAME, DB_USER, and DB_PASSWORD variables to point to the new database.
  5. Destroy: Verify the blog is loading correctly on the new database, then delete the old 2 GB database from the IONOS panel.

This entirely circumvents the host’s restrictive architecture and instantly reclaims the physical disk space.

Creating a new DB is impossible. The DB section includes a single DB, limited to 2 GB, which is now full and can only be managed via phpMyAdmin. Gemini:

This confirms the worst-case scenario for shared hosting: your 202 MB of data is trapped inside a 2 GB bloated container, and because you only have one database slot, you are completely locked out of the filesystem where the bloat actually lives.

Since the tables themselves are clean, the remaining 1.8 GB consists of either binary logs (MariaDB recording all the deletions your plugin made), an overgrown ibdata1 shared tablespace (which never shrinks automatically), or an orphaned hidden temporary file from a previous failed optimization.

Because phpMyAdmin only has access to the logical layer (the tables) and not the physical layer (the filesystem), you cannot fix this by dropping rows or tables.

Here is how you clear that hidden space when trapped in a single-database, 2 GB limit.

Step 1: Try Flushing the Logs (Zero Risk)

Before doing anything drastic, try forcing MariaDB to clear its binary logs via phpMyAdmin. On shared hosting, this usually fails with an “Access denied” error because you lack SUPER or BINLOG_ADMIN privileges, but if IONOS left a loophole in their permissions, this will fix the issue instantly.

…

If it succeeds, check your quota. If it fails with a privilege error, you have to execute the “Nuke and Pave” method below.

Step 2: The “Nuke and Pave” Protocol

Since you have a limit of 1 database, you cannot spin up a side-by-side replacement. You must delete the container to free up your single slot, then rebuild it. This will cause brief downtime for your blog, so do this during a low-traffic window.

…

Nope. I cannot delete the DB in the IONOS Control Panel. I can only delete the entire website! Gemini:

This confirms exactly what kind of environment you are dealing with. You aren’t on standard shared hosting—you are trapped in a “Managed WordPress” container appliance.

In this architecture, the database isn’t a standalone service; it is a permanently bound volume tied directly to the WordPress installation. This is why the IONOS sysadmins told you they “couldn’t do anything.” It’s not that a sysadmin technically can’t clear a binlog; it’s that their support tier literally does not have shell access to your specific container. They just have the same dashboard buttons you do.

OK, so it recommended that I export everything, delete my blog, then create a fresh WordPress site and import things back.

To make a long story short (Wordfence 2FA was active, and I had to temporarily disable it, as well as delete some tables and files it used; UpdraftPlus worked but with hiccups on large archives; IONOS has a slow and convoluted mechanism to reassign the domain name and the SSL certificate; etc.), this is the new size of the site:

What? 0.17 GB instead of 2 GB? Oh, this must be a miracle!

As for the fucktards de chez IONOS…

And no, there was no link in the previous message. They usually send a link to a page that gives useless instructions on how to run OPTIMIZE TABLE commands, but this time they forgot.

If you don’t understand French, here’s the part you need to translate:

Par ailleurs, le lien communiqué dans notre précédent message présente une méthode permettant d’effectuer certaines opérations de nettoyage de manière autonome. Si cette approche ne correspond pas à votre niveau de maîtrise technique ou à vos besoins, il reste possible de solliciter une nouvelle intervention de nos administrateurs. Celle-ci fera l’objet d’une facturation selon les conditions habituellement applicables à ce type de prestation.

IONOS SE (formerly 1&1 Internet AG), a major German cloud infrastructure company that generates over EUR 1.3 billion in annual revenue. 🤮 Wanna buy some stock?