Check Your WordPress Database Version Before MySQL 8.0 Bites

MySQL 8.0 reached end of life on 30 April 2026, and MariaDB 10.6 followed on 6 July 2026. If your WordPress site still runs on one of them, it keeps working today, but the database server under it no longer gets community security fixes from its makers.

The good news is that finding out takes one command and about two minutes. By the end of this guide you will know your exact database version, how it compares with what WordPress recommends, how to take a safe copy of your data first, and what to send your host.

What is the database version, and why should you care?

Your WordPress site has two halves. The files (themes, plugins, images) live on disk, and everything you type (posts, pages, orders, settings) lives in a database.

The database server is the program that stores and hands out that data. On most hosting plans it is either MySQL or MariaDB, two close cousins that speak almost the same language.

Think of it like the engine in a car. You drive the car (WordPress) every day and rarely look under the bonnet, but the engine has its own model year, and once the maker stops making parts for that year, every repair gets harder.

End of life (EOL) means the project behind that version has stopped publishing fixes for it. The software does not switch off. It simply stops getting patched when new problems are found.

Why this matters: WordPress still runs on very old versions (the 7.1 page lists MySQL 5.5.5 as the absolute minimum), so nothing on your screen will warn you.

Here is what the WordPress hosting team says for WordPress 7.1, released 19 August 2026. For new installs it recommends MySQL 8.4.x, or MariaDB 10.11.x, 11.4.x or 11.8.x.

The same page says MySQL 8.0 "reached end of life on 30 April 2026 and should no longer be used". It also says MariaDB 10.6 "reached end of life on 6 July 2026 and is no longer listed". It adds a clear rule: a version that is end of life upstream is never recommended, even when WordPress still runs on it.

Earlier, the WordPress 7.0 page (released 20 May 2026) already advised that sites on MySQL 8.0 "should be migrated to 8.4 LTS". LTS means long term support: a release line that gets fixes for years instead of months.

Before you start

• Access to your hosting account, usually cPanel or a similar control panel. If you are new to how hosting fits together, our guide on what web hosting is gives you the big picture first.
• SSH access, which is a way to type commands on your server from a text window. Some hosts switch it on by default, some only on request.
• WP-CLI on the server. WP-CLI is the official command line tool for WordPress, so you can manage the site by typing commands instead of clicking. Many hosts install it for you.
• About 15 minutes, plus a little more if your database is large.
• A place to keep a backup file, such as your own computer.

Risk level: reading the version is completely safe. It only asks a question and changes nothing. Taking an export is also safe; it reads your data and writes a copy to a file.

The risky part is the actual upgrade of the database server. That is your host's job on shared hosting, and this guide does not ask you to do it yourself.

Heads up: if you do not have SSH, skip to the "no SSH, no WP-CLI" variant further down. You can still get the answer by asking your host the right question.

How to check your WordPress database version with WP-CLI

Step 1: Confirm you have SSH and WP-CLI

First, log in to your server over SSH. Your host gives you the address, username and port, usually in their welcome email or help pages.

Heads up: cPanel also has a built-in Terminal feature, but cPanel's own documentation says your host must enable the "SSH Access & Terminal" feature for it to appear. cPanel also warns that commands entered there "can render your cPanel account inoperable", so type carefully and only run the commands below.

Once you see a command prompt, run this to check that WP-CLI exists and works.

wp --info

You should see a short report that includes your operating system, the PHP binary and its version, and the WP-CLI version. If you see that, you are ready for the next step.

If the shell says the wp command is not found, WP-CLI is either missing or installed under another name. Ask your host first, because on shared hosting you usually cannot install system-wide tools yourself. The official install guide uses sudo, which shared plans normally do not allow.

Quick tip: the WP-CLI handbook says WP-CLI needs PHP 7.2.24 or later. WordPress 7.0 and 7.1 already need PHP 7.4 or later, so any server that runs a current WordPress clears that bar.

Step 2: Go to your WordPress folder

WP-CLI needs to run inside the folder that holds your WordPress files. That folder contains wp-config.php, the file WordPress uses to store its database connection details.

