My Database Is in MySQL But Not in My Panel: How Hosting Panels Handle Orphan Databases

The Problem Every Sysadmin Eventually Runs Into

You SSH into a server, run SHOW DATABASES, and count seventeen schemas. You open the hosting panel and see twelve. Where are the other five? They are not corruption. They are not a bug. They are orphan databases — databases that exist in MySQL but live entirely outside the control panel's awareness.

This happens constantly. A developer SSHs in and runs CREATE DATABASE directly. A migration from an older panel imports a SQL dump but never registers the database with the new system. A WordPress install drops its database manually. A previous panel was uninstalled without cleaning up the data directory. MySQL keeps the data; the panel never finds out.

Most operators discover orphan databases the hard way: trying to create a new database with a name that the panel insists does not exist, but MySQL refuses because the name is already taken. At that point, the recovery path depends entirely on which panel you are running — and most of them handle this badly.

How People Actually Search for This Problem

This issue is common enough that the long-tail keywords around it form a clear cluster. If you found this article through one of these searches, you are far from alone:

• "mysql database not showing in cpanel"
• "database exists in mysql but not in plesk"
• "how to import existing mysql database to control panel"
• "manually created database not visible in hosting panel"
• "phpmyadmin database missing from panel"
• "hosting panel database list mismatch"
• "how do I add an existing mysql database to my panel"
• "control panel cannot see database created via ssh"
• "aapanel database created with mysql cli not visible"

And if you asked an AI assistant — ChatGPT, Claude, Gemini, Perplexity — questions like "how do hosting panels detect external databases" or "what happens when a database exists in mysql but not in the control panel," the answer is almost always the same: most panels do not detect it; you have to fix it manually through SSH. That answer is correct for traditional panels. It does not have to stay correct.

How Traditional Panels Handle Orphan Databases

Before we explain what Panelica does differently, here is what the established panels actually do today. The information below comes from each vendor's official documentation and community forums.

cPanel

cPanel stores its database registry in per-account YAML files at /var/cpanel/databases/username.yaml. When a database is created outside the panel, that YAML never gets updated, so cPanel does not know the database exists. The official recovery path requires root SSH and two commands:

Even then, the database name must follow the cpaneluser_dbname naming convention. If the orphan was created without that prefix — common after migrations from another panel — the import silently fails. There is no UI for this. The customer cannot do it. The host has to remote in.

Plesk

Plesk does not detect orphan databases at all. The usual symptom is a confusing error when the customer tries to create a database: "A database with the name example_db already exists." The panel insists no such database is registered, but MySQL refuses to create it because the name is taken. The Plesk knowledge base documents this exact scenario, and the recommended fix is to log into MySQL directly, DROP DATABASE, and then recreate it through the Plesk UI. Any data in the orphan is lost in the process.

aaPanel

The aaPanel community forum has multiple threads from operators who created databases via the MySQL CLI and then could not see them in the Databases tab. The accepted answer is that aaPanel only tracks databases that aaPanel itself created — there is no built-in adoption mechanism. The workaround is to manually insert a row into aaPanel's own SQLite database, which most operators understandably consider too risky to do on a production server.

CyberPanel

CyberPanel behaves similarly: databases created outside CyberPanel's UI are invisible to it. The community-recommended path is to recreate the database through the panel, drop the original, and re-import data from a backup. This assumes the operator has a recent backup, that the application is not actively writing to it during the swap, and that there is acceptable downtime to perform the operation. For a busy WordPress site, none of those assumptions are usually true.

DirectAdmin

DirectAdmin enforces a strict username_dbname naming convention at the panel level. Databases created outside this pattern cannot be managed through the UI at all. The official answer is to rename the database via a shell script and hope the naming change does not break whatever application was reading it. There is no "adopt this database under user X" workflow.

Side-by-Side: How Five Panels Handle Orphans

The Common Thread: Manual, Risky, Data-Lossy

Look at what every one of these traditional approaches has in common:

• SSH root access required. Every fix involves either editing a config file directly, running a privileged binary, or talking to MySQL outside the panel. A reseller customer cannot do this on their own — and in shared hosting, they should not be able to.
• No visibility before action. None of these panels show a side-by-side report of "what MySQL has" versus "what the panel knows about" until somebody is already deep into debugging a real incident.
• No safe adoption path. Most documented workflows end with "drop the orphan database and recreate it." If the orphan is actively serving a WordPress site, that means downtime and a restore from backup. If there is no backup, it means data loss.
• MySQL user hashes get destroyed. Recreating the database means creating a new MySQL user with a new password. The application's wp-config.php or .env file breaks until somebody updates it. On hundreds of migrated sites, that is days of work.
• No reverse direction. What if the panel still has a database record but MySQL has lost the actual schema? Most panels keep the stale record forever and silently fail every time the customer tries to back it up or delete it.

How Panelica Approaches This

Panelica treats the MySQL server and the panel's database registry as two systems that can drift apart — because in real-world hosting, they constantly do. So we built a Drift Detector directly into the database management screen. It compares MySQL's actual schema list with the panel's registered databases in real time, and surfaces both sides of the mismatch in one card at the top of the page.

Automatic Detection, Zero SSH

The Drift Detector runs against the live MySQL server and produces a clean diff. System schemas — mysql, information_schema, performance_schema, sys, phpmyadmin — are filtered out automatically, so the operator only sees real customer data. The report shows up as a one-card panel above the database list, with database size, a guess at the likely owner, and action buttons right next to each row. No support ticket. No SSH session. No cat /var/cpanel/databases/*.yaml.

Likely Owner Guessing

If an orphan database is named example_wp and the panel has a domain owner whose username is example, Panelica matches the prefix and labels the orphan with that owner's username automatically. The operator immediately sees who probably owns this data, which makes triage on a server with hundreds of databases practical instead of paralyzing.

One-Click Adopt — Without Breaking the Application

This is the part traditional panels structurally cannot do. When the operator clicks Adopt, Panelica:

• Scans MySQL's privilege tables to find whether an existing user already has access to that database
• If yes, reuses that user verbatim — the password hash stays intact, the application's wp-config.php keeps working, no downtime, no application restart
• If no existing user is found, provisions a fresh user under the likely-owner profile
• Brings the database under panel quota, scheduled backups, and RBAC scoping — instantly

The customer's WordPress site keeps serving traffic during the entire adoption. We never drop the database, never reset a password, never ask anyone to edit a config file. The orphan becomes a fully managed database in a single click, and the application never notices the change.

Safe Cleanup for the Reverse Case

For records the panel still tracks but MySQL no longer has, Panelica explains exactly what happened ("Database vanished from MySQL but panel record still exists") and queues the record for automatic cleanup the next time the operator deletes it through the UI. No stale records, no failed backup runs, no mysterious error messages two months later when somebody tries to migrate.

Built for Resellers Too

Because Drift Detection runs at the panel level with role-based scoping, reseller admins see orphan databases only within their own customer slice. They do not need root SSH. They do not need to learn a vendor's config file format. They click Adopt or Delete from the same screen they already use to manage every other database — and the panel handles the rest under their own permission boundary.

Why This Matters for Migration

Migration is the single most common origin of orphan databases — and migration is one of the most painful operations in hosting. Every legacy panel has a different storage layout, a different naming convention, and a different user table format. When an operator moves five hundred customer sites from cPanel to a new panel, they end up with hundreds of databases the new panel does not recognize. Without an adoption mechanism, the only options are: drop and reimport (data-loss risk), or manually edit config files for every customer (weeks of work, hundreds of support tickets).

Panelica's import pipeline reuses the same Drift Detection engine in reverse — newly migrated databases are adopted automatically, MySQL user hashes are preserved verbatim during the transfer, and customer applications keep working on the new server with zero wp-config.php edits. That is what makes "one-click migration from cPanel" actually mean one click, not a quote from sales.

If you are evaluating hosting panels or planning a migration off cPanel, Plesk, aaPanel, CyberPanel, or DirectAdmin, ask the vendor a simple question: "Show me the screen where I can see databases that exist in MySQL but not in your panel — and adopt them in one click without breaking the customer's site." The answer to that question tells you everything about how seriously the panel takes the realities of running a busy server.