How to Manage the WordPress Database without phpMyAdmin

You do not need phpMyAdmin to manage a WordPress database.

phpMyAdmin is a convenient web interface for MySQL and MariaDB, but it is only one possible way to inspect, export, import, query and maintain the database behind WordPress.

Depending on the task, you can manage a WordPress database through:

• WordPress itself;
• the wpdb database abstraction;
• WP-CLI;
• hosting database tools;
• MySQL or MariaDB command-line clients;
• desktop database clients;
• specialized WordPress database-management tools.

In many cases, using WordPress-aware tools is actually preferable because they understand concepts such as:

• the active table prefix;
• WordPress APIs;
• serialized data;
• Multisite table scopes;
• object relationships;
• plugin-specific behavior.

The important question is therefore not:

How can I replace phpMyAdmin?

It is:

Which database-management method is safest
for the operation I need to perform?

This guide explains how to manage a WordPress database without phpMyAdmin, including inspection, backups, exports, imports, queries, search and replace, optimization, repair, cleanup and safer alternatives for everyday administration.

What does “managing the WordPress database” actually mean?

Database management can refer to very different operations.

You may need to:

• list database tables;
• inspect columns;
• check database size;
• browse stored records;
• export a backup;
• restore an SQL dump;
• search for stored values;
• change URLs after a migration;
• run a custom SQL query;
• clean revisions or transients;
• optimize tables;
• check tables for errors;
• repair damaged tables;
• inspect plugin-created tables.

Those tasks do not all require the same tool.

Understand the database before modifying it

A standard WordPress database contains Core tables such as:

wp_posts
wp_postmeta
wp_options
wp_users
wp_usermeta
wp_comments
wp_commentmeta
wp_terms
wp_term_taxonomy
wp_term_relationships
wp_termmeta

Plugins may also create their own tables.

Before deeper maintenance, read The WordPress Database Structure, Explained.

Knowing which table contains which type of data makes every database operation safer.

You may not even need direct database access

Many tasks that look like database operations already have WordPress APIs.

For example:

get_option()
update_option()

get_post_meta()
update_post_meta()

wp_insert_post()
wp_update_post()
wp_delete_post()

get_user_meta()
update_user_meta()

The official WordPress Options API documentation explains how site configuration can be stored and retrieved without manually editing the wp_options table.

Why WordPress APIs are often safer

A database record may participate in more application logic than is visible from the table itself.

A WordPress API may also:

• validate input;
• sanitize data;
• trigger hooks;
• clear caches;
• update related records;
• preserve WordPress semantics.

So the first rule is:

Use WordPress APIs
when they already solve the task.

WP-CLI is one of the best phpMyAdmin alternatives

WP-CLI provides an extensive set of database commands directly from the terminal.

The official wp db command documentation currently includes commands for:

• listing tables;
• showing columns;
• checking the database;
• exporting;
• importing;
• running SQL;
• optimizing;
• repairing;
• searching;
• checking database size;
• opening a database console.

Check your database connection first

If WP-CLI can bootstrap WordPress correctly, it can usually use the database credentials already defined in:

wp-config.php

That means you generally do not need to copy database credentials into every command.

Find the WordPress database prefix

Run:

wp db prefix

The official wp db prefix documentation describes this command as displaying the active table prefix interpreted by WordPress.

A result may be:

wp_

but it could instead be:

client_
prod_
abc123_

This matters because you should never assume every WordPress installation uses wp_.

List WordPress database tables

Use:

wp db tables

The official wp db tables documentation explains that the command lists tables registered with the WordPress database handler by default.

Typical output may include:

wp_posts
wp_postmeta
wp_options
wp_users
wp_usermeta
wp_comments
wp_commentmeta
wp_terms
wp_term_taxonomy
wp_term_relationships
wp_termmeta

Include plugin-created tables

Some plugin tables may not be registered as standard $wpdb tables.

WP-CLI supports:

