WordPress and nearly all plugins store their settings in a unique location on your server named the “database.” Data stored in the database is organized in so-called ‘tables.’ This article will explain the meaning of all the available fields of the default WordPress Database structure in detail.
TL;DR: WordPress stores most site data in a MySQL or MariaDB database. A standard single-site WordPress installation currently uses 12 default tables with a configurable prefix, commonly
wp_. These tables store posts, pages, users, settings, comments, taxonomy terms, and metadata, while plugins, themes, WooCommerce, and multisite installations can add more tables.
Note: To safely inspect your WordPress database, back up your site or create a staging environment using WP STAGING. Then, use a database management tool, such as phpMyAdmin or Adminer, to access and modify the database without impacting your live site.
Contents
- WordPress Database Tables at a Glance
- How do Database Tables Look Like?
- List of WordPress Core Tables
- wp_options
- wp_users,wp_usermeta
- wp_posts,wp_postmeta
- wp_terms,wp_term_relationships,wp_term_taxonomy, wp_termmeta
- wp_comments,wp_commentmeta
- wp_links
- Upcoming WordPress 7.0 Table: wp_collaboration
- Graphical Structure of WordPress Database
- Common WordPress Database Problems and the Tables Behind Them
- Related Articles
WordPress Database Tables at a Glance
A standard single-site WordPress installation currently uses 12 default database tables. The table below summarizes what each table stores, where WordPress uses it, and what can break if the table is missing or corrupted.
| Table | Stores | Used for | What breaks if missing or corrupted |
|---|---|---|---|
wp_options | Site URL, active plugins, theme settings, transients, rewrite rules, cron data | WordPress bootstrap, plugin settings, site configuration | Wrong URL redirects, missing settings, plugin failures, broken cron, slow autoloaded options |
wp_posts | Posts, pages, attachments, revisions, menus, custom post types | Content, media library, navigation menus, many plugin data types | Missing pages/posts/media, broken menus, missing custom post type entries |
wp_postmeta | Metadata for posts, pages, attachments, products, page builders, SEO plugins | Featured images, product data, SEO fields, builder layouts | Missing images, broken layouts, missing product data, incomplete SEO metadata |
wp_users | User accounts, logins, password hashes, emails, display names | Authentication and authorship | Users cannot log in, authors disappear |
wp_usermeta | User roles, capabilities, profile fields, plugin user settings | Permissions and user-specific settings | Admin loses permissions, roles disappear, user settings break |
wp_comments | Comments, pingbacks, trackbacks, reviews | Comments and review systems | Comments or reviews disappear |
wp_commentmeta | Metadata for comments and reviews | Spam status, ratings, plugin comment data | Review metadata, spam data, or plugin comment data is lost |
wp_terms | Term names and slugs | Categories, tags, link categories, custom taxonomy terms | Category and tag names disappear |
wp_termmeta | Metadata for taxonomy terms | Term images, SEO metadata, custom term fields | Category/tag metadata disappears |
wp_term_taxonomy | Taxonomy type, parent relationship, term counts | Distinguishes category vs tag vs custom taxonomy | Categories/tags become incorrectly mapped or lose hierarchy |
wp_term_relationships | Relationships between content and taxonomy terms | Assigns posts/products/pages to categories and tags | Posts lose categories/tags, menus and taxonomy relationships break |
wp_links | Legacy blogroll/link manager data | Deprecated Links Manager feature and old plugins | Usually nothing on modern sites, unless an old plugin still uses it |
How do Database Tables Look Like?
Imagine an Excel sheet with one header row and values in the row below.
For instance, you can see a small section of the table here. wp_options:
Let’s talk about those tables more deepluy to understand why it is essential to know which table is responsible for the content of a WordPress site.
Understanding the table structure will help you to understand which table you need to include or exclude if you are planning to sync or move data from a staging site to the live site or vice versa with WP STAGING. It’s also helpful if you plan to update the staging site.
This becomes even more important with WordPress 7.0 and newer. The planned wp_collaboration table stores real-time editor collaboration data, which is usually temporary and environment-specific. When pushing a staging site to a live site, avoid overwriting the live site’s active collaboration state unless you intentionally want to replace the entire database.
List of WordPress Core Tables
The table above gives a quick overview. The following section explains the core WordPress tables in more detail for developers, site owners, and anyone debugging migrations, backups, or database issues.
- wp_options
- wp_users,
- wp_usermeta
- wp_posts
- wp_postmeta
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_termmeta
- wp_comments
- wp_commentmeta
- wp_links
WordPress may add new core tables in major releases. For example, WordPress 7.0 is planned to introduce `wp_collaboration` for real-time editor collaboration data.
Other tables in your database are created by plugins or themes and are not always required to run the website successfully.
wp_options
The table wp_options is one of the most essential WordPress database tables and stores all the settings of a WordPress site, like the URL, the title, installed plugins, etc! Most of the plugins store settings in this table as well.
All the settings in the WordPress dashboard are stored in this table.
wp_users,
wp_usermeta
wp_users Stores all the registered users on a WordPress site. It contains basic information about a user, like a username and encrypted password, email, time of registration, display name, status, and a few more fields.
wp_usermeta Stores the metadata (‘additional data‘) of the users. It extends the table wp_users with more data. For example, a user’s first name is stored in the table wp_usermeta instead of the table wp_users.
There are two necessary fields in this table. Plugins can store custom data in wp_usermeta by just adding a new value in the field meta_key.
wp_posts,
wp_postmeta
wp_posts Table stores all content-related data of a WordPress website. All posts, pages, and their revisions are available in the wp_posts table. It might be unclear, but WordPress stores much more into that table.
This table also contains navigation menu items, media files, and attachments like images and content data used by plugins.
In wp_posts is a table column post_type which segments that kind of different data so that a database query can request specific types of data. post_type is the most critical column in this table.
In the images below, you can see two different post_types,revision and attachment which are stored in the same wp_posts table:
The table wp_postmeta, just like the table wp_usermeta, extends the table wp_posts with more data, which can be used by other plugins as well.
For instance, the popular Yoast SEO plugin stores custom open graph tags, posts, and URL data in this table.
wp_terms,
wp_term_relationships,
wp_term_taxonomy,
wp_termmeta
The table wp_terms stores Categories and tags for posts, pages, and links.
One of the columns in this table is ‘slug. ‘ A slug is a term that reflects a tag of a particular post. In WordPress, you can use tags to connect posts, pages, and links.
wp_term_relationships is the conjunction and connects these tags to posts, pages, and links. It’s like a map between the terms objects and the terms.
wp_term_taxonomy Extends the table wp_terms with more data. It’s like metadata for the table wp_terms , with the difference that plugins cannot add custom data here. This table also contains a relationship between menus and menu items.
The wp_termmeta table stores metadata for taxonomy terms. It works similarly to wp_postmeta, wp_usermeta, and wp_commentmeta, but for categories, tags, and custom taxonomy terms.
Plugins and themes can use this table to store additional data for terms, such as category images, SEO metadata, custom colors, display settings, or other taxonomy-specific fields.
If this table is missing or incomplete after a migration, categories and tags may still exist, but their additional metadata can be lost.
wp_comments,
wp_commentmeta
wp_comments stores comments on posts and pages. This table also contains unapproved comments and author information, together with the hierarchy of comments. The table wp_commentmeta contains further metadata about the comments.
wp_links
This table contains information about custom links added to your site. It has been deprecated and is not used any longer. There are a few older plugins that still make use of it, but usually, it is an empty table.
Upcoming WordPress 7.0 Table: wp_collaboration
`wp_collaboration` is a new WordPress core database table planned for WordPress 7.0. It is part of the real-time collaboration feature in the block editor, which allows multiple users to edit the same post or page at the same time.
Earlier WordPress 7.0 beta versions stored collaboration-related sync data in post and post meta storage. This created performance problems because real-time editor activity can write data very frequently. Each post meta update may invalidate post-related object caches, which can reduce the effectiveness of persistent object caching while an editor session is open.
The new `wp_collaboration` table separates high-frequency collaboration data from the regular content tables like `wp_posts` and `wp_postmeta`. Its purpose is to store temporary synchronization data used by the editor, such as collaborative editing updates, client/session identifiers, room information, and timestamps used for cleanup.
This table does **not** replace `wp_posts`, `wp_postmeta`, or the WordPress revisions system. Posts, pages, attachments, custom post types, and revisions are still stored in `wp_posts`; post-specific metadata remains in `wp_postmeta`.
For backups and migrations, treat `wp_collaboration` differently from permanent content tables. A full database backup should include it, but when pushing a staging site to production, this table usually does not need to overwrite the live site because it stores short-lived collaboration/session data rather than canonical website content. WordPress can recreate collaboration state as users edit content.
Important: although the data is temporary, it may still contain editor synchronization payloads related to in-progress content. Do not treat it as public or disposable from a privacy and security perspective.
Note: The final schema may still change before the WordPress 7.0 release. During development, public proposals for `wp_collaboration` have included fields such as an auto-incrementing ID, room identifier, client/user identifiers, a data payload, and a GMT timestamp. Recent testing also explores storing presence/awareness data in a separate `wp_presence` table. Check the final WordPress 7.0 database schema before publishing the exact column list.
Graphical Structure of WordPress Database
This diagram shows how the WordPress tables are connected:
Open image in full resolution: Right click -> Open image in new tab
Common WordPress Database Problems and the Tables Behind Them
| Problem | Most relevant table(s) | What to check |
|---|---|---|
| Site redirects to the wrong domain after migration | wp_options | Check siteurl, home, and serialized plugin options |
| Admin user exists but has no admin permissions | wp_usermeta | Check the capabilities key, especially after changing the table prefix |
| Posts exist but categories or tags are missing | wp_terms, wp_term_taxonomy, wp_term_relationships | Check whether all taxonomy tables were migrated together |
| Media library entries exist but images are broken | wp_posts, wp_postmeta, uploads folder | Attachments are stored in wp_posts; file paths are often stored in _wp_attached_file in wp_postmeta |
| Menus disappear after migration | wp_posts, wp_terms, wp_term_relationships, wp_postmeta | Navigation menus are stored across several tables |
| Plugin settings disappear | wp_options, sometimes plugin-specific tables | Check whether the plugin stores settings in wp_options or custom tables |
| Site becomes slow after migration | wp_options, wp_postmeta | Check autoloaded options and large metadata tables |
| Comments or reviews disappear | wp_comments, wp_commentmeta | Migrate both tables together |
| WordPress says a table does not exist | wp-config.php, all prefixed tables | Check $table_prefix and whether all tables use the same prefix |