The command below moves you into a typical WordPress folder on cPanel hosting. Change public_html to your real folder if your site lives somewhere else, such as an addon domain folder.

cd ~/public_html

To confirm you are in the right place, list the config file.

ls -l wp-config.php

You should see one line describing wp-config.php. If you get "No such file or directory", you are in the wrong folder.

Quick tip: if you installed WordPress through Softaculous, the folder is the one you picked during setup. Our guide on installing WordPress in cPanel with Softaculous walks through where that path comes from.

Step 3: Ask the database server for its version

Now the main event. This command asks the database server which version it is, using the database name, user and password already stored in wp-config.php, so you never type your password.

wp db query 'SELECT VERSION();' --skip-column-names

SELECT VERSION(); is a tiny SQL question that means "what version are you?". The --skip-column-names option tells WP-CLI to leave out the header row, so you get a clean answer.

You should see a single line with a version number. On MySQL it might look like the example from the MySQL manual, 8.4.11-standard. On MariaDB it usually carries a -MariaDB ending, like the example in the MariaDB docs, 10.4.7-MariaDB.

The MySQL manual says the value "might have a suffix in addition to the version number". So ignore the text after the first dash for now and look at the first two numbers, such as 8.4 or 10.11.

Heads up: do not confuse this with wp core version --extra. That command shows a line called "Database revision", which is an internal WordPress schema number, not your MySQL or MariaDB version.

Step 4: Compare your version with the WordPress list

Take the first two numbers from Step 3 and find them in the list below. At the time of writing (17 October 2026), this is how they line up with the WordPress 7.1 hosting page and the endoflife.date tracker.

• MySQL 8.4: recommended by WordPress for new installs. endoflife.date lists premier support to 30 April 2029 and extended support to 30 April 2032.
• MySQL 8.0: ended 30 April 2026. WordPress says it "should no longer be used".
• MySQL 5.7 or older: endoflife.date shows 5.7 support ended on 31 October 2023.
• MariaDB 10.11, 11.4 or 11.8: recommended by WordPress. endoflife.date lists community support for 10.11 to 16 February 2028, 11.8 to 4 June 2028 and 11.4 to 29 May 2029.
• MariaDB 10.6: community support ended 6 July 2026, and WordPress no longer lists it.
• MariaDB 10.5 or older: endoflife.date shows 10.5 community support ended on 24 June 2025.

If your number sits in the recommended group, you are fine for now. Make a note of the end date in your calendar and move on with your day.

If your number sits in an ended group, keep going. The next step protects you before anyone touches the server.

Why this matters: endoflife.date also lists paid enterprise support for MariaDB 10.6 running to 23 August 2029. So a host on 10.6 may have a support contract you cannot see from outside. That is exactly why the right move is to ask, not to panic.

Made-up example: Sara runs a small bakery site on a shared plan. She runs the command in Step 3 and sees a version starting with 8.0. Her site works fine, orders come in, nothing looks broken, yet her database server stopped getting security fixes in April. She does not touch any server settings. She takes an export (Step 5), downloads it, and sends her host the message at the end of this guide.

Step 5: Take a safe export of your database first

Before you ask anyone to upgrade anything, keep your own copy of the data. An export is a single .sql text file that holds every table and row, and it can be imported back if something goes wrong.

Run the commands as the user who owns the site files, from the WordPress folder selected in Step 2. First verify in your hosting panel or web-server configuration that $HOME is outside every actual document root and is not exposed through a web-server alias or symlink. If it is served, replace $HOME below with an existing private parent directory owned by you and not served by any site. These commands export directly into a new owner-only directory (700), with an owner-only file (600), and print the export path when finished.

backup_dir="$(mktemp -d "$HOME/wordpress-db-backup.XXXXXXXX")" &&
chmod 700 "$backup_dir" &&
(umask 077 &&
 wp db export "$backup_dir/db-before-upgrade.sql" --porcelain &&
 chmod 600 "$backup_dir/db-before-upgrade.sql")

