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:

• the database has grown unusually large
• an old plugin has left behind large tables
• the website has been running for many years
• there are a very large number of revisions
• a plugin stores large amounts of logs
• WooCommerce background tasks growing noticeably
• the WordPress admin area responds slowly during database-intensive operations
• a performance tool points out slow database queries
• hosting allocation should be investigated

In such cases, it should first be determined whether, which tables are growing and why. Only after that is it decided whether anything should be deleted at all.

Check WordPress database after plugin cleanup #

After removing old plugin data, you should thoroughly test the website afterwards.

Check in particular:

• Home
• important subpages
• WordPress admin area
• Forms
• User Login
• Plugins with database access
• in WooCommerce cart and checkout

In the event of an error message, you should not proceed with further cleanups, but investigate the cause first.

What are the benefits of database optimization for SEO? #

Deleting revisions or transients does not directly improve your Google ranking.

However, a technically sound website can be indirectly relevant if database issues actually lead to slow response times, errors, or a poor user experience.

You should therefore not view database cleaning as an „SEO trick“.

For SEO, content, search intent, internal linking, technical accessibility, performance, and numerous other factors are much more important than the question of whether your database is, for example, 80 or 120 MB in size.

WordPress database and cache are not the same #

The terms database, cache, and storage are often confused with one another.

The Database contains permanently stored structured information of your website.

A Cache normally holds already generated or frequently required data in store so that they can be reused more quickly.

Clearing a cache and deleting database contents are therefore two completely different processes.

A cache can normally be rebuilt. A deleted post or removed plugin configuration from the database, on the other hand, cannot be easily.

A logical order for database cleanup #

Recommended approach #

1. Create or check current backup.
2. Analyze the size of the database and individual tables.
3. Identify unusually large tables.
4. Check which WordPress function or plugin generates the data.
5. Check contents that are obviously no longer needed, such as the trash and spam.
6. Reduce old revisions if necessary.
7. Clean up expired temporary data if necessary.
8. Check plugin logs and their retention period.
9. Remove orphaned plugin data only after explicit identification.
10. Technically optimize tables when there is an actual need.
11. Then test the website and important functions.

What you should not do #

• Deleting tables just because they are large
• execute unknown SQL commands from the internet
• experimenting directly in phpMyAdmin without a backup
• wp_options purge on suspicion
• Delete WooCommerce order data as „old data“
• consider all revisions automatically as useless data garbage
• constantly delete all transients
• Remove plugin tables based solely on their name
• consider database optimization as a universal solution for performance issues

Note: When optimizing a database, the rule „delete a lot = much faster“ does not apply. Professional cleanup begins with an analysis. Only when you know, what data is available and why, you should decide what can be removed.

When should you prefer not to delete anything yourself? #

If you cannot reliably determine what data a table contains or which plugin requires a specific entry, you should not remove the data on suspicion.

This is especially true for production WooCommerce stores, membership websites, and mission-critical WordPress installations.

As a CURIAWEB customer, you can contact our support if you have any questions or uncertainties. Please let us know as precisely as possible which website is affected, which table or database appears abnormal, and why you would like to perform a cleanup.

This makes it possible to first assess whether unnecessary data is actually present or whether the database size is completely normal for the website in question.

Summary #

A WordPress database grows as you use your website. Posts, pages, settings, users, comments, and plugin data are permanently stored there. In addition, revisions, spam comments, expired transients, logs, and data from unused plugins can accumulate over time.

However, a large database is not automatically slow or faulty. The crucial factors are what data is stored and whether it is still needed. Therefore, before any major cleanup, you should have a current backup and first analyze the affected tables.

Revisions can be limited, spam and trash contents removed, and expired temporary data cleaned up. In the case of plugin tables, orphaned metadata, and especially wp_options greater caution is required against this. With WooCommerce, business- and order-relevant data must never be deleted on suspicion.

If you work directly with phpMyAdmin for the analysis, our guide on helps you Working with the WordPress database via phpMyAdmin in understanding database name and table prefix. We explain how to correctly remove extensions you no longer need in the article Deactivate or delete WordPress plugins.