WordPress Database Error: Table Doesn't Exist

Why it happens

• The table name differs in letter case, for example WP_Options instead of wp_options. On a server where table names are case-sensitive, which is the Linux default, these are two different tables.
• A table was lost: a partial import, a backup that skipped it, a failed plugin uninstall or a manual DROP TABLE.
• A plugin's own table is missing. The plugin created it once, on activation, and a migration or restore did not bring it along.
• The database was restored into the wrong database, or the DB_NAME in wp-config.php points at an empty one.
• The table_prefix in wp-config.php does not match the prefix of the tables in the database. This is common after a migration, a restore, or when someone changes the prefix for security. This one prints no message. Visitors get the install screen, so it is the cause to suspect when you see that screen.

How to fix it

Try the fixes in this order. Each one is independent: stop as soon as the error is gone.

WordPress built a table name from the prefix in wp-config.php and the database says that table is not there. Either the table is really missing, or it exists under a different prefix or letter case. Compare the prefix and the real table names first. The rest follows from that.

The message you search for is only one of three things owners see. Which one depends on which table is missing and whether WordPress is allowed to print errors.

What you see#

I broke a lab site (WordPress 7.1.4, MariaDB 10.6) in four ways and recorded what a visitor sees each time.

So the search-engine version of this error is mostly a log line. A site that is down with a missing options table never prints it. If your site shows a blank heading, read Error establishing a database connection as well.

This is the message in wp-content/debug.log, from a lab site where I renamed wp_postmeta:

[30-Oct-2026 12:41:34 UTC] WordPress database error Table 'lab_f31_wordpress_database_error.wp_postmeta' doesn't exist for query SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (1) ORDER BY meta_id ASC made by require('wp-blog-header.php'), wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts, _prime_post_caches, update_postmeta_cache, update_meta_cache

The page still answered 200. With WP_DEBUG and WP_DEBUG_DISPLAY both on, the same error also printed at the very top of the page, above the doctype:

<div id="error"><p class="wpdberror"><strong>WordPress database error:</strong> [Table 'lab_f31_wordpress_database_error.wp_postmeta' doesn't exist]<br /><code>SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (1) ORDER BY meta_id ASC</code></p></div>

A wp_options / siteurl version of the message appears when WordPress is not allowed to stop. That happens on the repair page, which a lot of guides tell you to open:

How WordPress picks the table name#

Every core table name is the prefix from wp-config.php plus a fixed name: posts, postmeta, options, and so on. WordPress sends that name to the database exactly as built. If the database cannot find it, it answers that the table does not exist, and WordPress logs the text above. Nothing is guessed or retried.

Before the page runs, is_blog_installed() reads siteurl from the options table with errors muted. If it finds a value, the site is installed. If not, it describes each core table. No table at all means a fresh site, so you get the install screen. At least one table found means a damaged site, so you get the unavailable-tables message. That is why a wrong prefix and a missing options table look so different to visitors.

The prefix may use only letters, numbers and underscores, as the comment in wp-config.php says. If it has anything else, WordPress stops with an error about the prefix.

Do not click through the install screen#

A wrong prefix sends the site to the install screen. If you finish the installer, WordPress creates a full new set of tables with the wrong prefix next to your real ones. I did this on the lab site with wp core install and a wrong prefix:

wp core install --url=http://localhost:8903 --title="Fresh install" --admin_user=admin2 --admin_email=a@example.com --admin_password=...

Success: WordPress installed successfully.

The database then held both wp_posts and wrong_posts, each with its own users and options. Setting the prefix back to wp_ brought the original site back unharmed, so nothing was lost. The new tables stay behind until you delete them.

WP-CLI is more helpful than the browser here. With the same wrong prefix, wp db tables --all-tables-with-prefix says which prefix it found:

Error: The site you have requested is not installed.Your table prefix is 'wp_'. Found installation with table prefix: WP_.Or, run `wp core install` to create database tables.

That one line is the answer. Use wp config set table_prefix WP_ to match it.

Letter case and migrations#

MySQL's lower_case_table_names setting decides whether wp_options and WP_Options are the same table. The default is 0 on Linux, 1 on Windows and 2 on macOS. On the Linux lab database it was 0, so after RENAME TABLE wp_options TO WP_Options WordPress could not find wp_options.

The usual path to this problem: a site is built on a Windows or Mac laptop where the case did not matter, then moved to a Linux server where it does. Any table whose case differs from what WordPress builds is simply missing. WordPress core and most plugins write names in lower case, but some plugins use mixed case. Rename the tables, as in the fix above, or set the prefix to the case used in the database. Do not change lower_case_table_names on a live server. MySQL does not allow changing it after the server is first set up.

Missing plugin tables#

Plugins that keep their own data create their tables once, when you activate them. A migration that skips those tables, or a restore from a partial backup, leaves the plugin running with no table. Every page view then logs the error. The page still loads, because WordPress cannot tell the plugin is broken.

To test it I wrote a small plugin that creates wp_dvl_visits when you activate it and writes one row on every page view, in the wp_footer hook. After I dropped the table, the log said:

[30-Oct-2026 12:41:08 UTC] WordPress database error Table 'lab_f31_wordpress_database_error.wp_dvl_visits' doesn't exist for query SHOW FULL COLUMNS FROM `wp_dvl_visits` made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('wp-includes/template-canvas.php'), wp_footer, do_action('wp_footer'), WP_Hook->do_action, WP_Hook->apply_filters, {closure}

The table name is the clue, and the made by chain shows when the query ran (here, in the footer). Searching the plugin and theme folders for the name finds the file:

$ grep -rl "dvl_visits" wp-content/plugins wp-content/themeswp-content/plugins/dvl-visits/dvl-visits.php

After wp plugin deactivate dvl-visits and wp plugin activate dvl-visits, the table was back and the log stayed empty.

To see every core table WordPress expects that the database lacks, run this on a site that still loads:

wp eval 'global $wpdb; $have = $wpdb->get_col( "SHOW TABLES" ); foreach ( $wpdb->tables( "all" ) as $t ) { if ( ! in_array( $t, $have, true ) ) { echo "missing: $t\n"; } } echo "done\n";'

done

"done" with no missing: lines means every core table is there. This only looks at core tables, not plugin tables.

Back up first, then restore one table#

Before any repair, back up the database as it is. A broken database is still the best copy you have of what survived. With WP-CLI: wp db export before-fix.sql. In phpMyAdmin: open the database, choose Export and keep the default settings. WP-CLI cannot do this when the options table is missing, so use phpMyAdmin then.

If you have a backup of the missing table, import only that table. In phpMyAdmin, open the backup file in a text editor, copy the CREATE TABLE and INSERT statements for that one table, and run them on the SQL tab. Importing a full dump over a working database replaces every table in it, and everything written since that backup is lost.

If you changed settings while repairing, find and undo changed settings helps you check them. If the database cannot be reached at all, see error establishing a database connection.

After it is fixed#

• Reload the front page and /wp-admin/, then check the log is quiet: empty debug.log, reload a few pages, and check that nothing new is written.
• Remove WP_ALLOW_REPAIR from wp-config.php if you added it. The repair page needs no login while it is set.
• Turn WP_DEBUG off again on a live site.