Optimize WordPress database: Remove junk data and shrink database

Over time, in a WordPress database Several post revisions, auto-saved drafts, spam comments, expired transients, and data from no longer used plugins can cause the database to become significantly larger than necessary.

A large database is not automatically a slow database. Nevertheless, it is worth removing unnecessary data on a regular basis. Especially with websites that have been around for several years, are frequently edited, or have used many plugins, considerable amounts of no longer needed data can accumulate.

In this guide, we explain to you, what WordPress stores in the database, which data can normally be cleaned up safely, where special caution is required, and how you can sensibly optimize a WordPress database without deleting important content.

Briefly explained: a WordPress database should not be as small as possible, but clean and efficient be. Only delete data whose function you know, and create a current backup before any major database cleanup.

What does WordPress store in the database? #

In simple terms, WordPress consists of two main areas: the Files your website and the Database.

For example, the files contain:

• WordPress core files
• Plugins
• Themes
• uploaded images and other media files
• Configuration files

In contrast, the database contains a large portion of the actual website content and settings. These include, among other things:

• Posts and pages
• Post revisions
• Comments
• User accounts
• Categories and Tags
• WordPress settings
• Plugin and theme settings
• Metadata
• temporarily stored information
• with WooCommerce additionally numerous shop, customer and order data

That is why the database is a central component of your WordPress website. An ill-considered cleanup can have much more serious consequences than just a little lost storage space.

Why does a WordPress database grow over time? #

A growing database is completely normal at first. When you create new pages, publish posts, receive comments, or use plugins, additional database entries are created.

In addition to this actually required data, however, information can accumulate that is no longer needed later.

Typical examples are:

• old post revisions
• automatic drafts
• deleted posts in the recycle bin
• Spam comments
• deleted comments
• expired transients
• orphaned metadata
• legacy plugin settings
• temporary data
• Log and statistical data of certain plugins

Depending on the website, this data may be negligible or make up a significant portion of the database.

A large database is not automatically a problem #

The pure file size of a database only gives a limited indication of the speed of a WordPress website.

A correctly structured database with many necessary datasets can function smoothly. At the same time, a much smaller database can cause slow queries if, for example, a plugin executes inefficient database queries or creates problematic entries in frequently loaded options.

Therefore, the goal of an optimization is not:

„My database needs to be as small as possible.“

Rather:

„My database should only contain the required data and remain technically clean.“

Note: Never delete data just because a table looks large. First, you must clarify which application or WordPress function uses this data.

Before every database cleanup: Create a backup #

Before deleting data from the WordPress database or editing tables directly, you should have a recent backup.

This applies in particular to:

• productive corporate websites
• WooCommerce stores
• Member websites
• High-traffic websites
• Websites with extensive plugin data
• manual changes via phpMyAdmin

A database cleanup differs from many normal WordPress settings: Deleted data cannot necessarily be restored simply via an „Undo“ button.

Important: A backup should be created before the cleanup and not only after something has already gone wrong.

How big is my WordPress database? #

If you are using CURIAWEB web hosting, you can manage your databases via cPanel manage.

For a detailed view, phpMyAdmin. There you can open the relevant WordPress database and view the contained tables and their size.

If you are running multiple WordPress installations, you should first make sure that you have opened the correct database.

You can find the used database name in the WordPress file:

wp-config.php

There is the database about DB_NAME defined.

We have already explained how to identify the correct WordPress database via cPanel and phpMyAdmin in our guide Change WordPress password via phpMyAdmin explained in more detail.

Understanding the most important WordPress database tables #

A standard WordPress installation uses various tables with different tasks.

With a table prefix of wp_ do the following tables belong to this, for example:

• wp_posts – Posts, pages and other content types
• wp_postmeta – additional information on content
• wp_comments – Comments
• wp_commentmeta – additional comment data
• wp_users – User accounts
• wp_usermeta – additional user information and permissions
• wp_options - WordPress and plugin settings
• wp_terms – Terms like categories and tags
• wp_term_taxonomy – Assignment and type of taxonomies
• wp_term_relationships - Links between content and taxonomies
• wp_termmeta - additional information on taxonomy terms
• wp_links – WordPress legacy link management

Plugins can create their own additional tables. WooCommerce and more extensive extensions can therefore add numerous other tables to a WordPress database.

The table prefix also does not have to wp_ loud. It may be configured differently on your installation.

Post revisions: One of the most common reasons for additional data #

WordPress can store previous versions of posts and pages during editing as so-called Revisions save.

This is a very useful feature. If you accidentally overwrite content or want to return to an older version, revisions can be a lifesaver.

