What Is the WordPress Database?
The WordPress database is the MySQL (or MariaDB) database where WordPress stores everything dynamic: your posts and pages, comments, users, settings, and menus. WordPress separates content from design and code, so while your theme and plugins live in files, the actual words, options, and relationships live in database tables like wp_posts, wp_options, and wp_users. Every page load runs queries against this database to assemble what visitors see. Understanding it helps explain backups, migrations, performance, and why editing the database directly is powerful but risky without care.
- Engine
- WordPress uses a MySQL or MariaDB relational database to store dynamic content (WordPress Requirements)
- Core tables
- Default installs have about a dozen tables, including wp_posts, wp_options, and wp_users (WordPress Developer docs)
- Content lives here
- Posts, pages, comments, users, and settings are stored in the database, not in theme files
- Table prefix
- Tables share a prefix, wp_ by default, set in wp-config.php for the connection
- Managed via
- Tools like phpMyAdmin, Adminer, or WP-CLI, plus the WordPress dashboard itself
What the WordPress database holds #
The WordPress database is where your site's living content and settings are stored, kept in a MySQL or MariaDB database on your server. WordPress deliberately separates content from code: your theme files control appearance and your plugins add features, but the actual text of every post and page, all your comments, user accounts, site options, and navigation menus live in the database. When a visitor loads a page, WordPress runs queries to pull the right rows and assembles the page on the fly. This separation is why you can change themes without losing your writing, and why a backup must include both files and the database to be complete. Grasping this split clarifies a lot: why migrations move two things, why a database problem can take a site down even when files are fine, and why serious /services/database-services exist. The database is, in a real sense, the heart of a WordPress site, holding everything that makes it yours.
The core tables explained #
A standard WordPress install creates about a dozen tables, all sharing a prefix, wp_ by default. The most important is wp_posts, which despite its name stores posts, pages, menu items, and other content types, distinguished by a post_type column. wp_postmeta holds extra data attached to those items, like custom fields. wp_options stores site-wide settings and is loaded heavily on every request. wp_users and wp_usermeta keep accounts and their details. wp_comments and wp_commentmeta store discussion. wp_terms, wp_term_taxonomy, and wp_term_relationships together manage categories and tags. Knowing these tables demystifies how WordPress works and why certain operations behave as they do. For instance, a bloated wp_options table with too much autoloaded data slows every page, a common finding during /services/speed-optimization work. You rarely touch these tables directly in normal use, but understanding their roles helps you reason about backups, performance, and what a plugin is really doing when it stores or reads data behind the scenes. Knowing which table holds what also helps you judge whether a plugin's promised feature is storing data sensibly or bloating the site over time.
How WordPress connects to the database #
WordPress finds and connects to its database using credentials stored in the wp-config.php file at the root of the installation. This file holds the database name, username, password, host, and the table prefix. On every request, WordPress reads these settings and opens a connection so it can run the queries that build each page. If any credential is wrong, perhaps after a botched move, you get the dreaded Error establishing a database connection message, and the site goes dark. The example below shows the relevant lines. Because wp-config.php contains the keys to all your content, it is a sensitive file that must be protected, a routine concern in /services/website-security. During a move, matching these settings to the new server's database is a critical step, and a mismatch is one of the most common migration failures. Understanding that this small file is the bridge between WordPress and its data explains why a single wrong character in it can bring down an otherwise healthy site instantly.
// wp-config.php: how WordPress connects to its database
define('DB_NAME', 'my_wordpress_db');
define('DB_USER', 'db_username');
define('DB_PASSWORD', 'strong_password_here');
define('DB_HOST', 'localhost'); // sometimes an IP or host:port
// Table prefix (default wp_) for this install
$table_prefix = 'wp_';Why the database matters for backups #
A complete WordPress backup has two halves: the files and the database. Many owners assume copying their files backs up their site, but the files are only themes, plugins, uploads, and core code. Every word you have written, every setting, every comment, lives in the database. Restore only the files after a disaster and you get an empty shell with no content. That is why reliable backup routines always export the database alongside the files, and why restoring means importing both. This two-part reality is fundamental to /services/managed-hosting and to any credible /services/care-plans, where automated backups capture the database on a schedule. It also explains why database corruption is so serious: lose or damage that data without a backup and the content is simply gone. Understanding the database-plus-files split turns backup from a vague safety net into a concrete practice you can verify, ensuring that when you say you have a backup, you actually have everything needed to bring the whole site back.
The database during migrations #
Moving a WordPress site means moving both its files and its database, and the database part is where things most often go wrong. Beyond copying the data, you usually must update stored URLs, since the database is full of references to the old domain in content, settings, and widgets. Doing this correctly requires a serialized-data-aware search-and-replace, because WordPress stores some values as serialized PHP that breaks if edited naively. You also have to update wp-config.php with the new server's database credentials and confirm the table prefix matches. Skip or fumble any of these steps and you get connection errors, mixed old and new URLs, or a login loop. This is why /services/website-migrations is a real skill rather than a simple file copy. A careful migration exports the database, imports it cleanly, runs the correct replacements, and verifies the site end to end, so the move is invisible to visitors and nothing, from menus to plugin settings, quietly breaks along the way.
Database performance and bloat #
Over time, a WordPress database can slow down as it accumulates clutter. Post revisions pile up, storing dozens of drafts per article. Expired transients, spam comments, and orphaned metadata from deleted plugins linger in the tables. The wp_options table can balloon with autoloaded data that WordPress reads on every single request, dragging down page speed even for cached pages. Cleaning and optimizing the database, removing excess revisions, clearing stale transients, and trimming autoloaded options, is a standard part of /services/speed-optimization. It should be done carefully, ideally with a backup and a trusted plugin or WP-CLI rather than blind manual deletion. A lean, well-indexed database answers queries faster, which means quicker page assembly and a snappier site. For growing businesses whose sites have run for years, database bloat is a common, invisible drag that a targeted cleanup can noticeably relieve, and it is one of the more cost-effective performance improvements available because it addresses a root cause rather than masking it.
Editing the database directly #
Sometimes a fix requires touching the database directly, through a tool like phpMyAdmin or Adminer, or via WP-CLI. This might be needed to reset a password when locked out, disable a broken plugin that blocks the dashboard, or correct a bad setting. Direct editing is powerful, but it is also unforgiving: there is no undo, and a wrong query can corrupt or delete data instantly. The cardinal rule is to take a full database backup before any manual change, and to know exactly what a query does before running it. Serialized data adds risk, since editing it by hand can break it. Because of these stakes, direct database work is best left to developers, and it is a routine part of /services/website-rescue when the normal dashboard route is unavailable. For a business owner, the practical takeaway is simple: the database is not a place to experiment casually, and any direct edit should be backed up first and, ideally, handled by someone experienced.
Keeping your database healthy #
A healthy WordPress database is backed up regularly, kept reasonably lean, secured against unauthorized access, and moved carefully when the site relocates. You do not need to understand SQL to benefit from these practices; you need a setup that follows them. That means scheduled backups covering both files and database, periodic cleanup of revisions and stale data, strong protection of wp-config.php and database credentials, and professional handling during any migration. These are exactly the assurances that quality /services/managed-hosting and ongoing /services/care-plans provide. For most owners, the database should be invisible, quietly doing its job while you focus on your business. Trouble usually appears only when it is neglected: no backups before a crash, bloat slowing the site, or a fumbled move breaking content. If you are unsure whether your database is being backed up, secured, and maintained properly, a quick /free-website-audit can check, and it is one of the more important things to verify about any WordPress site you rely on.
FAQ
Where is my WordPress content actually stored?
In the database, not in your theme files. Posts, pages, comments, user accounts, and settings all live in MySQL or MariaDB tables like wp_posts and wp_options. Your theme and plugins are files that control design and features, but the actual content and configuration are database rows, which is why a full backup must include both.
What are the main WordPress database tables?
The key ones are wp_posts (posts, pages, menu items), wp_postmeta (custom fields), wp_options (site settings), wp_users and wp_usermeta (accounts), wp_comments (discussion), and the wp_terms group (categories and tags). A default install has about a dozen tables sharing the wp_ prefix. Plugins may add more tables of their own.
What causes Error establishing a database connection?
Usually wrong database credentials in wp-config.php, a database server that is down or overloaded, or a corrupted database. It often appears after a migration when the new server's database name, user, password, or host do not match. Check those settings first, then contact your host if the database server itself is unresponsive.
Can I edit the WordPress database directly?
Yes, with tools like phpMyAdmin or WP-CLI, but it is risky because there is no undo and a wrong query can corrupt data. Always take a full backup first, and be especially careful with serialized data, which breaks if edited by hand. Direct edits are best left to experienced developers.
Why is my database making the site slow?
Common causes are bloat: piles of post revisions, expired transients, spam, and a swollen wp_options table with too much autoloaded data that loads on every request. Cleaning and optimizing the database, ideally with a backup and a trusted tool, often speeds things up. Database cleanup is a standard part of performance optimization.
Do I need to back up the database separately?
Your backup must include the database, but it does not have to be a separate manual step if your host or care plan backs up files and database together. Just files alone is not a real backup, because all your content lives in the database. Confirm your backups cover both to be truly safe.
How Local Web Advisor checks this for you
Is your own website getting web dev right?
Our free AI audit scans your site and tells you — in plain English — exactly what to fix for web dev and seven other areas, with the business impact and the fix for each. No login needed to start.
Run my free website audit →Was this helpful?