wp db tables --all-tables-with-prefix

This can help identify custom tables sharing the WordPress prefix.

For a complete database:

wp db tables --all-tables

can list tables beyond the WordPress prefix as well.

Use that option carefully when a database is shared with other applications.

Multisite table listing needs context

On WordPress Multisite, table scope matters.

For example:

wp db tables --scope=blog

can show blog-level tables.

The official WP-CLI documentation also supports:

--network
--scope=global
--scope=ms_global

depending on the operation.

Inspect table columns without phpMyAdmin

Use:

wp db columns wp_posts

The official wp db columns command displays structural information about a database table.

For wp_posts, you may see information such as:

Field
Type
Null
Key
Default
Extra

This is useful when debugging:

• custom tables;
• plugin migrations;
• missing indexes;
• column types;
• schema differences between environments.

Inspect the database through WordPress itself

WordPress exposes the global:

$wpdb

object for database access.

The official wpdb documentation describes it as WordPress’s database abstraction class.

Developers can use it to:

• retrieve rows;
• count records;
• insert data;
• update records;
• delete custom data;
• run prepared SQL.

Example: inspect a table row count

global $wpdb;

$count = $wpdb->get_var(
    "SELECT COUNT(*)
    FROM {$wpdb->posts}"
);

This allows a plugin or diagnostic tool to inspect the database without exposing a general-purpose SQL console.

Use prepared queries for dynamic SQL

If values come from variables, use:

$wpdb->prepare()

The official wpdb::prepare() documentation currently supports placeholders including:

%s
%d
%f
%i

for strings, integers, floating-point values and identifiers respectively.

For the full process, see How to Safely Run SQL Queries in WordPress.

Export the WordPress database with WP-CLI

One of the most useful commands is:

wp db export

The current WP-CLI database documentation supports exporting the database to an SQL file.

A basic command:

wp db export

typically creates an SQL file in the current directory.

Choose the export filename explicitly

wp db export backup.sql

This makes backup handling clearer.

Add DROP TABLE statements when appropriate

WP-CLI supports:

wp db export backup.sql --add-drop-table

This can be useful when the dump is intended to recreate tables during restoration.

However, understand what:

DROP TABLE IF EXISTS

means before importing the file into a database containing data you intend to keep.

Export only selected tables

WP-CLI can export specific tables.

For example:

wp db export selected.sql \
    --tables=wp_posts,wp_postmeta

This can be useful for diagnostics or controlled migrations.

It is not a complete WordPress database backup if other required tables are omitted.

A database export is not a full WordPress backup

The official WordPress database backup documentation makes this distinction explicit.

A database backup can include:

• posts;
• pages;
• settings;
• users;
• comments;
• plugin database data.

It does not normally include:

• plugins;
• themes;
• uploaded files;
• wp-config.php;
• custom server files.

TheOneWP Backup Manager can provide database-only, files-only or complete backup workflows depending on what needs to be recoverable.

Import a database without phpMyAdmin

WP-CLI provides:

wp db import

The official wp db import documentation explains that the command imports SQL from a file or standard input using the database credentials from wp-config.php.

For example:

wp db import backup.sql

Importing can overwrite important data

An SQL dump may contain:

DROP TABLE
CREATE TABLE
INSERT
UPDATE

depending on how it was created.

Never assume:

import
=
merge safely with existing site

A full database import can replace the current application state.

Before importing, create another backup

A sensible sequence is:

current production database
↓
export backup
↓
verify backup exists
↓
perform import
↓
verify WordPress

This gives you a recovery path if the imported database is incorrect.

Check the database before deeper maintenance

WP-CLI provides:

wp db check

The official wp db check command uses database checking facilities to inspect the current database status.

This can help identify database-level table issues.

Database checking is not application debugging

A successful database check does not mean:

• every plugin query is efficient;
• there is no database bloat;
• there are no orphaned records;
• the application data is logically correct.