However, many revisions can accumulate on frequently edited pages.

Especially in the case of extensive landing pages or websites that have been edited over years, individual content items can have numerous old versions.

Should I delete all WordPress revisions? #

Not necessarily.

Revisions are not useless data garbage. They fulfill a specific security and convenience function when editing content.

A sensible strategy can therefore be to remove very old revisions or to limit the number of revisions stored in the future, instead of disabling the feature altogether.

Before a cleanup, you should check, especially in the case of important pages, whether you might still want to fall back on older versions.

Limit the number of WordPress revisions #

If you want to prevent WordPress from saving a very large number of revisions per post in the long run, you can set the maximum number via the file wp-config.php limit.

An example would be:

define( 'WP_POST_REVISIONS', 10 );

This limits the number of saved revisions per post or page.

The specific value is not a general recommendation for every website. For frequently edited editorial websites, a higher number may make sense, while fewer revisions may be sufficient for simple corporate websites.

Recommendation: Completely disabling revisions saves database entries, but it also removes a useful recovery feature. Limiting them is the better compromise for many websites.

Automatic drafts and trash contents #

During editing, WordPress automatically saves intermediate drafts. In addition, deleted posts and pages initially remain in the trash.

This is intentional and protects against accidental data loss.

However, if many unneeded drafts or trash items have accumulated over a longer period of time, they can be reviewed and permanently deleted.

For example, open:

Posts → All Posts

or:

Pages → All Pages

and check the respective trash and draft areas.

We explain how posts and pages are managed in our guides on Editing and Deleting WordPress Posts as well as to Editing and deleting WordPress pages.

Clean up spam comments and trash #

Websites with an activated comment function can accumulate large amounts of spam comments over time.

WordPress distinguishes, among other things, between:

• approved comments
• pending comments
• Spam
• Recycle Bin

Spam and comments that are no longer needed can be deleted.

For websites with a very high volume of spam, regular cleaning can prevent an unnecessary amount of comment data from being stored.

We explain how to properly manage comments and their status at Manage comments in WordPress.

What are WordPress transients? #

Transients are temporarily stored data that WordPress or plugins can cache for a specific period of time.

For example, a plugin can temporarily store the result of a complex calculation or an external query so that it does not have to be performed again every time the page is loaded.

Transients typically have an expiration time. Once expired, they are no longer valid.

Expired transients can therefore generally be removed. WordPress or the respective plugin will regenerate required temporary data as needed.

Should I constantly delete all transients? #

No.

Transients exist precisely to temporarily cache certain data. If you delete them permanently, it can even cause extra work for WordPress or plugins because the data has to be regenerated over and over again.

A cleanup expired Transients can be useful. A constant complete deletion of all temporary data, on the other hand, is not a performance strategy.

What is orphaned data? #

As orphaned data are simply referred to as database entries whose original association no longer exists.

An example: A plugin stores additional information for a post. If the original content or a plugin function is removed, metadata that is no longer needed can remain under certain circumstances.

Such data may occur, among other things, in the following areas:

• Post metadata
• Comment metadata
• User metadata
• Taxonomy mappings
• plugin-native tables

The problem: Not every entry that looks „orphaned“ at first glance can be safely deleted.

Attention: Do not delete any metadata or database tables solely based on their name. Modern plugins may use data structures whose purpose is not obvious without knowing the plugin.

Uninstalled plugins may leave data behind #

Deactivating or deleting a WordPress plugin does not necessarily mean that all data generated by that plugin is removed from the database.

This is even partly intended.

If you reinstall a plugin later, many users want to reuse their previous configuration. Therefore, some plugins keep their settings or tables even after uninstallation.

Other plugins explicitly offer an option during removal such as:

„Delete all data when uninstalling“

Whether left-behind data can be removed therefore depends on the respective plugin.

How to correctly disable and remove plugins will be explained later in our guide Deactivate or delete WordPress plugins.

Detect old plugin tables #

In phpMyAdmin, you can often see additional tables created by plugins alongside the WordPress core tables.

The table name sometimes contains the name or an abbreviation of the plugin in question. However, you should not rely on that blindly.

Before you delete a supposedly old plugin table, you should clearly clarify:

• which plugin created the table
• whether the plugin is still active
• whether another plugin uses the same data
• whether the data is still needed
• whether a later reinstall is planned
• whether a current backup is available

If you cannot answer these questions, leave the table as it is.

The wp_options table deserves special attention #

One of the most important WordPress tables is:

wp_options

or correspondingly with a different table prefix:

deinpraefix_options