WP-CLI uses the mysqldump tool and the credentials from wp-config.php behind the scenes. The --porcelain option makes it print just the file name, which is handy for scripts and for copying.

Save the exact export path printed above. Continue only if every command succeeds. In the same SSH session, check the directory permissions, file permissions and size:

ls -ld "$backup_dir" &&
ls -lh "$backup_dir/db-before-upgrade.sql"

The directory should show drwx------ (700) and the file -rw------- (600), both owned by your account. You should see a nonzero file size that roughly matches your site. If you reconnect later, use the exact saved path instead of $backup_dir/db-before-upgrade.sql. To compare, this next command shows how big WP-CLI thinks your database is.

wp db size

You should see a small table with your database name and a size in MB. The export file is plain text, so its size will not match exactly, but a 0 byte file means the export failed.

Finally, download the file to your own computer with SFTP or your host's file manager. A backup that only lives on the same server is not much of a backup.

Security note: an .sql export contains your user table, including email addresses and password hashes. Keep it outside every web-served directory, download it securely, then delete the server copy when you no longer need it. A nonempty file alone does not prove recovery will work; test a restore on an isolated staging site before an upgrade, never on the live database as a check.

Quick tip: always pass the explicit private output path to wp db export. If you omit it, WP-CLI writes its generated file in the current directory, which is the web folder in this walkthrough. Moving it afterwards leaves an exposure window. Rerun Step 5 to create a new private directory for each fresh backup.

Step 6: Ask your host for a plan

You now have facts instead of a worry: an exact version number and a fresh backup. Send those to your host and ask what they intend to do.

Ask for a date, ask whether your site will be moved to a different server, and ask whether they will take their own backup first. The ready-to-send message at the end of this guide covers all of it.

Variants

cPanel MySQL Databases page

cPanel has a MySQL Databases interface where you create databases and users. According to cPanel's documentation, it shows your current databases with their size, privileged users and actions, plus tools to check and repair a database.

It does not show the database server version, so it cannot replace Step 3. It is still useful for one thing: confirming the database name that wp-config.php points to really exists.

Heads up: cPanel's docs say renaming a MySQL database is "potentially dangerous" and ends all active connections to it. Do not rename anything as part of this check.

Plesk or DirectAdmin

If your host uses Plesk or DirectAdmin, the commands in Steps 1 to 5 are exactly the same, because they run over SSH and do not depend on the control panel. I have not listed panel menu paths for these panels here, because they vary by version and host setup.

No SSH, no WP-CLI

Some plans have no SSH at all. That is fine. You can still get the answer by asking your host to run the same check for you.

Open a support ticket and ask two plain questions: is my database server MySQL or MariaDB, and what is its exact version number? Ask them to also confirm that they hold a recent backup of your database.

Quick tip: do not guess the version from a screen in WordPress. The official Site Health documentation (Tools > Site Health > Info) has a Database section, but the page does not describe what that section contains, so I am not going to promise you will find the server version there.

How to check it worked

Run through these checks once you have done the steps, and again after your host makes any change.

• wp --info prints a report with PHP and WP-CLI versions. This proves WP-CLI works on your account.
• wp db query 'SELECT VERSION();' --skip-column-names prints one version line. After a host upgrade, the first two numbers should match a recommended version, such as 8.4 or 10.11.
• wp db check prints Success: Database checked. This runs the mysqlcheck tool with its check option on your tables.
• ls -lh "$backup_dir/db-before-upgrade.sql" (or the exact path you saved in Step 5 after reconnecting) shows an owner-only file larger than 0 bytes, and the same file now sits on your own computer.
• Your homepage, a single post and your login page all load in a private browser window after any change.

Troubleshooting

Problem: the wp command is not found

Symptom: you type wp --info and the shell says it cannot find the command.

Likely cause: WP-CLI is not installed on your account, or it sits outside your shell's search path.

Fix: ask your host whether WP-CLI is available and where. If they give you a path to a wp-cli.phar file instead, run it with PHP, for example php wp-cli.phar --info from the folder that holds it.

Problem: "Error: Can't connect to the database"

Symptom: wp db query stops with this error.