It means the database tables passed the relevant database-engine checks.

Repair database tables only when there is a reason

WP-CLI also provides:

wp db repair

Repair should be used when table corruption or similar database-engine issues actually require it.

It should not be part of a random weekly maintenance ritual.

Optimize WordPress tables with WP-CLI

Use:

wp db optimize

The official wp db optimize documentation states that the command uses database optimization facilities through mysqlcheck.

Optimization does not remove unnecessary application data

This distinction matters.

Suppose your database contains:

400,000 obsolete revisions
2 GB old logs
100,000 expired records

Running:

wp db optimize

does not magically decide which of those records should be deleted.

Table optimization and data cleanup are different operations.

For that broader distinction, see WordPress Database Bloat, Explained.

Inspect database size from the command line

The wp db command set includes:

wp db size

This can help establish whether database growth is actually significant before cleanup begins.

A useful process is:

measure
↓
investigate
↓
clean
↓
measure again

Table size matters more than assumptions

You may expect:

wp_posts

to be the largest table, only to discover:

wp_postmeta

or a plugin-created log table is substantially larger.

This is why database maintenance should start with inspection rather than deleting whichever table name looks familiar.

Search the WordPress database without phpMyAdmin

WP-CLI provides:

wp db search

The official wp db search documentation states that it searches text columns across database tables.

For example:

wp db search 'old.example.com'

This can help identify:

• old domains;
• plugin settings;
• stale paths;
• stored email addresses;
• specific configuration values.

Search and replace is a separate operation

Finding:

old.example.com

does not mean you should immediately run a SQL:

UPDATE ... REPLACE(...)

WordPress data can contain serialized PHP structures.

Use wp search-replace for WordPress migrations

WP-CLI provides:

wp search-replace

The official wp search-replace documentation states that the command intelligently handles PHP serialized data.

That makes it significantly safer than a naive SQL replacement for many WordPress migration scenarios.

Always start with –dry-run

For example:

wp search-replace \
    'https://old.example.com' \
    'https://new.example.com' \
    --dry-run

This reports what would change without writing the replacements.

Then review:

• tables affected;
• number of replacements;
• unexpected plugin tables;
• environment-specific values.

Serialized data is why generic SQL tools can be dangerous

A serialized value may contain:

string length
+
string content

Changing a URL to a different-length value without recalculating the serialization can corrupt the stored data.

For the full explanation, see Why Serialized Data Breaks Naive WordPress Migrations.

Run SQL directly from WP-CLI when necessary

WP-CLI provides:

wp db query

The official wp db query command executes SQL against the configured WordPress database.

For example:

wp db query "
SELECT COUNT(*)
FROM wp_posts
WHERE post_type = 'revision';
"

Direct SQL is powerful because it bypasses WordPress

That is useful for:

• diagnostics;
• aggregates;
• controlled database maintenance;
• specialized queries.

It also means WordPress application logic may not run.

Prefer read-only queries during investigation

Begin with:

SELECT
SHOW
DESCRIBE
EXPLAIN

before moving to:

UPDATE
DELETE
ALTER
DROP
TRUNCATE

when investigating an unfamiliar database.

Run SELECT before DELETE

Before:

DELETE FROM wp_postmeta
WHERE meta_key = '_obsolete_data';

first inspect:

SELECT meta_id, post_id, meta_key
FROM wp_postmeta
WHERE meta_key = '_obsolete_data'
LIMIT 100;

Then count:

SELECT COUNT(*)
FROM wp_postmeta
WHERE meta_key = '_obsolete_data';

Only after you understand the affected records should deletion even enter the discussion.

For custom development, use $wpdb rather than wp db query

wp db query is useful for administrators and shell workflows.

Inside a plugin or theme, use:

$wpdb

and prepared queries.

For example:

global $wpdb;

$count = $wpdb->get_var(
    $wpdb->prepare(
        "SELECT COUNT(*)
        FROM {$wpdb->posts}
        WHERE post_status = %s",
        'publish'
    )
);