This is where WordPress, themes, and numerous plugins store configurations and other values.

Individual plugins can leave significant amounts of data there. However, even more important than the sheer size can be, which option data is loaded automatically on page views.

What does autoload mean in WordPress? #

Certain entries from the options table can be loaded automatically by WordPress because they are frequently needed.

It can become problematic when plugins save very large amounts of data as autoloaded options or leave behind unnecessary entries after their removal.

This can impact performance, even though the entire database might not be particularly large.

Precisely here is where it becomes clear why looking solely at the database size is not sufficient.

For advanced users: Noticeably large automatically loaded option data can be a starting point for performance analysis. However, never delete or change such entries solely based on their size. First, it must be clarified which component requires them.

Do not treat the WooCommerce database like a normal blog #

At a WooCommerce website special care is required.

An online shop stores significantly more business-relevant data than a simple blog. Depending on the WooCommerce version, configuration, and extensions, this can include, among other things:

• Orders
• Order items
• Customer data
• Product data
• Tax information
• Shipping information
• Vouchers
• Webhooks
• scheduled background tasks
• Payment-related metadata
• Plugin-specific shop data

Such data must not simply be deleted as „old database entries“.

In addition, there are legal and accounting retention obligations that can be relevant depending on the company and type of data.

Important for WooCommerce: Never purge order, customer, payment, or tax-relevant data on suspicion. In the case of a production shop, it must be clearly determined prior to any data purge which data may be removed technically and legally.

Action Scheduler can generate large tables #

WooCommerce and numerous other WordPress plugins use the Action Scheduler, to schedule and execute background tasks.

Depending on the activity of a website, many entries can accumulate over time.

Especially in the case of shops or websites with automations, corresponding tables can therefore grow significantly.

Many entries are not automatically an error. However, if there are an unusually large number of failed or constantly regenerated tasks, the cause should be investigated first.

Merely deleting the entries, for example, does not fix a plugin that generates new failed tasks every minute due to an error.

Optimizing database tables: What does that mean? #

MySQL and MariaDB can technically optimize tables. This is not about deleting WordPress content, but about the internal organization and storage of the database tables.

After many modifications and deletions, unused storage can accumulate within a table, depending on the database engine used.

Table optimization can reorganize or reclaim this memory under certain conditions.

However, that doesn't mean every WordPress database needs to be manually optimized all the time.

Optimize WordPress database via phpMyAdmin #

Depending on the server configuration, phpMyAdmin offers a function for optimizing database tables.

Optimize tables in phpMyAdmin #

1. First, create or check a current backup.
2. Open cPanel.
3. Start phpMyAdmin.
4. Select the correct WordPress database.
5. Check the displayed tables.
6. Mark the tables that need to be optimized, or use the provided selection function.
7. Select the function „Optimize table“ or rather „Optimize table“.
8. Wait until phpMyAdmin has completed the operation.
9. Then check the website and the WordPress admin area.

Whether and how much memory is actually freed up depends on the database structure, the storage engine used, and the state of the tables.

Does „Optimize table“ make my website faster? #

Not necessarily.

Table optimization can be useful in certain situations, but it is not a universal WordPress turbo.

If your website is slow, completely different causes may be responsible:

• inefficient plugins
• too many external requests
• slow PHP processes
• unoptimized images
• missing caching
• poorly coded database queries
• excessively large automatically loaded options
• Problems with themes or page builders

Database optimization should therefore be considered part of technical maintenance and not as a one-size-fits-all solution for every slow WordPress website.

Can I use a WordPress optimization plugin? #

Yes. There are WordPress plugins that enable database cleanups conveniently via the dashboard.

Such plugins can, for example, offer functions for:

• Revisions
• Drafts
• Spam comments
• Recycle bin contents
• Transients
• Table optimization

However, a plugin does not automatically make the cleanup risk-free.

If an option offers, for example, „delete orphaned metadata“ or „remove unused tables,“ you should still understand which data is affected by it.

Basic rule: The more aggressive a cleanup function sounds, the more carefully you should check what it actually deletes.

Do not permanently install an additional plugin for every maintenance task #

For a one-time database cleanup, you do not necessarily have to keep a corresponding plugin installed permanently.

If you only need a maintenance plugin for a specific task, you can remove it again after a successful cleanup, provided none of its functions are permanently required.

Every additional plugin expands the code of your WordPress installation and must be maintained and updated itself.

Therefore, do not install multiple plugins that essentially perform the same task.

Do not „clean up“ the database directly with SQL commands“ #

The internet is full of SQL commands that supposedly remove revisions, metadata, options, or other WordPress data with a single click.

