What Is the WordPress Database? (Simple Guide)

The WordPress database — what it stores

WordPress runs on MySQL (or its fork MariaDB) — a relational database that stores everything that is not a file: posts, pages, users, settings, comments. The division of WordPress is filesystem versus database — public_html holds the PHP, themes and plugins; the database holds the content and configuration that make them meaningful.

Key points:

• wp_posts is the heart: every post, page, revision and custom post type lives there.

• wp_options carries site settings — and silently collects bloat from careless plugins.

• wp_users and wp_usermeta hold accounts and their capabilities.

• wp_postmeta stores the per-post extras — custom fields, SEO data, templates.

• Credentials live in wp-config.php (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST).

Most 'WordPress is slow' mysteries end in this database — autoloaded options and piled-up revisions, mostly. phpMyAdmin (via cPanel) is the window in; backup before touching anything, always. The revision-limiting fix is the first cleanup, and the WordPress hosting stack runs MySQL/MariaDB tuned for it. The core tables map follows below.

Core tables mapped — posts, postmeta, options, users, terms

A fresh WordPress install creates twelve tables, all sharing the prefix wp_ (changeable at install time). Plugins add their own tables on top, and multisite adds numbered copies per subsite — wp_2_posts for site two, and so on.

Finding your database name in wp-config.php

The database is not a file you can open in the file manager — it lives inside MySQL on your server, and MySQL stores it in its own data directory that only the database engine touches. To identify it, open wp-config.php in the site root (File Manager or FTP) and read the constants at the top: DB_NAME is the database name, DB_USER and DB_PASSWORD the login pair, DB_HOST usually localhost, and $table_prefix the wp_ prefix. Hosting panels show the same names under their MySQL Databases section.

Accessing phpMyAdmin via cPanel safely

In cPanel, open phpMyAdmin (under Databases), pick your DB_NAME from the left column, and the twelve tables appear. Browsing is safe; editing is not — phpMyAdmin writes changes the instant you click Go, with no undo. Three rules: never run an UPDATE or DELETE without a WHERE clause (it rewrites or removes the whole table otherwise), export a backup first, and close the tab when done. Adminer offers the same access as a single PHP file, and WP-CLI covers common jobs (wp db export, wp search-replace) without any web interface.

wp_options bloat — autoloaded rows

wp_options stores settings as key-value rows: siteurl, the tagline, the serialized list of active plugins. Each row carries an autoload flag — anything marked yes is loaded into memory on every page request. A healthy site autoloads a few dozen rows; a neglected one can carry thousands left behind by deactivated plugins and expired transients, slowing every request. Check the weight with SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes'; in phpMyAdmin — over roughly 1 MB is a smell worth cleaning.

Optimization — revisions, transients, table cleanup

Four cleanups cover most slow-database cases. First, cap revisions — WordPress stores unlimited copies of every post by default; set define( 'WP_POST_REVISIONS', 10 ); in wp-config.php and prune the backlog. Second, delete expired transients (DELETE FROM wp_options WHERE option_name LIKE '\_transient\_%'; after a backup — they rebuild themselves). Third, empty the trash and spam comment queues so those rows actually leave the database. Fourth, run OPTIMIZE TABLE on the heavyweights (wp_posts, wp_postmeta, wp_options) to reclaim space — phpMyAdmin's operations tab or a plugin like WP-Optimize does it in one click.

Backup before touching anything

Every step above assumes a backup exists. In phpMyAdmin, select the database, choose Export, and download a compressed .sql file — thirty seconds for most sites. Hosting backups cover you too, but keep a copy off the server (your computer or cloud storage), because a hacked site and its backups are often compromised together. And test the restore once on a staging copy: an untested backup is a hope, not a plan.