See How to Safely Run SQL Queries in WordPress before building custom database tools.

Open a database console from WP-CLI

The wp db command set also includes:

wp db cli

and:

wp db connect

for opening or connecting to the underlying MySQL or MariaDB command-line environment using WordPress database credentials.

This provides much of the raw database access people use phpMyAdmin for, without requiring a browser-based database interface.

Command-line MySQL is another direct alternative

If you have server shell access, you can use the MySQL or MariaDB client directly.

Typical operations include:

SHOW TABLES;

DESCRIBE wp_posts;

SELECT COUNT(*)
FROM wp_posts;

However, direct database clients know nothing about WordPress application semantics.

They are database tools, not WordPress APIs.

Desktop database clients are another option

The official WordPress database backup documentation also discusses database-management approaches outside phpMyAdmin, including direct MySQL or MariaDB tools and desktop applications such as MySQL Workbench.

Other database clients can provide similar capabilities:

• table browsing;
• SQL editors;
• exports;
• imports;
• schema inspection.

The security consideration is the same: avoid exposing the database server publicly merely to make a desktop client convenient.

Remote database access should be tightly controlled

Allowing MySQL or MariaDB connections from the public internet introduces a much larger attack surface.

Prefer:

• SSH tunnels;
• VPN access;
• restricted source IPs;
• hosting-provider secure tunnels;
• local database proxies;

when remote access is actually required.

Do not expose database credentials casually

WordPress database credentials are usually defined in:

wp-config.php

through constants such as:

DB_NAME
DB_USER
DB_PASSWORD
DB_HOST

A database-management workflow should avoid:

• sending credentials by email;
• committing them to Git;
• embedding them in public scripts;
• storing them in browser-accessible JavaScript;
• sharing unrestricted screenshots containing credentials.

Use TheOneWP Database Manager for browser-based inspection

TheOneWP Database Manager provides a WordPress-integrated way to inspect database tables, structures and records.

This is useful when you need database visibility but do not want to expose a separate phpMyAdmin installation.

Typical investigation questions include:

Which tables exist?

Which table is largest?

What columns does this table contain?

Which records are stored here?

Does this appear to belong to a plugin?

Database inspection and database cleanup are separate jobs

A database-management interface should help you understand what exists.

Cleanup should begin only after that data has been classified.

A sensible sequence is:

inspect
↓
identify
↓
measure
↓
back up
↓
clean
↓
verify

Use Database Optimizer for known cleanup categories

TheOneWP Database Optimizer provides targeted cleanup for supported categories of unnecessary WordPress database records.

This is different from manually deleting arbitrary rows from a table.

Examples of database growth worth investigating

A database may accumulate:

• old post revisions;
• expired transients;
• spam comments;
• trashed comments;
• orphaned metadata;
• old plugin logs;
• abandoned plugin tables;
• large autoloaded options;
• temporary processing records.

Not every item in those categories is automatically safe to delete.

See WordPress Database Bloat, Explained for a systematic cleanup workflow.

Post revisions can be a significant source of growth

WordPress revisions live in the posts architecture.

A heavily edited site may accumulate:

thousands of posts
×
many revisions per post

which can add substantial database volume.

See What Are WordPress Post Revisions, Really? before deleting revision data simply because it exists.

Transients are another frequently misunderstood category

Without a persistent external object cache, transient data is commonly stored in wp_options.

Expired transients may remain physically present until cleanup occurs.

But valid transients are application data, not automatically database waste.

See WordPress Transients Explained.

Inspect wp_options carefully

The wp_options table can contain:

• Core configuration;
• plugin settings;
• theme settings;
• scheduled-event state;
• serialized arrays;
• temporary values;
• autoloaded options.

Deleting an unfamiliar option because its name looks old is not a reliable maintenance strategy.

Autoloaded options deserve special attention

