Database tables
The database stores your site in tables, each for one kind of data. WordPress brings a fixed set of its own, for posts, comments, users, categories and tags, and settings. Many plugins add tables for their own data: a shop for orders, a form plugin for entries, a security plugin for its log.
Why it matters
Section titled “Why it matters”The number of tables doesn’t make pages slower by itself; WordPress only reads the tables a page needs. It’s a sign of how much has been added to the site over time. Plugins often leave their tables behind when they’re deleted, so a site with many more tables than active plugins can explain usually carries leftovers. They take up space, make backups and moves larger, and make it harder to see what belongs to what.
What influences it
Section titled “What influences it”WordPress: The most common reason for many tables is plugins: those that are active, and those that were removed without deleting their data. Some plugins create several tables at once. A second WordPress installation in the same database has its own tables, under a different prefix.
In Permo
Section titled “In Permo”The Tables card is in System info, tab Database, under Database server. It counts the
tables that start with this site’s table prefix, such as wp_, including those of plugins and of
Permo itself, and names the prefix in the note. Tables of other sites in the same database don’t
count. One limit, the same as for the database size: if a second
installation uses a prefix that starts with this site’s prefix, such as wp_shop_ next to wp_,
its tables count as well.
The Tables section further down lists the largest tables with their size, on request. The value on the card gives context; Permo doesn’t rate it.