Likely cause: the WP-CLI handbook lists wrong database credentials in wp-config.php, WP-CLI not using the MAMP PHP binary (a local development tool), or a multisite setup.

Fix: run wp --info to see which PHP binary it uses, then check you are in the right folder from Step 2. If your website itself also shows a connection error, that is a different problem from the version check, and it is time to talk to your host before anything else.

Problem: "Error: YIKES! It looks like you're running this as root."

Symptom: WP-CLI refuses to run and shows this message.

Likely cause: you logged in as the server's root user. The WP-CLI handbook strongly discourages this, because WordPress code would then run with full control of the server.

Fix: log out and log back in as your normal hosting account user, the one that owns the site files.

Problem: "PHP Fatal error: Allowed memory size of ... bytes exhausted"

Symptom: a WP-CLI command stops part way with a memory error. The handbook mentions this error mainly for wp package install, so it is rare with the commands in this guide.

Likely cause: PHP has a memory cap, set by memory_limit, and the command needs more than that.

Fix: raise the PHP memory limit for that one command only, which leaves your server settings alone. Ask your host what memory_limit value they allow. Rerun Step 5 to create a fresh private backup directory, replacing only its wp db export line with, for example, php -d memory_limit=256M "$(which wp)" db export "$backup_dir/db-before-upgrade.sql" --porcelain. Keep the && separators and surrounding permission-setting commands, including the final chmod 600.

Heads up: do not raise the limit server-wide just to fix one export, because that changes every PHP script on the account.

You should then see the file name printed, just like in Step 5.

Problem: the version line looks strange

Symptom: you see extra text such as -standard or -MariaDB after the number, or you are not sure whether you have MySQL or MariaDB.

Likely cause: servers add a suffix to the version string. The MySQL manual says the value "might have a suffix in addition to the version number".

Fix: read only the numbers before the first dash. A -MariaDB ending points to MariaDB. If you are unsure, put the full line in your message to the host and ask them to confirm.

Problem: the export file is 0 bytes

Symptom: ls -lh shows the file, but its size is 0.

Likely cause: the export stopped early, often because of the memory or connection errors above, or because your home folder is out of disk space.

Fix: delete the empty file, fix the error you saw, and run Step 5 again. Never treat a 0 byte file as a backup.

When to call in your host or a developer

Bring in your host for anything that changes the database server: upgrades, moves to another server, or changes to server settings. That is their equipment, and they can take a full server snapshot that you cannot.

Bring in a developer if your site has a lot of custom code or unusual plugins. The MySQL 8.4 upgrade notes list several changed defaults, for example innodb_adaptive_hash_index going from ON to OFF, innodb_change_buffering from all to none, and innodb_io_capacity from 200 to 10000. These rarely matter for a small blog, but a busy shop may notice speed changes.

The same MySQL page says that when upgrading to MySQL 8.4.4 or later, it is recommended to drop any spatial indexes beforehand and re-create them after the upgrade. A spatial index is a special index used for map and location data. If a developer built map features on your site, ask them whether any of your tables use one.

The one message worth forwarding

Copy this, fill in the parts in square brackets, and send it to your host's support team or your developer.

Hello,

I checked the database server version for my WordPress site example.com over SSH with WP-CLI:

wp db query 'SELECT VERSION();' --skip-column-names
Result: [paste the full line here]

The WordPress 7.1 hosting compatibility page recommends MySQL 8.4.x or MariaDB 10.11.x, 11.4.x or 11.8.x for new installs. It says MySQL 8.0 reached end of life on 30 April 2026 and MariaDB 10.6 reached end of life on 6 July 2026.

Could you please tell me:
1. Whether my account will move to a supported version, and roughly when.
2. Whether this means moving to a different server or a change of IP address.
3. Whether you will take a full backup before the change.
4. Whether you will give me notice before the change, so I can watch the site.

I have already taken my own export of the database with wp db export and kept a copy offline.

Thank you,
[your name]

The short version: one command tells you your database version, one more makes a safe copy, and one message gets you a real plan from the people who run the server.