Some option data is loaded automatically during normal WordPress initialization.

Large unnecessary autoloaded datasets can contribute to request overhead.

The correct process is:

measure autoloaded data
↓
identify owners
↓
confirm whether values are still required
↓
remove only known obsolete entries

Do not treat table optimization as database cleanup

These operations solve different problems:

Data cleanup
→ remove unnecessary records

Table optimization
→ database-engine maintenance

Query optimization
→ improve inefficient access patterns

A database may need one, two or none of those.

Query performance should be investigated separately

Suppose a request is slow because of:

SELECT ...
FROM wp_postmeta
WHERE meta_key = ...
AND meta_value = ...

against millions of rows.

Deleting several hundred unrelated post revisions may not materially improve that query.

See Optimizing the WordPress Posts Table for the difference between table size, metadata growth and query performance.

Database management during migrations needs extra care

Migration workflows often involve:

• database export;
• database import;
• domain replacement;
• filesystem-path changes;
• environment-specific settings;
• serialized data;
• plugin custom tables.

See Preparing a WordPress Database for Migration before treating migration as a simple export-and-import operation.

Use staging for risky database maintenance

If a database operation is unfamiliar or destructive, reproduce the environment on staging first.

A useful process is:

production backup
↓
staging clone
↓
run database operation
↓
inspect site
↓
test important workflows
↓
apply production process only when understood

See WordPress Staging Site Best Practices.

Do not assume staging database changes can simply be pushed back wholesale

Production may continue receiving:

• orders;
• user registrations;
• comments;
• form submissions;
• content edits.

Replacing the whole production database with an older staging database can destroy those newer records.

Backup before destructive operations

Before:

DELETE
UPDATE
DROP
TRUNCATE
ALTER
database import
large search-replace

create a current database backup.

For important sites, verify that the backup is:

• complete;
• readable;
• stored outside the database server;
• available if the site becomes inaccessible.

Do not store the only backup inside the same site you are modifying

If the server fails, storing:

backup.sql

only inside that same server does not provide much resilience.

Keep recoverable copies in an independent location.

Protect SQL dump files

A WordPress SQL export can contain:

• user email addresses;
• password hashes;
• private content;
• customer details;
• plugin configuration;
• API credentials stored by plugins;
• session-related data.

Do not leave database exports inside a publicly downloadable directory.

Delete temporary SQL exports when no longer required

After a migration or maintenance operation, remove temporary dumps from:

• web roots;
• public upload directories;
• temporary server folders;
• shared staging environments;

unless they are deliberately part of a protected backup system.

Review database privileges

A database user should have the permissions required for WordPress to function, but it should not automatically have access to unrelated databases on the same server.

At a broader infrastructure level, use least privilege where practical.

Do not give every WordPress administrator raw database access

Being able to manage WordPress settings is different from being able to execute:

DROP TABLE

against production.

Database access should be limited to people who genuinely require it.

Use task-specific tools instead of a generic SQL box

If someone needs to:

clear expired application logs

it is safer to expose:

Expired logs: 12,481

[Preview]
[Delete expired logs]

than:

SQL query:
[_______________________________]

[Run]

A task-specific interface can enforce:

• capability checks;
• nonces;
• known tables;
• known conditions;
• preview behavior;
• safe deletion routines.

When phpMyAdmin is still useful

None of this means phpMyAdmin is inherently a poor tool.

It remains useful when:

• it is securely provided by the hosting environment;
• you need visual table browsing;
• you are comfortable with SQL;
• you need database-level administration outside WordPress.

The point is simply that WordPress database management does not depend on it.

WP-CLI is often better for repeatable workflows

Consider a migration workflow:

wp db export
wp search-replace --dry-run
wp search-replace
wp db check

These commands can be documented, scripted and repeated consistently.

A series of manual clicks through phpMyAdmin is usually harder to reproduce exactly.

Command-line workflows can also work remotely

WP-CLI supports global connection options such as SSH-based execution.

