What Is the WordPress Database?
The WordPress database is a MySQL or MariaDB database holding everything edited in the dashboard: posts, pages, users, comments and settings, across 12 core tables such as wp_posts and wp_options. Its name and login sit in wp-config.php, and phpMyAdmin in your hosting panel opens it. Images, themes and plugins stay as files.
For WordPress site owners who need to find, read, back up or clean their database without breaking the site.
knowledge
- Read time
- 4 min
- Sections
- 7
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
What the WordPress database stores, and what it does not
The WordPress database holds everything that changes through the dashboard: posts, pages, comments, users, menus and settings. Everything else is files in public_html: WordPress core PHP, themes, plugins and the wp-content/uploads folder with your images.
| In the database | In files on disk |
|---|---|
| Post and page text, revisions, menus | WordPress core, wp-config.php, .htaccess |
| Users, hashed passwords, roles | Theme and plugin code |
| Comments, categories, tags | Uploaded images and PDFs (only their record sits in wp_posts) |
| Site URL, active theme and plugin list, widget settings | Cache files written by caching plugins |
This split is why a backup needs both halves. A database export alone restores your words but not your images; a file copy alone restores the design but not a single post.
Which database engine WordPress uses
WordPress runs on MySQL or MariaDB; WordPress.org currently recommends MySQL 8.4 or MariaDB 10.11 or newer, alongside PHP 8.3 or newer. MariaDB began as a MySQL fork and WordPress talks to both in the same way.
Older engines still start WordPress — the requirements page notes it works on MySQL 5.5.5 and PHP 7.4 — but those versions are past end of life. If your panel shows an older version, ask your host before blaming a plugin for slow queries.
The 12 core tables of a WordPress database
A single-site WordPress install creates 12 tables, each starting with the prefix set in wp-config.php, wp_ by default. Plugins add their own tables, and multisite adds a numbered set per subsite (wp_2_posts for site two) plus network tables such as wp_blogs and wp_sitemeta.
| Table | What it stores |
|---|---|
| wp_posts | Posts, pages, revisions, menu items, attachments and custom post types, one row each |
| wp_postmeta | Per-post extras: custom fields, SEO plugin data, page template choice |
| wp_comments / wp_commentmeta | Comments, author IP, approval state and extra comment data |
| wp_users / wp_usermeta | Accounts, hashed passwords, roles and capabilities |
| wp_terms, wp_term_taxonomy, wp_term_relationships | Categories and tags, their type, and which post carries which |
| wp_termmeta | Extra data per category or tag |
| wp_options | Site settings: URL, tagline, active plugins and theme, cached values |
| wp_links | Legacy blogroll; the Links manager has been hidden since WordPress 3.5 |
On a WooCommerce store, wp_postmeta usually becomes the biggest table first, because every product attribute and older-style order field is a separate row there.
How to find your WordPress database name in wp-config.php
Open wp-config.php in the site root and read four constants: DB_NAME, DB_USER, DB_PASSWORD and DB_HOST. The database lives inside the MySQL server, not as a file you can open in File Manager.
define( 'DB_NAME', 'example_wp' );
define( 'DB_USER', 'example_wpuser' );
define( 'DB_PASSWORD', '••••••••' );
define( 'DB_HOST', 'localhost' );
$table_prefix = 'wp_';DB_HOST is usually localhost on shared hosting. If these values do not match the database and user listed in your panel, WordPress shows "Error establishing a database connection"; the database connection error fix walks through each mismatch.
Opening the database safely in phpMyAdmin
Open phpMyAdmin from your hosting panel, pick the database whose name matches DB_NAME, and browse; treat every edit as permanent. phpMyAdmin runs a query the moment you click Go, and there is no undo button.
- Export first: select the database, choose Export, and keep the .sql file; exporting a database from phpMyAdmin covers the options.
- Always use WHERE: an UPDATE or DELETE without a WHERE clause changes or removes every row in the table.
- Avoid raw find-and-replace on URLs: serialized data in wp_options and wp_postmeta stores string lengths, so a plain SQL replace can break widgets.
wp search-replacehandles serialization.
Checking wp_options autoload bloat after WordPress 6.6
Autoloaded options load on every request, and WordPress 6.6 changed how they are labelled, so old "autoload = 'yes'" queries now miss rows. New or updated options are stored as on, off, auto, auto-on or auto-off; rows marked yes, on, auto-on and auto are the ones WordPress loads.
SELECT SUM(LENGTH(option_value)) AS autoload_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Since 6.6, Site Health reports "Autoloaded options could affect performance" when this total passes 800 KB, and WordPress stops auto-loading any single option above 150,000 bytes unless a plugin explicitly asks for it. Change the table prefix in the query if yours is not wp_.
Cleaning the WordPress database without breaking it
Four jobs cover most slow databases: cap revisions, clear expired transients, empty spam and trash, then optimise the largest tables. Run them after an export, in this order.
- Cap revisions by adding
define( 'WP_POST_REVISIONS', 10 );to wp-config.php; WordPress keeps unlimited revisions by default. The revision limit guide shows how to prune the backlog. - Delete only expired transients with
wp transient delete --expired. A SQL delete on every_transient_row also removes live cache entries and their timeouts. - Empty the comment spam queue and the trash for posts and pages so those rows actually leave wp_posts and wp_comments.
- Run
wp db optimizeor phpMyAdmin's Optimize table on wp_posts, wp_postmeta and wp_options to reclaim space. Deeper checks are in repairing and optimising a MySQL database.
Check the result with wp db size --tables, which lists each table's size so you can see what actually shrank.
Backing up the database before any change
Export the database to a .sql file and keep one copy off the server before every cleanup, plugin removal or migration. wp db export or phpMyAdmin's Export does it in under a minute for most small sites.
Store that copy on your computer or cloud storage, because a compromised account can take its on-server backups with it, and test a restore once on a staging copy. On WebJi® WordPress hosting (ControlPanel.Systems), the panel also offers self-service file and MySQL restores for the last 30 days, and each MySQL database can grow to 1 GB.
Frequently asked questions
Can I change the wp_ table prefix on a live site?
Yes, but it takes more than editing $table_prefix. You must rename every table and update the prefixed keys inside wp_options and wp_usermeta, such as wp_user_roles and wp_capabilities, or admins lose access. Export a backup first; the security gain is small.
Why is wp_postmeta so much bigger than wp_posts?
Each post has one row in wp_posts but can have dozens in wp_postmeta: custom fields, SEO plugin data, page builder layouts and product attributes. Plugins that are removed often leave their meta rows behind, which is where most cleanup gains come from.
Can two WordPress sites share one database?
They can, as long as each uses a different $table_prefix, such as wp_ and blog_. It works, but one export then contains both sites and one bad query can damage both, so a separate database per site is the cleaner setup when your plan allows it.
Does deleting a plugin remove its database tables?
Only if the plugin includes an uninstall routine that does so. Many leave their tables and wp_options rows in place so settings survive a reinstall. Check the plugin's settings for a "delete data on uninstall" option, or remove leftover tables after a backup.
Last editorial update: 14 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.