Which database belongs to which site, and why it matters

On an account holding several sites, the database list is where the network gets confusing. Names are prefixed with the account, not the site, so twenty databases can look interchangeable and nobody remembers which one belongs to which domain until the wrong one gets deleted.

Why the names stop helping

Databases are created with the account prefix attached automatically. Whatever you type is appended to it, so an account called netops ends up with netops_wp1, netops_wp2, netops_test. After a year, wp2 means nothing to anyone, including you.

The prefix cannot be changed, so the only lever is the part you choose. Use it.

Name them after the domain

netops_examplecom
netops_examplenet
netops_clientshop

Not perfect, because the prefix eats characters and long domains get truncated, but a truncated domain is still a hundred times more useful than a number. Apply the same rule to database users, so a leaked or rotated credential is traceable to one site.

Finding out which database a site actually uses

When the names are already unhelpful, read it from the site's configuration rather than guessing:

grep -i "DB_NAME\|DB_USER" ~/public_html/wp-config.php
grep -rn "DB_NAME" ~/*/wp-config.php

The second form walks every site directory in the account and prints the mapping for all of them at once. That output, saved somewhere, is the inventory you should have had from the beginning.

Orphans

Every network accumulates databases belonging to sites that no longer exist: a test install, a migration that was redone, a client that left. They cost inodes and disk, and they are indistinguishable from live databases by name alone.

Before deleting any of them:

1. Confirm no configuration file on the account references it.
2. Check its last modification time. A database untouched for a year is a strong candidate, but not proof.
3. Export it, download the export, then delete.
4. Wait a week before discarding the export.

This is the same suspend-before-terminate discipline that applies to accounts, and it exists for the same reason: deletion has no undo.

One user per site, not one user for everything

A single database user with access to every database on the account is convenient and it removes a boundary you paid for. If one site is compromised, its configuration file hands the attacker credentials for all the others.

Give each site its own user with rights to its own database only. This is the database-level equivalent of the filesystem isolation described in Platform and Limits, and it matters most on exactly the accounts where several sites live together.

Why this belongs in a network discussion at all

You separated your sites at the address level so they would not resolve back to one another. Sharing one database user across them reconnects them at a layer that is invisible from outside but very real during an incident. Separation is only as complete as its weakest layer, and this is a common weak one.

If two sites genuinely must not share anything, they belong in separate accounts rather than separate databases within one. That decision is covered in Network Planning. What the addresses themselves buy you is set out on the Class C hosting page.

The database interface is documented at docs.cpanel.net.