{"id":2144,"date":"2026-08-23T13:15:54","date_gmt":"2026-08-23T10:15:54","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=2144"},"modified":"2026-10-18T05:20:21","modified_gmt":"2026-10-18T02:20:21","slug":"wordpress-wp-postmeta-table-is-huge-causes-and-cleanup","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/wordpress-wp-postmeta-table-is-huge-causes-and-cleanup\/","title":{"rendered":"Why the WordPress wp_postmeta Table Gets So Large"},"content":{"rendered":"

Your wp_postmeta table is large because a handful of meta keys are large. It is almost never “WordPress in general”, and it is rarely the orphaned rows that cleanup guides start with. Find the keys first. The query takes a second, and it tells you whether you are looking at a page builder, a shop, an image library or a plugin you removed two years ago.<\/p>\n

Each of those gives you a different answer, and only some of them are deletions.<\/p>\n

Table of contents<\/strong><\/p>\n
    \n
  1. Measure it before you clean it<\/a><\/li>\n
  2. Which keys are usually the heavy ones<\/a><\/li>\n
  3. Orphaned rows: meta whose post is gone<\/a><\/li>\n
  4. Revisions carry meta too<\/a><\/li>\n
  5. Keys left behind by removed plugins<\/a><\/li>\n
  6. Deleting one key without collateral damage<\/a><\/li>\n
  7. Why the table does not shrink on disk<\/a><\/li>\n
  8. Verification<\/a><\/li>\n
  9. AIOWS Database Cleaner<\/a><\/li>\n
  10. FAQ<\/a><\/li>\n
  11. Sources<\/a><\/li>\n<\/ol>\n<\/div>\n

    Measure it before you clean it<\/h2>\n

    Run two read-only queries in phpMyAdmin, Adminer or your host’s database tool. Nothing below changes your data until the section on deleting.<\/p>\n

    First, check your table prefix. It is $table_prefix<\/code> in wp-config.php<\/code>, and it is often not wp_<\/code>. Every query in this article uses wp_<\/code>; replace it with yours.<\/p>\n

    How big is the table, and how much of it is free space?<\/p>\n

    SELECT table_name,\n       ROUND(data_length \/ 1048576, 1)  AS data_mb,\n       ROUND(index_length \/ 1048576, 1) AS index_mb,\n       ROUND(data_free \/ 1048576, 1)    AS free_mb,\n       table_rows\nFROM information_schema.tables\nWHERE table_schema = DATABASE()\n  AND table_name = 'wp_postmeta';<\/code><\/pre>\n
    table_rows<\/code> is an estimate for InnoDB tables. Use it to judge your scale, not for your before-and-after comparisons.<\/p>\n
    Which keys hold the space?<\/p>\n
    SELECT meta_key,\n       COUNT(*)                                   AS rows_count,\n       ROUND(SUM(LENGTH(meta_value)) \/ 1048576, 2) AS value_mb\nFROM wp_postmeta\nGROUP BY meta_key\nORDER BY value_mb DESC\nLIMIT 25;<\/code><\/pre>\n
    Write down your top five keys with their row counts and sizes. You will compare against this list at the end.<\/p>\n
    If every row shows 0.00, that is your answer too: your space is not in wp_postmeta<\/code>. The small test site for this article had 136 rows, and every key rounded to 0.00 MB.<\/p>\n
    Which keys are usually the heavy ones<\/h2>\n
    The prefix of a key tells you who wrote it. A leading underscore hides it from your custom-fields box. It does not tell you the key is unimportant.<\/p>\n
    \n\n\n\n\n\n\n\n\n\n\n\n\n
    Key pattern<\/th>\nWritten by<\/th>\nWhat it holds<\/th>\nSafe to delete?<\/th>\n<\/tr>\n<\/thead>\n
    _elementor_data<\/code>, _elementor_*<\/code><\/td>\nElementor<\/td>\nThe whole page layout as JSON, per page and per revision<\/td>\nNo. This is your page.<\/td>\n<\/tr>\n
    _wp_attachment_metadata<\/code><\/td>\nWordPress core<\/td>\nSizes and file names of every image size<\/td>\nNo. Images lose their sizes.<\/td>\n<\/tr>\n
    _oembed_<\/code>, _oembed_time_<\/em><\/code><\/td>\nWordPress core<\/td>\nCached embed HTML for pasted URLs<\/td>\nYes. WordPress fetches it again on the next view.<\/td>\n<\/tr>\n
    _edit_lock<\/code>, _edit_last<\/code><\/td>\nWordPress core<\/td>\nWho is editing, and who last edited<\/td>\nHarmless either way, and tiny.<\/td>\n<\/tr>\n
    _yoast_wpseo_<\/code>, rank_math_<\/em><\/code><\/td>\nSEO plugins<\/td>\nTitles, descriptions, scores<\/td>\nNo, while the plugin is in use.<\/td>\n<\/tr>\n
    _price<\/code>, _regular_price<\/code>, _sku<\/code>, _stock<\/code><\/td>\nWooCommerce<\/td>\nProduct data<\/td>\nNo.<\/td>\n<\/tr>\n
    _billing_<\/code>, _order_<\/em><\/code>, _customer_ip_address<\/code><\/td>\nWooCommerce, older order storage only<\/td>\nOrders and your customers’ details<\/td>\nNo.<\/td>\n<\/tr>\n
    anything from a plugin you removed<\/td>\nthat plugin<\/td>\nits settings per post<\/td>\nOnly after the check in Keys left behind<\/a>.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
    If your top key is a page builder’s, the table is large because your pages are large. Deleting will not fix that for you; trimming revisions might. If it is _oembed_*<\/code>, you can clear it safely. If it is a key you do not recognise, read the leftovers section before you touch it.<\/p>\n
    If you run a shop, check where WooCommerce keeps your orders before you read order keys in this list. You find it under WooCommerce<\/strong> > Settings<\/strong> > Advanced<\/strong> > Features<\/strong>, as “Order data storage”. On the test site with WooCommerce 11.2.1: – with WordPress posts storage (legacy)<\/strong>, one order wrote 25 rows to   wp_postmeta<\/code>, six of them _billing_*<\/code>; – with High-performance order storage<\/strong>, a new order wrote none. Its address   went to the wc_order_addresses<\/code> table instead.<\/p>\n
    Products keep their meta in wp_postmeta<\/code> either way. Switching to the new storage left the old order’s rows where they were, and WooCommerce listed that order as one to clean up.<\/p>\n
    Orphaned rows: meta whose post is gone<\/h2>\n
    An orphaned row has a post_id<\/code> that no longer exists in wp_posts<\/code>. WordPress does not create them on its own: when you delete a post, wp_delete_post()<\/code> deletes its meta with it. Orphans come from posts someone removed by SQL, from imports that failed halfway, and from plugins that delete their own post types the wrong way.<\/p>\n
    Count them before you assume you have any:<\/p>\n
    SELECT COUNT(*) AS orphaned_rows,\n       ROUND(SUM(LENGTH(pm.meta_value)) \/ 1048576, 2) AS orphaned_mb\nFROM wp_postmeta pm\nLEFT JOIN wp_posts p ON p.ID = pm.post_id\nWHERE p.ID IS NULL;<\/code><\/pre>\n
    If the result is a few hundred rows and a fraction of a megabyte, orphans are not your problem. Clean them anyway if you like, but go back to the key list. If the result is a large share of the table, you have found your cause.<\/p>\n
    If you want to check the other meta tables too, how to find orphaned metadata in WordPress<\/a> walks you through them.<\/p>\n
    Revisions carry meta too<\/h2>\n
    Every revision you save is a row in wp_posts<\/code> with post_type = 'revision'<\/code>. Page builders store a copy of their layout meta against many of those revisions. If your page has 60 revisions, it can carry 60 copies of its _elementor_data<\/code>.<\/p>\n
    Count them per parent before you delete anything:<\/p>\n
    SELECT p.post_parent, COUNT(*) AS revisions\nFROM wp_posts p\nWHERE p.post_type = 'revision'\nGROUP BY p.post_parent\nORDER BY revisions DESC\nLIMIT 10;<\/code><\/pre>\n
    Delete your revisions through WordPress, a plugin or WP-CLI, not with a bare DELETE FROM wp_posts<\/code>. The WordPress route removes their meta with them. The SQL route leaves that meta behind as orphans, and you are back in the previous section.<\/p>\n
    To stop the growth, set a limit in your wp-config.php<\/code>:<\/p>\n
    define( 'WP_POST_REVISIONS', 10 );<\/code><\/pre>\n
    You will find the full procedure in how to delete old WordPress post revisions safely<\/a>.<\/p>\n
    Keys left behind by removed plugins<\/h2>\n
    This is where you can get hurt. A key you do not recognise looks like rubbish, and sometimes it belongs to something you still run: a theme option, a snippet in your functions.php<\/code>, or a plugin whose name has nothing in common with the key.<\/p>\n
    Before you delete a key, establish three things:<\/p>\n
      \n
    1. Who wrote it.<\/strong> Search your installed code for the key name. With WP-CLI    or shell access: grep -r \"your_meta_key\" wp-content\/<\/code>. If you get no result    in wp-content<\/code>, that is a strong sign that nothing active reads it.<\/li>\n
    2. That nothing reads it.<\/strong> A result in a plugin you no longer use is fine.    A result in your active theme or a must-use plugin means stop.<\/li>\n
    3. How many posts carry it.<\/strong> A key on every one of your posts is a setting.    A key on twelve posts from 2019 is a leftover.<\/li>\n<\/ol>\n
      Deactivating a plugin does not remove its meta. When you delete it through the Plugins screen, you run its uninstall routine, if it has one. Many plugins do not.<\/p>\n
      Deleting one key without collateral damage<\/h2>\n
      Take a database backup first, and make sure you can restore it. That is the step that makes every other mistake here recoverable. If you have not restored one before, create a WordPress database backup and verify the SQL export<\/a> shows how.<\/p>\n
      Then work one key at a time. Run your SELECT<\/code> and read its count. Then run your DELETE<\/code> with exactly the same WHERE<\/code>:<\/p>\n
      SELECT COUNT(*) FROM wp_postmeta WHERE meta_key = 'old_plugin_key';\n\nDELETE FROM wp_postmeta WHERE meta_key = 'old_plugin_key' LIMIT 5000;<\/code><\/pre>\n
      Repeat the DELETE<\/code> until it reports 0 affected rows. The LIMIT<\/code> keeps each statement short, so your shared host’s query timeout does not stop it halfway. If a long run stops anyway, see database cleanup stuck or timed out<\/a>.<\/p>\n
      For cached embeds, use a pattern rather than a list:<\/p>\n
      DELETE FROM wp_postmeta WHERE meta_key LIKE '\\_oembed\\_%' LIMIT 5000;<\/code><\/pre>\n
      You need the backslashes. In LIKE<\/code>, an unescaped underscore matches any single character, so '_oembed_%'<\/code> also matches keys you did not mean.<\/p>\n
      Why the table does not shrink on disk<\/h2>\n
      After a large delete, you will often see the table’s data size stay the same. InnoDB keeps the freed pages for reuse instead of returning them to your file system. The first query in this article shows them to you as free_mb<\/code>.<\/p>\n
      OPTIMIZE TABLE wp_postmeta;<\/code> rebuilds the table and gives that space back when your server stores each table in its own file. That is the default on current MySQL and MariaDB. On a big table the rebuild takes time and may lock your writes while it runs, so do it at a quiet hour. How to optimize WordPress database tables safely<\/a> gives you the details.<\/p>\n
      You do not need to optimize after every cleanup. Free space inside the table is reused by your next inserts. It only matters when you need the disk back, for example because a backup fails because the disk is full<\/a>.<\/p>\n
      Verification<\/h2>\n
      Your cleanup is finished when the numbers moved and the site did not.<\/p>\n
      \n\n\n\n\n\n\n\n\n
      Check<\/th>\nExpected<\/th>\n<\/tr>\n<\/thead>\n
      Run the key-size query again<\/td>\nThe keys you deleted are gone from the list. The others have the same row counts as before.<\/td>\n<\/tr>\n
      Run the orphan count again<\/td>\n0, if you cleaned orphans.<\/td>\n<\/tr>\n
      Open three pages: one built with your page builder, one with images, and one product if you run a shop<\/td>\nAll three look exactly as before.<\/td>\n<\/tr>\n
      Pick one meta row of a live post that you did not target, and count its key before and after<\/td>\nMust not change.<\/strong> If it dropped, your WHERE<\/code> was wider than you thought. Restore the backup.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n
      The last row is the one you cannot skip. A cleanup that removes the right rows proves nothing on its own. It has to leave the wrong rows alone too, and only a before-and-after count of a key you did not target shows that.<\/p>\n
      On the test site the fourth row held both times. After a Database Cleaner run, the untargeted key stayed at 7 rows and a decoy key that an unescaped pattern would match stayed at 1. After the manual DELETE<\/code> above, typed exactly as printed, 3 rows went, the untargeted key stayed at 14 and the decoy at 2. Without the backslashes, the same pattern matched 5 rows, the decoys included.<\/p>\n
      \n
      How AIOWS helps:<\/p>\n
      AIOWS Database Cleaner<\/h2>\n
      Database Cleaner takes the routine part of this article off your hands, so your attention goes to the part that needs it.<\/p>\n
      It runs the deletions that need no judgement.<\/strong> Two of its eleven tasks are the safe ones from this article. Orphaned Post Meta removes the wp_postmeta<\/code> rows whose post no longer exists, and nothing else. oEmbed Cache removes the _oembed_<\/code> keys with the underscore escaped, so the LIKE<\/code> trap above cannot catch you. Post Revisions deletes through WordPress itself, which takes each revision’s meta with it. It can also keep the newest revisions of every post.<\/p>\n
      It shows you the count first.<\/strong> Each task shows how many rows it would remove, counted with the same conditions as the delete. You cannot select a task that has nothing to remove. Before Orphaned Post Meta runs, the confirmation lists the keys with the most orphaned rows and the post IDs they pointed to. That is your last look at what the orphans were.<\/p>\n
      It backs up first, every time.<\/strong> Each cleanup starts with a backup of the tables it touches. If that backup cannot be written, nothing is deleted.<\/p>\n
      It keeps optimizing separate.<\/strong> Optimize Tables is its own button. Run your cleanup, compare your numbers, and give the disk space back when you choose.<\/p>\n
      \"Database
      Every task shows its count before you select it.<\/figcaption><\/figure>\n
      The confirmation for Orphaned Post Meta read, word for word:<\/p>\n
      This action will first create a database backup, then permanently delete the selected items. Are you sure?\n\nOrphaned post meta rows that will be deleted, by key:\norphan_test_0 \u00d717\norphan_test_1 \u00d717\norphan_test_2 \u00d716\npost IDs 100.006\u2013100.010, 5 objects<\/code><\/pre>\n
      Its limits, stated plainly. It does not decide which meta keys of your live posts are leftovers. Keys left by removed plugins, duplicate rows, and orphaned term or user meta are not among its tasks. Those stay with you, one key at a time, as the leftovers section describes. It does not delete trashed media, because a database backup cannot bring the files back. Empty the Media Library trash yourself. And it cannot tell you why your table grew. The key-size query at the top of this article does that, and it is worth running before any tool.<\/p>\n
      Explore AIOWS Database Cleaner<\/a>Compare AIOWS plans<\/a><\/p>\n<\/section>\n
      FAQ<\/h2>\n
      Is a 500 MB wp_postmeta table a problem?<\/strong> Not by itself. It matters when your queries that read it get slow, or when your backups and disk suffer. The key list tells you whether the size is content you need or data you can drop.<\/p>\n
      Can I delete all meta keys that start with an underscore?<\/strong> No. The underscore only hides a key from your custom-fields box. Your images, page layouts and shop data all live in underscore keys.<\/p>\n
      Will deleting orphaned postmeta break anything?<\/strong> No, if your query joins on wp_posts<\/code> as above. An orphaned row belongs to no post, so nothing on your site can display it.<\/p>\n
      Why is the table still the same size after cleanup?<\/strong> InnoDB keeps the freed space inside the file. OPTIMIZE TABLE<\/code> gives it back. See Why the table does not shrink on disk<\/a>.<\/p>\n
      Does a big wp_postmeta table slow down my site?<\/strong> It can slow down your queries that filter by meta value, such as some shop and search queries. Pages you serve from a cache are not affected. Measure before you conclude that it does.<\/p>\n
      Sources<\/h2>\n