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.
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
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 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
- wp_options
- wp_users,
- wp_usermeta
- wp_posts
- wp_postmeta
- wp_terms
- wp_term_relationships
- wp_term_taxonomy
- wp_comments
- wp_commentmeta
- wp_collaboration — planned for WordPress 7.0+
- wp_links
WordPress may add new core tables in major releases. Other tables in your database are often 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
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_relationship 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.
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_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.
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.
Graphical Structure of WordPress Database
This diagram shows how the WordPress tables are connected:
Source: WordPress.org