Can multiple WordPress sites use the same database?
Yes. Two mechanisms do it: a WordPress Multisite network, or separate installations distinguished by table prefixes. Beyond the fact that the data sits in one place, they have almost nothing in common. They differ in the management model, in how much isolation you actually get, and in what happens when one site has to be restored from a backup.
What follows is the difference between the two approaches, the technical consequences of each, and the conditions under which either one makes sense.
Multisite versus separate installations
| Feature | WordPress Multisite | Separate installations |
|---|---|---|
| Users | Shared across the network | Independent per site |
| Plugins and themes | Shared files, managed network-wide | Separate per site |
| Administration | One network dashboard | Separate dashboards |
| Configuration freedom | Constrained by network settings | Full |
| Core updates | One update for every site | Separate for each |
Multisite turns a single installation into a network of sites. Some tables are shared across the whole network: user accounts in wp_users and wp_usermeta, plus the tables that manage the network itself, wp_blogs, wp_site and wp_sitemeta. Every site added after the first gets its own set of content tables, numbered in the name: wp_2_posts, wp_2_options, wp_2_comments and so on.
Separate installations keep their own dashboards, users, plugins and themes. The only thing joining them is that they write to the same database using different prefixes. Whether that makes them independent is the question this article is really about, and the answer is not the one most guides give.
The distinction comes down to management philosophy. Multisite fits a portfolio of related sites under common oversight: branch networks, regional variants, brands belonging to one owner. Separate installations fit cases where the sites are meant to stay apart.
How WordPress stores data
WordPress keeps content, settings and user data in a MySQL or MariaDB database, in tables with a fixed structure. Every table name starts with a prefix, wp_ by default. Hence wp_posts, wp_users, wp_options. WooCommerce adds its own tables on top of this same structure — see where WooCommerce actually stores its data.
That prefix is the only mechanism allowing several independent installations to coexist in one database. It is not an isolation mechanism. It is a name-collision mechanism. The difference matters, and we return to it under security.
How table prefixes work
The prefix is configured in wp-config.php:
php
$table_prefix = 'shop1_';The installer then creates shop1_posts, shop1_users and the rest. A second installation with the prefix blog2_ builds its own disjoint set in the same database.
The trailing underscore is required. WordPress appends the table name with no separator, so shop1 produces shop1posts.
One practical note. Changing the prefix on a live site is not a one-line edit. Besides renaming the tables, you have to update the entries that carry the prefix inside the data itself: the user roles key in the options table, and the capabilities entries in user metadata. Skip that step and you lock yourself out of the admin.
Security: what a shared database actually gives you
This needs stating plainly, because most guides soften it.
If every installation connects to the database as the same MySQL user, and that is the default and by far the most common setup, then there is no isolation between the sites. Compromising one installation gives an attacker full read and write access to the tables of all the others, including their user tables. The prefix is no barrier at all, because its only job is to keep names apart.
Reducing that risk requires a separate MySQL user per installation, with privileges scoped to its own tables. A wildcard grant on the prefix pattern covers most of it, since the underscore has to be escaped in the pattern. It works, but it is awkward to maintain: any plugin that creates a table outside the prefix convention needs its privileges granted by hand, and the omission only surfaces as an error at the moment the plugin first tries to write.
Everything else is standard and still applies: separate strong passwords, current core and plugin versions, monitoring of database access, and file permission control. None of those address the shared-credential problem, so treat them as necessary rather than sufficient.
Backups: the consequence people miss
A shared database simplifies making backups. One dump covers every site. The problem appears on the way back.
Restoring that dump rolls back the state of every installation in the database, not only the one that needed fixing. If one site was breached on Wednesday while the others carried on taking orders, restoring Tuesday’s copy costs the other sites two days of work.
The workaround is selective restore: extracting only the tables with the right prefix from the dump. It can be done, but it needs a written procedure prepared in advance, not improvisation under the pressure of an incident. The same problem exists in Multisite, where part of the data is shared across the network as well.
Trade-offs at a glance
In favour of a shared database:
simpler hosting configuration where the number of available databases is limited
one backup procedure
fewer places to monitor
Against:
no real isolation when the sites share a database user
restoring a backup affects every site at once
load generated by one site affects the others
harder diagnostics, because queries from different sites mix in the logs
separating a site onto its own infrastructure later requires a migration
When each option makes sense
Choose Multisite when the sites belong to one owner, share editorial staff, and have similar functionality. The typical case is a network of regional variants, or a brand portfolio managed by one team. Note that plugins and themes are shared across the network, so a failed update affects every site at once.
Separate installations in a shared database are a situational solution. They make sense where hosting limits the number of databases and the sites are non-critical: internal tools, test environments, low-traffic projects. This is not an architecture to choose for sites taking payments or processing personal data.
Separate databases remain the default wherever isolation, predictable recovery, and independent scaling matter. The cost of an additional database today is marginal against the cost of a single incident spanning several sites.
What to settle before you commit
The decision to share a database is easy to make and hard to reverse. Separating installations years later means migrating data, repointing configuration, and a maintenance window for every site in the set. That migration itself is covered in can I copy a WordPress site to another domain?
If you are planning the architecture for a portfolio of sites, settle three things at the start. Will any of these sites ever be sold or spun out separately? What is an acceptable recovery time after a failure? Who owns updates? The answers usually decide the choice faster than any comparison of technical capabilities.
At WLC we design and rebuild architectures of this kind, including separating networks that have outgrown the scale they were built for.