Such commands can be technically correct and still be unsuitable for your specific website.

An SQL command does not automatically consider:

• your installed plugins
• your individual table prefixes
• WooCommerce structures
• Custom Post Types
• Plugin dependencies
• custom data models

Therefore, do not copy unknown SQL commands from forums, blogs, or AI answers directly into a production database.

Attention: A single SQL command can permanently modify or delete thousands of records in seconds. Only use SQL for database cleanups if you know exactly which records are affected.

wp_postmeta can become very large #

For extensive WordPress websites, the table wp_postmeta often to the larger tables.

That is not automatically unusual. WordPress and plugins use post metadata for a lot of additional information.

Page Builders, WooCommerce, SEO plugins, and other extensions can store large amounts of legitimate data there.

A large wp_postmetatable is therefore no reason to delete data records across the board.

Check log and statistical data #

Some plugins store logs, statistics, or historical data directly in the WordPress database.

This may include, for example:

• Security protocols
• 404 Logs
• Email protocols
• Activity logs
• Statistical data
• Import and export logs
• Debug Information

If such data is stored indefinitely, the corresponding tables can grow considerably.

Therefore, check plugins with logging functions to see if a reasonable retention period can be configured.

Often it is better, for example, to retain only a defined period rather than storing technical logs for years that no one needs anymore.

Backups do not belong in the WordPress database #

Normal complete website backups are usually stored as files and therefore are not part of the actual WordPress database.

Nevertheless, backup plugins can save status information, logs, and configurations in the database.

If your hosting usage is unusually high, you shouldn't just check the database for that reason. Old backup archives in the file system can take up significantly more storage space than the database itself.

Why Database Cleanup Is Not a Daily Job #

A WordPress database does not need to be „cleaned“ every day.

WordPress and modern database systems are designed to work permanently with large amounts of structured data.

Too aggressive or permanently executed cleanup can even be counterproductive if, for example, useful temporary data is constantly removed or revisions that would be needed later are deleted.

For most standard websites, occasional checks as part of regular maintenance are sufficient.

When is a more detailed database analysis worthwhile? #

A more detailed examination is particularly useful if:

• die Datenbank ungewöhnlich stark gewachsen ist
• ein altes Plugin grosse Tabellen hinterlassen hat
• die Website seit vielen Jahren betrieben wird
• sehr viele Revisionen vorhanden sind
• ein Plugin grosse Mengen an Logs speichert
• WooCommerce-Hintergrundaufgaben auffällig anwachsen
• der WordPress-Adminbereich bei datenbankintensiven Aktionen langsam reagiert
• ein Performance-Tool auf langsame Datenbankabfragen hinweist
• die Hosting-Belegung untersucht werden soll

In solchen Fällen sollte zuerst festgestellt werden, welche Tabellen wachsen und warum. Erst danach wird entschieden, ob überhaupt etwas gelöscht werden sollte.

WordPress-Datenbank nach einer Plugin-Bereinigung kontrollieren #

Wenn du alte Plugin-Daten entfernt hast, solltest du die Website anschliessend gründlich testen.

Check in particular:

• Home
• important subpages
• WordPress admin area
• Forms
• Benutzer-Login
• Plugins mit Datenbankzugriff
• bei WooCommerce Warenkorb und Checkout

Bei einer Fehlermeldung solltest du nicht mit weiteren Bereinigungen fortfahren, sondern zuerst die Ursache untersuchen.

Was bringt eine Datenbankoptimierung für SEO? #

Das Löschen von Revisionen oder Transients verbessert dein Google-Ranking nicht direkt.

Eine technisch saubere Website kann jedoch indirekt relevant sein, wenn Datenbankprobleme tatsächlich zu langsamen Antwortzeiten, Fehlern oder einer schlechten Benutzererfahrung führen.

Du solltest eine Datenbankbereinigung deshalb nicht als „SEO-Trick“ betrachten.

Für SEO sind Inhalte, Suchintention, interne Verlinkung, technische Erreichbarkeit, Performance und zahlreiche weitere Faktoren wesentlich wichtiger als die Frage, ob deine Datenbank beispielsweise 80 oder 120 MB gross ist.

WordPress-Datenbank und Cache sind nicht dasselbe #

Die Begriffe Datenbank, Cache und Speicher werden häufig miteinander verwechselt.

The Database enthält dauerhaft gespeicherte strukturierte Informationen deiner Website.

A Cache hält dagegen normalerweise bereits erzeugte oder häufig benötigte Daten vor, damit sie schneller wiederverwendet werden können.

