A default WordPress install creates 12 WordPress database tables, and every one of them starts with the wp_ prefix unless you changed it. They hold your posts, comments, users, settings and taxonomy terms, and nothing else is needed for a working site.
I checked that number myself in October 2026 rather than copying it from an older guide. I ran wp core install for WordPress 7.1.3 on a clean MySQL 8.0.35 database. Then I counted the tables with WP-CLI and with plain SQL. I also built a multisite network and a WooCommerce 11.2 store to see how the count grows.
If WP-CLI or the mysql client cannot connect before you count anything, learn how to fix MySQL error 2003 first.
Below you get the full WordPress database tables list with what each one stores and the column count of each. You also get three ways to check your own site. You also get the real numbers for multisite and WooCommerce, plus the mistake that makes many people count the wrong number.
How Many WordPress Database Tables Are There by Default?
WordPress creates 12 WordPress database tables on a fresh single site install, and that number has not changed in years. My clean WordPress 7.1.3 test returned exactly 12 tables from wp db tables. Any extra table you see on your own site came from a plugin, a theme, multisite or a hosting tool.
Here is the full set of WordPress default tables, grouped by the job they do:
The count comes from the schema file that ships with core. WordPress defines every table in wp-admin/includes/schema.php and returns that list through the wp_get_db_schema() function. In that file, 10 tables belong to each site and 2 tables, users and usermeta, are global.
The global part matters later on multisite. One users table serves the whole network. A second site never gets its own login table.
This is what the clean install printed in my terminal. The command lists the tables WordPress has registered on the $wpdb object:
Note: Older articles sometimes name tables like wp_categories or wp_post2cat. Those came from very old versions, and core still lists them only as “old tables” in its database class. A modern install never creates them.
What Each Default Table Stores
Each default table stores one kind of data, and most of them come in pairs: a main table plus a meta table for extra fields. Posts pair with postmeta, comments with commentmeta, users with usermeta and terms with termmeta. The remaining four tables handle settings, taxonomy links and the old link manager.
wp_posts and wp_postmeta
The wp_posts table holds far more than blog posts. Pages, menu items, media attachments, revisions, reusable blocks and custom post types all live here, told apart by the post_type column. My fresh install held 3 rows: “Hello world!”, “Sample Page” and a draft “Privacy Policy” page.
The wp_postmeta table stores extra fields as key and value pairs. Page templates, image sizes and plugin fields such as a product price all end up in this table. It started with 2 rows on my test site, and on a busy store it can grow into the hundreds of thousands.
If you ever wondered where images are stored in the WordPress database, the answer is this pair. The file sits on disk, while its attachment row and metadata sit in these two tables.
wp_comments and wp_commentmeta
The wp_comments table holds every comment, pingback and trackback, with the author name, email, IP address and approval status. A fresh install ships with one sample comment on the “Hello world!” post. The wp_commentmeta table keeps extra data, such as notes that anti-spam plugins attach to a comment.
wp_users and wp_usermeta
The wp_users table stores the login, hashed password, email and display name for each account. Everything else about a user goes into wp_usermeta. My single admin account already had 16 meta rows, including wp_capabilities, which is where the administrator role is saved.
That role lookup is worth knowing. A role is not a column on the users table. Changing a role by hand means editing a usermeta row. The query below shows the serialized administrator value stored for user 1.
wp_terms, wp_termmeta, wp_term_taxonomy and wp_term_relationships
Four tables handle categories and tags. The wp_terms table stores the name and slug, while wp_term_taxonomy says whether that term is a category, a tag or a custom taxonomy. The wp_term_relationships table links each post to its terms, and wp_termmeta stores extra term fields.
The split looks odd at first, but it lets one term name exist in two taxonomies. My clean site had one term, “Uncategorized”, with a count of 1. Joining the two main tables shows it:
wp_options and wp_links
The wp_options table stores site settings: the site URL, the active theme, the active plugins list, widget settings and cached transients. My fresh install held 107 option rows before a single plugin was added. Of those, 98 were set to autoload on, 2 to auto and 7 to off.
The wp_links table is a leftover from the old Links feature. It still gets created, yet the 7.1.3 admin showed no Links menu at all, and the table held 0 rows.
WordPress Table Structure: Columns in Each Table
The WordPress table structure is small. Most tables have only 3 to 6 columns and only three tables pass ten. The wp_posts table is the widest with 23 columns. Every meta table uses the same 4 column shape. Once you know one, you know all four.
I pulled the column counts from the MySQL information schema on the clean install. The query filters out WooCommerce tables because I added the plugin to that database later in the test:
The meta tables share this layout: an ID, the parent object ID, meta_key and meta_value. That is why plugins can add almost any data without new tables, and also why postmeta gets slow on large sites.
The two big tables are worth a closer look:
WooCommerce adds its own order tables, and you need them if you ever mark WooCommerce orders complete with MySQL.
- wp_posts (23 columns): Holds the title, content, excerpt, status, author, dates, slug, parent ID, menu order and post type.
- wp_comments (15 columns): Holds the comment text, author details, IP, date, approval flag, agent string and parent comment.
- wp_links (13 columns): Holds the URL, name, image, target, description, visibility and rating of each old blogroll link.
- wp_users (10 columns): Holds the login, password hash, nicename, email, URL, registration date and display name.
Every table uses the InnoDB engine and the utf8mb4_unicode_520_ci collation on my MySQL 8.0.35 test. The wpdb class reference documents the properties that hold each table name, such as $wpdb->posts and $wpdb->options.
How to Check Your Own WordPress Tables List
You can check your own WordPress tables list in about two minutes with WP-CLI, a SQL query, or the Site Health screen in the dashboard. WP-CLI is the fastest, SQL works in phpMyAdmin on any host, and Site Health shows the table prefix without any tools. Pick whichever access your host gives you.
- Run WP-CLI from the site folder: Type
wp db tablesto see the tables WordPress has registered. Add--all-tablesto see every table in the database, including ones plugins left behind.
- Count rows with SQL: Open phpMyAdmin or the MySQL client and run a
COUNT(*)query per table, as in the output below. On my clean site the options table held 107 rows and the links table held none.
- Open Site Health in the dashboard: Go to Tools > Site Health > Info tab and open the Database panel. It shows the server version, database name, charset and the table prefix in use.
- Confirm the prefix in wp-config.php: Run
wp db prefixor searchwp-config.phpfor$table_prefix. Every table name starts with that value.
phpMyAdmin is the same check with a mouse. Open the database named in Site Health, and the left sidebar lists every table with your prefix, along with its row count and size.
The wp db tables command explains the difference between those flags. Without a flag, you only see tables registered on $wpdb, which is why my WooCommerce test site still printed 12 tables later on.
Tip: Back up the database before you open phpMyAdmin with write access. WordPress keeps a short guide to backing up your database, and a single wrong click on Drop deletes a table for good.
Why Your Site Shows More Than 12 Tables
Most live sites show far more than 12 WordPress database tables, because plugins, multisite and hosting tools all add their own. My WooCommerce 11.2 test store had 52 tables, and a two site network had 28. The extras are normal, and most of them are safe to leave alone.
Here is how the count changed across my three test installs:
Multisite Adds 6 Network Tables Plus 10 per Site
Turning on multisite added 6 network tables to my install: wp_blogs, wp_blogmeta, wp_site, wp_sitemeta, wp_signups and wp_registration_log. That took the count from 12 to 18 before any subsite existed. The steps for creating a network are in the WordPress advanced administration handbook.
Each new subsite then gets its own 10 tables with a numbered prefix. My second site created wp_2_posts, wp_2_options and eight more. The total reached 28.
The users and usermeta tables stay shared across the network. On multisite the users table also gains 2 columns named spam and deleted. That gives it 12 columns instead of 10.
WooCommerce Adds 40 Tables
WooCommerce 11.2 added 40 tables to my clean site, which took it from 12 to 52. They cover orders, order items, tax rates, shipping zones, sessions, webhooks, API keys, download permissions, Action Scheduler jobs and analytics lookups. Four of them are the High-Performance Order Storage tables: wp_wc_orders, wp_wc_orders_meta, wp_wc_order_addresses and wp_wc_order_operational_data.
One result surprised me. Activating WooCommerce through WP-CLI created 36 tables, and the four HPOS tables only appeared when the full WooCommerce installer ran. So a count taken right after activation can differ from a store that has loaded its admin once.
Deactivating WooCommerce removed none of its tables. The count stayed the same, and only --all-tables showed them, since plain wp db tables went back to 12.
If you run a store, these tables are what your WooCommerce database backup needs to cover. Missing one of them on a restore can lose orders or tax settings.
Other Plugins and Leftover Tables
Plenty of plugins create tables, and many keep them after you delete the plugin. Installing WP-Optimize 4.7.0 on my test site added 3 tables, wp_tm_tasks, wp_tm_taskmeta and wp_wpo_404_detector, for a total of 55. Plugins that store their own records, from forms to WordPress chatbot plugins that keep chat logs, may add tables too.
WP-Optimize also shows which plugin owns each table. On my test site it flagged every WooCommerce table as belonging to an inactive plugin and offered a Remove button for each one.
Only remove a leftover table when you are sure you will not reinstall that plugin. Removing WooCommerce tables, for example, deletes every order if the store ever comes back.
Default Tables and Site Security
The default table names are public knowledge. Attackers who find an SQL injection hole know exactly which tables to target. Changing the wp_ prefix hides the names from automated scripts that assume the default. It does not fix the hole itself. Treat it as one small layer.
The prefix lives in wp-config.php, and the wp-config.php guide explains the $table_prefix setting. Changing it on a live site means renaming every table and updating rows that store the prefix, such as wp_capabilities in usermeta.
That last part trips people up. If you rename the tables but skip the meta keys, your admin account loses its role. DevDiggers has a full guide on changing the WordPress database prefix safely.
Two other habits do more than a new prefix. Keep plugins updated, since an injection bug usually lives in plugin code that builds its own queries. Give the database user only the rights WordPress needs to read and write its own tables.
Also keep phpMyAdmin behind your hosting login and never on a public URL of its own. A database tool that anyone can reach turns a known table name into a short path to your data.
A tidy database is part of regular upkeep, along with updates, backups and uptime checks. A WordPress care plan bundles those jobs if you would rather not run them yourself.
Common Mistakes When Counting WordPress Tables
Most wrong answers about WordPress database tables come from counting the wrong thing. People count only registered tables, mix up multisite and single site numbers, or trust an old guide that lists retired tables. Each mistake gives a different number, which is why you see 11, 12 and 20 quoted online.
- Trusting plain wp db tables: It lists only tables registered on
$wpdb. My store with 52 tables printed 12. Add--all-tablesfor the real total. - Counting during WooCommerce activation: A CLI activation gave me 48 tables, and the full installer brought it to 52. Load the store admin once before you count.
- Forgetting the custom prefix: A site with the prefix
xyz_still has 12 core tables. Search for your own prefix in phpMyAdmin instead ofwp_. - Deleting tables of deactivated plugins: Deactivation leaves data in place on purpose. Delete a plugin’s tables only after you have decided never to use it again.
- Mixing up rows and tables: Some tools show a row total next to the table list. My fresh site had 107 option rows in one table, which is not the same as 107 tables.
A quick sanity check helps. Count the tables that start with your prefix and carry no plugin name. You should land on 12 for a single site or 18 for a fresh network.
If the number is lower than 12, something is wrong. A missing core table usually means a failed install or a broken migration. Restore from a backup before you edit anything.
Core files are never stored in these tables. Templates such as index.php in WordPress sit on disk. A database export does not include your theme or plugin code.
Conclusion
A fresh install creates 12 WordPress database tables, and I confirmed that count on WordPress 7.1.3 in October 2026. Ten tables belong to each site, and the users and usermeta tables are shared on multisite.
Real sites have more. Multisite added 6 network tables plus 10 per site in my test, and WooCommerce 11.2 added 40 more. Deactivating a plugin left all of its tables behind.
To check your own site, run wp db tables --all-tables or look up the prefix under Tools > Site Health. Back up first before you touch any table by hand.
Frequently Asked Questions (FAQs)
Q1. How many tables does WordPress create by default?
WordPress creates 12 tables on a fresh single site install. My WordPress 7.1.3 test in October 2026 returned exactly 12, all with the wp_ prefix.
Q2. What are the main WordPress default tables?
The most used ones are wp_posts, wp_postmeta, wp_options, wp_users and wp_usermeta. The other seven store comments, taxonomy terms and the old link manager data.
Q3. Can I delete the wp_links table?
It is safe to leave alone, and deleting it gains you almost nothing. My clean install held 0 rows in it, and core creates it again on every new install anyway.
Q4. Why does phpMyAdmin show more tables than WP-CLI?
The plain wp db tables command only lists tables WordPress has registered. phpMyAdmin shows every table in the database. Add --all-tables to WP-CLI to see the same full list.
Q5. Does WooCommerce delete its tables when I deactivate it?
No. In my WooCommerce 11.2 test the table count stayed the same after deactivation. All 40 of its tables and every order stayed in the database.
Q6. Which WordPress table stores passwords?
The wp_users table stores each password in the user_pass column as a hash, never as plain text. Roles and permissions are stored separately in wp_usermeta.
