Dropping a WordPress Database Safely

Before anything else: confirm which database belongs to the site you mean. Shared hosting accounts routinely hold four or five databases with names like usr1234_wp5, and nothing in the list tells you which site each one runs. Dropping a database is instantaneous, unconfirmed beyond a single dialogue, and permanent.

Everything worth saying about this task is about identification. The deletion is trivial; deleting the wrong one takes down a site you were not thinking about, often one that belongs to somebody else.

What a database drop destroys

The database holds all of your content and none of your files:

• Gone: posts, pages, comments, categories and tags, user accounts and password hashes, every plugin and theme setting, WooCommerce orders and customers, form submissions, menus, widgets.
• Untouched: the WordPress files themselves, the uploads folder, your themes and plugins, the domain, the hosting account, and email.

That asymmetry produces the classic aftermath: a site that still loads its code, fails to connect, and shows an error establishing a database connection to every visitor. If you dropped the database on purpose, remove the files too, and if you did not, that error is your first symptom.

Confirm ownership before you touch anything

Two checks, in order, and the second one is conclusive.

Read wp-config.php for the site in question. It names the database, the database user and the table prefix:

define( 'DB_NAME', 'usr1234_wp5' );
define( 'DB_USER', 'usr1234_wp5user' );
$table_prefix = 'wp_';

What each wp-config.php setting does covers the rest of the file. If you have already deleted the site's files, you no longer have this — which is why the order in uninstalling WordPress from a domain puts reading the config first.

Then verify from inside the database. Open it in the hosting panel's database tool and read the siteurl row of the options table:

SELECT option_value FROM wp_options WHERE option_name = 'siteurl';

Adjust wp_ to the prefix you noted. The value returned is the site that database runs. If it is not the site you meant to delete, stop — you were about to destroy something else. Working in phpMyAdmin covers navigating that interface if it is unfamiliar.

Also count the prefixes. If the table list contains wp_posts and wpb2_posts, two sites share this database and dropping it takes both.

Export it, download it, open it

Do this even when you are certain. A database dump of a modest site is a few megabytes and takes a minute.

1. Export the whole database as SQL from the panel's database tool, or with WP-CLI:

wp db export backup.sql

2. Download the file off the server. A dump sitting in the account you are cleaning out is not a backup.
3. Open it in a text editor. It should contain CREATE TABLE and INSERT INTO statements and recognisable content. A file of a few kilobytes is an error message, not an export.
4. Export anything you will need to read — orders, subscribers, entries — as CSV as well. SQL is for restoring, not for looking things up.

How to back up a WordPress site covers taking files and database together, which is what you want if the site might ever come back.

Drop the database and its user

Panels are reorganised constantly, so look for the concept rather than a path: a databases section listing each database with its size and assigned users, and a delete or drop action per row. The same section lists database users separately.

Delete both. A database user left behind is a working set of credentials for a database that no longer exists, and if the same user was granted access to your other databases, it is a live credential for those. Check its privileges before removing it, in case another site depends on that account.

With WP-CLI, from the site directory:

wp db drop --yes

To remove one site from a shared database instead, drop only its prefixed tables — never the database.

Make sure this is the tool you want

Dropping is right when the site is being retired, when you are clearing debris left by an install you already removed, or when you are deliberately starting from empty.

It is the wrong tool for a site that is merely broken. Corrupted tables can usually be repaired, bloat can be cleared, and a stuck site can be reset without losing everything — repairing a WordPress database covers those routes. Once you have confirmed the drop, none of them are available to you any more.