Das Löschen eines Caches und das Löschen von Datenbankinhalten sind deshalb zwei völlig unterschiedliche Vorgänge.

Ein Cache kann normalerweise neu aufgebaut werden. Ein gelöschter Beitrag oder eine entfernte Plugin-Konfiguration aus der Datenbank dagegen nicht ohne Weiteres.

Eine sinnvolle Reihenfolge für die Datenbankbereinigung #

Empfohlenes Vorgehen #

1. Aktuelles Backup erstellen beziehungsweise überprüfen.
2. Grösse der Datenbank und einzelnen Tabellen analysieren.
3. Ungewöhnlich grosse Tabellen identifizieren.
4. Prüfen, welche WordPress-Funktion oder welches Plugin die Daten erzeugt.
5. Offensichtlich nicht mehr benötigte Inhalte wie Papierkorb und Spam kontrollieren.
6. Alte Revisionen bei Bedarf reduzieren.
7. Abgelaufene temporäre Daten gegebenenfalls bereinigen.
8. Plugin-Logs und deren Aufbewahrungsdauer prüfen.
9. Verwaiste Plugin-Daten nur nach eindeutiger Identifikation entfernen.
10. Tabellen bei tatsächlichem Bedarf technisch optimieren.
11. Website und wichtige Funktionen anschliessend testen.

Was du nicht machen solltest #

• Tabellen löschen, nur weil sie gross sind
• unbekannte SQL-Befehle aus dem Internet ausführen
• ohne Backup direkt in phpMyAdmin experimentieren
• wp_options auf Verdacht bereinigen
• WooCommerce-Bestelldaten als „alte Daten“ löschen
• alle Revisionen automatisch als nutzlosen Datenmüll betrachten
• ständig sämtliche Transients löschen
• Plugin-Tabellen allein anhand ihres Namens entfernen
• eine Datenbankoptimierung als universelle Lösung für Performance-Probleme betrachten

Note: Bei einer Datenbankoptimierung gilt nicht „viel löschen = viel schneller“. Eine professionelle Bereinigung beginnt mit einer Analyse. Erst wenn du weisst, welche Daten vorhanden sind und warum, solltest du entscheiden, was entfernt werden kann.

Wann solltest du lieber nichts selbst löschen? #

Wenn du nicht sicher beurteilen kannst, welche Daten eine Tabelle enthält oder welches Plugin einen bestimmten Eintrag benötigt, solltest du die Daten nicht auf Verdacht entfernen.

Das gilt besonders bei produktiven WooCommerce-Shops, Mitglieder-Websites und geschäftskritischen WordPress-Installationen.

Als CURIAWEB-Kunde kannst du dich bei Unsicherheiten an unseren Support wenden. Teile uns möglichst genau mit, welche Website betroffen ist, welche Tabelle beziehungsweise Datenbank auffällig erscheint und warum du eine Bereinigung durchführen möchtest.

So lässt sich zuerst beurteilen, ob tatsächlich unnötige Daten vorliegen oder ob die Datenbankgrösse für die betreffende Website vollkommen normal ist.

Summary #

Eine WordPress-Datenbank wächst mit der Nutzung deiner Website. Beiträge, Seiten, Einstellungen, Benutzer, Kommentare und Plugin-Daten werden dort dauerhaft gespeichert. Zusätzlich können sich mit der Zeit Revisionen, Spam-Kommentare, abgelaufene Transients, Protokolle und Daten nicht mehr verwendeter Plugins ansammeln.

Eine grosse Datenbank ist jedoch nicht automatisch langsam oder fehlerhaft. Entscheidend ist, welche Daten gespeichert werden und ob sie weiterhin benötigt werden. Vor jeder grösseren Bereinigung solltest du deshalb ein aktuelles Backup besitzen und zunächst die betroffenen Tabellen analysieren.

Revisionen können begrenzt, Spam und Papierkorb-Inhalte entfernt und abgelaufene temporäre Daten bereinigt werden. Bei Plugin-Tabellen, verwaisten Metadaten und insbesondere wp_options ist dagegen grössere Vorsicht erforderlich. Bei WooCommerce dürfen geschäfts- und bestellrelevante Daten niemals auf Verdacht gelöscht werden.

Wenn du für die Analyse direkt mit phpMyAdmin arbeitest, hilft dir unsere Anleitung zum Arbeiten mit der WordPress-Datenbank über phpMyAdmin beim Verständnis von Datenbankname und Tabellenpräfix. Wie du nicht mehr benötigte Erweiterungen korrekt entfernst, erklären wir im Artikel Deactivate or delete WordPress plugins.