In earlier articles in this series, I introduced each table in a standard single-site WordPress database, how those tables interact, and how data is stored across them. In this article, we will look at the WordPress database in a Multisite network. A Multisite installation adds several extra tables, and each site in the network also has its own dedicated set of content tables. To really understand what the WordPress database looks like in Multisite, you need to understand three groups of tables:
- The main site tables
- The network-wide tables
- The per-site tables for each site in the network
Main Site Tables in Multisite
The main site in a Multisite network still uses the same 11 core tables as a normal single-site WordPress installation. These tables store the main site’s own content and settings:
- wp_posts
- wp_postmeta
- wp_comments
- wp_commentmeta
- wp_users
- wp_usermeta
- wp_links
- wp_term_relationships
- wp_term_taxonomy
- wp_terms
- wp_options
Two of these tables are also shared across the wider network:
- wp_users
- wp_usermeta
The other tables work the same way they do in single-site mode and store the main site’s own content. The users and usermeta tables, however, also store data that matters to the entire network rather than only the main site.
Network-Wide Tables in Multisite
In addition to the shared user tables, WordPress creates several extra tables specifically for Multisite network management:
- wp_blogs
- wp_blog_versions
- wp_registration_log
- wp_signups
- wp_site
- wp_sitemeta
- wp_sitecategories (optional)
Together with the shared user tables, these tables store the data required to run the network. Here is a quick summary of what each one does:
| Table | Data | Description |
|---|---|---|
| wp_blogs | One record for each site in the network | Fields include blog_id, the domain, path, and registration time. |
| wp_blog_versions | Database version information for each site | Updated when the network is upgraded. Key fields are blog_id, db_version, and last_updated. |
| wp_registration_log | The administrator user created when a site is registered | For each site, identified by blog_id, it records the admin user ID, email address, and registration date. |
| wp_signups | Sites that have been registered but not yet activated | Each record has a unique signup_id and includes the registered domain, title, username, and email address. The record is removed after activation. |
| wp_site | The main network site URL | This table usually contains a single record with the main site ID, domain, and path, which is normally /. |
| wp_sitemeta | Extra network metadata | This works like a network-level wp_options table and stores settings for the entire network, using fields such as meta_id, site_id, meta_key, and meta_value. |
| wp_sitecategories | Optional table used when global categories are enabled | It allows all sites in the network to share the same categories. Besides default categories, it may also include custom taxonomy terms. |
| wp_users | All users for the network | Users are stored here rather than duplicated for each site, which allows them to access multiple sites in the network. In Multisite, WordPress adds the spam and deleted fields to this table. |
| wp_usermeta | Extra user information | This table works much the same way as it does in a single-site installation. |
How These Tables Relate to Each Other
Because each site’s data needs to connect back to the network’s core tables, most Multisite tables relate back to wp_blogs through blog_id. There are three notable exceptions:
wp_sitecategories, which stores shared category and taxonomy term informationwp_signups, which stores registered but not yet activated siteswp_usermeta, which links throughwp_usersrather than directly throughwp_blogs
The Database Tables for Each Individual Site
The way WordPress stores data for each site in Multisite is very direct: it creates a separate set of content tables for each subsite. Since user data stays in the shared main tables, WordPress does not duplicate wp_users and wp_usermeta for every site. To distinguish each subsite, WordPress adds the site ID to the table name. For example, on site ID 2, the posts table becomes wp_2_posts.
Each subsite gets the following tables:
- wp_xx_posts
- wp_xx_postmeta
- wp_xx_comments
- wp_xx_commentmeta
- wp_xx_links
- wp_xx_term_relationships
- wp_xx_term_taxonomy
- wp_xx_terms
- wp_xx_options
Here, xx represents the site ID. Aside from the table name prefix, data is stored in these per-site tables in the same way it is stored for a normal single-site WordPress installation.
Summary
If you plan to use WordPress Multisite, it is worth taking the time to understand its database structure in detail. That knowledge makes it much easier to manage and maintain a network, troubleshoot problems quickly, and identify which site is causing an issue. If the default Multisite database structure does not fully meet your needs, you can also use the WordPress Database API to add custom tables of your own.
