Earlier in this series, I introduced each table in the WordPress single-site database, how those tables relate to one another, and how they store data. This article extends that discussion into WordPress Multisite.
A WordPress Multisite network includes some additional network-level tables, while each site in the network also has its own site-specific tables. To understand what the WordPress database looks like in Multisite mode, it helps to think about three kinds of tables:
- Tables for the main site
- Tables for the whole network
- Tables for each individual site in the network
Tables used by the main site in Multisite mode
The main site in a Multisite network still has the same 11 core tables that a normal single-site WordPress install uses. Those tables store the main site’s content and settings:
wp_postswp_postmetawp_commentswp_commentmetawp_userswp_usermetawp_linkswp_term_relationshipswp_term_taxonomywp_termswp_options
Two of those tables are also special because they are used beyond the main site:
wp_userswp_usermeta
The other tables behave just as they do in a normal single-site installation and mainly store the main site’s own content. The user-related tables, however, are shared with the network more broadly.
Network-level tables in Multisite mode
In addition to the core tables, WordPress creates a set of extra tables for network-level Multisite data. These include:
wp_blogswp_blog_versionswp_registration_logwp_signupswp_sitewp_sitemetawp_sitecategories(optional)
These network tables, together with the shared user tables, hold the data that describes the overall Multisite network.
How the tables relate to one another
Because each site’s data needs to connect back to the network, many tables link to the wp_blogs table through blog_id. The original article points out three exceptions:
wp_sitecategories, which links documents to category itemswp_signups, which stores registered but not yet activated siteswp_usermeta, which links back indirectly throughwp_usersrather than directly throughwp_blogs
How WordPress stores each site’s tables in Multisite
The actual storage strategy in Multisite is simple and a little blunt: WordPress effectively creates a copy of the content tables for each site. Since user data is already stored in the shared main-site user tables, the site-specific copies do not include extra wp_users or wp_usermeta tables.
To distinguish one child site from another, WordPress prefixes each site’s tables with the site ID. For example, for site 2 the posts table becomes wp_2_posts. Each child site has the following kinds of tables:
wp_xx_postswp_xx_postmetawp_xx_commentswp_xx_commentmetawp_xx_linkswp_xx_term_relationshipswp_xx_term_taxonomywp_xx_termswp_xx_options
In the list above, xx represents the site ID. The data storage pattern inside those child-site tables works the same way it does in a single-site installation.
Summary
If you plan to use WordPress Multisite, taking time to understand the underlying database structure is extremely helpful. It makes the network easier to manage and maintain, and it also helps you locate problems quickly when a specific child site has an issue.
And if the default Multisite structure does not fully fit a project’s needs, WordPress still gives developers room to create additional custom tables through the database APIs.
