{"id":13632,"date":"2026-10-24T07:35:00","date_gmt":"2026-10-24T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=13632"},"modified":"2026-10-24T06:36:04","modified_gmt":"2026-10-24T04:36:04","slug":"2483-revisions-for-926-posts-what-really-fills-a-wordpress-database","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/wordpress-plugins-tricks\/tutorials-en-wordpress-plugins-tricks\/2483-revisions-for-926-posts-what-really-fills-a-wordpress-database\/","title":{"rendered":"WordPress Revisions: Storage, Limits and Reliable Measurement"},"content":{"rendered":"

WordPress revisions retain editing states for comparison and restoration. That history also adds data to the database. A large revision count alone proves neither a defect nor a slow website.<\/p>\n

A read-only measurement of this website on 24 October 2026 at 04:19 UTC<\/strong> found 7,635 revisions among 12,284 rows in the posts table. Revisions accounted for about 79.4 percent of the stored content bytes. This dated snapshot replaces the earlier, now outdated figures.<\/p>\n

\"Revision
Measurement on 24 October 2026, 04:19 UTC: 7,635 revisions; 79.4% of post_content bytes. This is not a disk-space or speed benchmark.<\/figcaption><\/figure>\n

What WordPress actually stores<\/h2>\n

By default, a revision stores the title, content and excerpt. WordPress saves the current editing state in a separate row linked to the post. Further edits turn that snapshot into an older state. Appropriately registered metadata can also participate in revisions. A revision is nevertheless not a complete backup of every post property or the entire website.<\/p>\n

Not every save creates a revision. The post type must support revisions, revisions must be enabled, and the relevant fields normally need to have changed. Filters can modify this behaviour. A script touching 300 posts therefore does not necessarily create 300 revisions. Direct SQL updates bypass the normal WordPress workflow entirely.<\/p>\n

Autosaves work differently: WordPress maintains an autosave per post and user. An existing autosave is updated; an autosave matching the saved post can be removed.<\/p>\n

Count rows instead of relying on estimates<\/h2>\n

The measured table uses InnoDB. For this storage engine, information_schema.TABLES.TABLE_ROWS<\/code> can be an estimate. During the measurement, the overview reported 10,649 rows, while a direct count returned 12,284. That difference is not evidence of missing records.<\/p>\n

The direct count found 7,635 revisions, 2,958 attachments, 1,689 posts and pages, and two other records for global styles and navigation. The 1,689 posts and pages cover all statuses, including drafts, scheduled posts and trash. Only 1,290 posts and pages were published. An attachment record also does not represent every automatically generated image file.<\/p>\n

\n\"Symbolic
\n<\/figure>\n

Content size is not file size<\/h2>\n

OCTET_LENGTH(post_content)<\/code> measured 92,563,135 bytes in revisions and 23,963,672 bytes in posts and pages: about 88.3 and 22.9 MiB respectively. One MiB equals 1,048,576 bytes. The two remaining records contained another 74 bytes combined; attachments had empty content fields in this measurement. Attachments can contain descriptions in other cases.<\/p>\n

This query measures only the post_content<\/code> column. Titles, other columns, metadata, indexes and already allocated table space are excluded. Consequently, 88.3 MiB of revision content does not establish that 88.3 MiB of disk space can be reclaimed or that compressed backups would shrink by the same amount.<\/p>\n

Where the costs appear<\/h2>\n

Normal public post queries exclude revisions. That does not guarantee identical loading times with and without revisions: queries, indexes, caches, extensions and administration screens can behave differently. This review contains no comparative loading-speed benchmark.<\/p>\n

Additional records increase the content of logical database exports. Backup and transfer times also depend on compression, storage and export methods. Three times as much content does not automatically require three times as long to copy.<\/p>\n

Choose a retention policy<\/h2>\n

WP_POST_REVISIONS<\/code> controls ordinary revision retention. true<\/code> or -1<\/code> means unlimited; a positive integer limits revisions per post; false<\/code> or 0<\/code> disables ordinary revisions. Autosaves are exempt. The measured installation used true<\/code>. WordPress filters can change the effective limit.<\/p>\n

A suitable limit depends on editing frequency and the depth of history required for restoration. Three to five versions is not a universal recommendation. Before extensive changes, a verified backup and an understandable change log complement the revision history.<\/p>\n

\n

Questions and answers<\/h2>\n

Does a new limit immediately remove all old revisions?<\/h3>\n

No. Normal trimming happens per post during the creation of a new revision. A configuration change or an unchanged save does not automatically clean the entire collection. Disabling ordinary revisions does not delete existing revisions either.<\/p>\n

Why avoid deleting directly from the posts table?<\/h3>\n

A standalone SQL DELETE can leave associated metadata and cache entries behind. wp_delete_post_revision()<\/code> uses the normal WordPress deletion workflow, including related cleanup. Removing old revisions requires a verified backup and an explicitly defined selection. No revisions were deleted during this measurement.<\/p>\n

Does deletion shrink the table file?<\/h3>\n

Not necessarily. InnoDB can reuse freed space internally. Whether rebuilding returns space to the filesystem depends partly on the tablespace and configuration. Rebuilding can require additional space and maintenance time; this does not justify a blanket OPTIMIZE TABLE command.<\/p>\n

Which query shows the distribution?<\/h3>\n

The following read-only query separates post type and status. The wp_<\/code> prefix must match the actual table prefix.<\/p>\n

SELECT post_type, post_status,\n       COUNT(*) AS row_count,\n       COALESCE(SUM(OCTET_LENGTH(post_content)), 0) AS content_bytes\nFROM wp_posts\nGROUP BY post_type, post_status\nORDER BY post_type, post_status;<\/code><\/pre>\n
The byte count covers only the content field. During ongoing editing, successive queries can capture different snapshots.<\/p>\n<\/div>\n
\n
Sources<\/h2>\n