This makes it possible for administrators to run supported operations against remote WordPress environments without exposing a database-management web application publicly.

Choose the right tool for each database task

A practical mapping looks like this:

Inspect WordPress tables
→ Database Manager
→ wp db tables

Inspect table structure
→ Database Manager
→ wp db columns

Database backup
→ Backup Manager
→ wp db export

Restore database
→ wp db import

Search stored data
→ wp db search

Domain migration
→ wp search-replace

Custom SQL
→ $wpdb
→ wp db query

Known database cleanup
→ Database Optimizer

Database engine check
→ wp db check

Database engine optimization
→ wp db optimize

A practical database-management workflow

1. Understand what you need to change.
2. Identify the relevant WordPress tables.
3. Use a WordPress API if one already solves the problem.
4. Inspect the database before modifying it.
5. Measure table sizes and record counts where relevant.
6. Identify plugin-owned custom tables.
7. Create a current backup.
8. Test risky operations on staging.
9. Use WP-CLI or controlled WordPress tooling for the operation.
10. Preview destructive changes where possible.
11. Use serialization-aware search and replace.
12. Verify the affected records afterward.
13. Test the WordPress application.
14. Keep the backup until the change has been verified.

WordPress database management checklist

• Do not assume phpMyAdmin is required.
• Understand the WordPress database structure first.
• Check the active table prefix.
• List Core and plugin tables.
• Identify Multisite table scope when applicable.
• Use WordPress APIs for WordPress-owned objects where possible.
• Use $wpdb for custom application queries.
• Use prepared SQL for dynamic values.
• Use WP-CLI for repeatable database administration.
• Use wp db tables to inspect tables.
• Use wp db columns to inspect schemas.
• Use wp db size to measure the database.
• Use wp db export before risky work.
• Protect SQL backup files.
• Use wp db import carefully.
• Use wp db search for investigation.
• Use wp search-replace --dry-run before replacements.
• Do not use naive SQL replacement on serialized data.
• Use wp db query only when direct SQL is justified.
• Run SELECT before destructive DELETE or UPDATE operations.
• Count affected rows before changing them.
• Use wp db check for database-engine checks.
• Use repair only when a table actually requires repair.
• Do not confuse optimization with data cleanup.
• Do not delete unknown plugin tables.
• Inspect wp_postmeta alongside wp_posts.
• Inspect wp_options before deleting configuration.
• Understand revisions before removing them.
• Understand transients before clearing them.
• Use staging for risky maintenance.
• Keep database credentials protected.
• Restrict remote database access.
• Do not expose arbitrary SQL tools to ordinary administrators.
• Verify WordPress after every important database operation.

Related guides

• The WordPress Database Structure, Explained
• How to Safely Run SQL Queries in WordPress
• WordPress Database Bloat, Explained
• Optimizing the WordPress Posts Table
• Preparing a WordPress Database for Migration
• Why Serialized Data Breaks Naive WordPress Migrations

Final recommendation

phpMyAdmin is only one interface to the database behind WordPress.

You can manage most WordPress database workflows without it by combining:

WordPress APIs
+
$wpdb
+
WP-CLI
+
purpose-built database tools

For routine administration, WP-CLI provides particularly strong coverage. You can inspect tables, export and import databases, search stored values, execute SQL, measure database size, check tables and optimize the database using the credentials WordPress already knows.

For WordPress-aware maintenance, tools such as Database Manager, Database Optimizer and Backup Manager can separate inspection, cleanup and recovery into clearer workflows.

The safest approach is to choose the least destructive tool capable of completing the task.

Use WordPress APIs before direct SQL, inspect before deleting, export before destructive maintenance, use serialization-aware tools for migration changes and test unfamiliar database operations on staging.

Removing phpMyAdmin from the workflow does not mean giving up database control. In many WordPress environments, it simply means moving that control into tools that understand the application better and can be documented, automated and repeated more safely.