Every WordPress site keeps its content in a database. Your posts, pages, users, settings and comments all live there, so it is fair to ask which engine does that work. Many owners expect a choice between MySQL and PostgreSQL.<\/p>\n
The answer is short, but the reasons are worth knowing. WordPress was built for MySQL from day one, and that choice shapes your hosting, your backups and your upgrade path.<\/p>\n
WordPress uses MySQL. It does not use PostgreSQL. The install screen asks for a database name, a user, a password and a host, and those four values point to a MySQL database. Nothing else works in a standard install.<\/p>\n
This has been true since the first release in 2003. The core team picked MySQL because it was free, fast and available on almost every shared host. Today roughly four in ten websites run WordPress, and every one of them sits on MySQL or a close relative of it.<\/p>\n
You can see the proof inside the software. WordPress ships with a class named So when a host says a site needs a database, they mean MySQL.<\/p>\n Here is where people get confused. You may open your hosting panel and see the word MariaDB, not MySQL. Nothing is broken. MariaDB is a fork of MySQL, built by some of the same engineers who wrote the original.<\/p>\n A fork means the code was copied at one point in time and then grown in its own direction. MariaDB kept the same command language, table types and connection protocol, so WordPress cannot tell the difference in daily use. Hosts like it because it is fully open source, has no paid tier, and follows a release schedule that is easy to plan around.<\/p>\n The one place the difference shows is version numbers. The two projects count releases separately, so MariaDB 10.11 is not older than MySQL 8.0. Check which of the two a hosting requirement refers to before you act on it. Moving a site between the two normally works with a plain export and import.<\/p>\n Version numbers matter more than most owners think. An old engine can block a WordPress update, slow your queries, or leave known security holes open, so it is worth checking once a year.<\/p>\n For 2026, aim for MySQL 8.0 or newer, or MariaDB 10.6 or newer. There is a catch with MySQL 8.0 this year. That branch reached the end of its support life in April 2026, so it no longer gets security patches.<\/p>\n The safe move is MySQL 8.4, a long term release backed until 2032. On the MariaDB side, 10.11 is supported into 2028 and 11.4 into 2029. Any of those three will carry your site for years.<\/p>\n Your PHP version needs to keep pace too. PHP 8.1 or higher is the sensible target. An old PHP build paired with a new database throws odd connection errors, so ask your host to move both together.<\/p>\n PostgreSQL is an excellent database. It handles complex joins well, it has strong data types, and large applications lean on it every day. None of that helps here, because WordPress was never written to speak its dialect. The block is not a licensing rule or a missing setting you can switch on. It sits in the code itself, in two separate places that both have to change before a Postgres install could work.<\/p>\n The first place is WordPress core, which builds every query in MySQL syntax. The second is the plugin ecosystem, where thousands of authors write raw queries in that same syntax. Fixing one without the other still leaves a broken site.<\/p>\n Every database call in WordPress goes through the Replacing that layer is not a small patch. You would rewrite the query builder, the table creation code and the upgrade scripts that run on every core release, then keep that rewrite in step with WordPress forever.<\/p>\n Even a perfect core port would solve only half the problem. Thousands of plugins run their own custom queries through the Some use functions that Postgres does not have or spells differently. Date handling, string joins and full text search are the usual trouble spots. One unsupported function throws a fatal error on the page that calls it, so you would end up testing every plugin you own, forever.<\/p>\n You do not have to guess, because WordPress will tell you and so will your host. Two quick checks cover every case, and neither one changes a single file or setting. Do both before any upgrade, migration or support ticket, since the engine name and version are the first things a technician will ask for.<\/p>\n The first check runs inside your admin area and takes under a minute. The second reads the connection details on the server, which helps when the dashboard will not load. Between them you get the engine, the version, the database name and the table prefix.<\/p>\n Log in to your admin area. Go to Tools<\/strong> then Site Health<\/strong>, then open the Info<\/strong> tab. Scroll down to the section named Database<\/strong> and click it to expand.<\/p>\n You will see rows for the extension in use, the server version and the client version. The server version is the line you want. It reads something like 8.4.0 for MySQL, or 10.11.6-MariaDB if your host runs the fork. The same panel shows your database name and table prefix.<\/p>\n The second check happens on the server. Open your site files over FTP or the file manager your host provides. In the root folder you will find Those values tell you which database your site connects to. Find the database name value in your hosting panel under the database section, where the panel prints the engine and version next to the name. Our guide to creating a WordPress database in phpMyAdmin<\/a> walks through the same screen.<\/p>\n Technically yes, and practically we advise against it for any site that earns money. Community projects have tried to sit between WordPress and Postgres for years. They catch each query, rewrite it into Postgres syntax, and pass it along. On a bare install this can look like it works.<\/p>\n The trouble starts when you add real plugins. Translation layers cover the common cases, not the odd ones, so a form plugin or a store plugin can fire a query the layer cannot rewrite. You then get a white screen with no clear error. No host will debug that site and no plugin author will accept the bug report. If speed is the goal, our notes on WordPress database performance<\/a> cover the safe wins first.<\/p>\n PostgreSQL is not the only engine people ask about. SQLite comes up often, and the story there is more hopeful. SQLite keeps the whole database in a single file on disk, with no separate server to run.<\/p>\n The WordPress performance team has built an official test module that lets core run on SQLite. It targets local development, small demos and low resource setups, and it is useful for a laptop install where a full database server feels heavy.<\/p>\n It is still an experiment. It is off by default, it is not advised for live traffic, and the same plugin query problem applies. SQLite also copes badly when many writers hit it at once, so a busy store will struggle.<\/p>\n The short version is this. MySQL and MariaDB are the two supported choices for a live site in 2026. SQLite is a fine sandbox, and Postgres remains a research project.<\/p>\n Since MySQL is what you have, the useful question is how to look after it. A neglected database slows every page load, and four habits keep it in good shape.<\/p>\n First, control post revisions. WordPress saves a full copy of a post every time you save a draft, and an old blog can carry tens of thousands. Add a revisions limit to Second, clear expired transients and spam comments monthly. These sit in the options and comments tables and add up quietly.<\/p>\n Third, watch autoloaded options. Any row in the options table with autoload set to yes is read on every page request. Once that total passes about one megabyte, the whole site slows. Removed plugins are the usual culprit.<\/p>\n Fourth, back up before you touch anything. Our walkthrough on backing up a WordPress database<\/a> shows the export options that matter, and our guide to the database connection error<\/a> gets you back online if a change goes wrong.<\/p>\n Two questions come up again and again on support tickets, and both have short answers that hide a longer story. Owners want to know whether a host move will quietly swap their engine, and whether that choice shows up in search results. Here is the reasoning behind each.<\/p>\n It might, and that is usually fine. Moving from a MySQL host to a MariaDB host, your export will import cleanly in almost every case. The table structures and data types match closely enough that WordPress never notices the swap.<\/p>\n The one thing to check is version direction. Moving from a newer engine to an older one can fail if your export uses a feature the older build lacks. Ask the new host for their version before you migrate, match or beat what you have, and run a test import on staging first.<\/p>\n Not directly. Search engines never see your database. They see the finished HTML your server sends. What they do notice is how long that page takes to arrive, and the database plays a real part in that.<\/p>\n A slow query adds time to every request, and so does a bloated options table or a missing index. Fixing those improves your Core Web Vitals, which feeds into rankings. The engine brand is not the lever. Server resources, caching and query quality are where the gains live.<\/p>\n Database work is the part of WordPress where a small mistake costs the most. A dropped table or a careless find and replace can take a site down in seconds, and the fix is rarely obvious under pressure.<\/p>\n That is exactly the kind of job worth handing over. Our team handles version upgrades, migrations between MySQL and MariaDB hosts, table cleanups and emergency recovery every day. We take a full backup first, test the change on staging, and only then touch the live site.<\/p>\n We also audit slow queries, trim autoloaded options and set up scheduled cleanups so the bloat does not return. You get a short report in plain language, so you know what changed and why it helps.<\/p>\nwpdb<\/code> that talks to your database through the PHP mysqli<\/code> extension. There is no second driver for Postgres in core, and none is planned.<\/p>\nWhat MariaDB Is and Why Your Host May Use It Instead<\/h2>\n
Which Database Versions WordPress Needs in 2026<\/h2>\n
Why WordPress Cannot Use PostgreSQL Out of the Box<\/h2>\n
The wpdb Layer Speaks MySQL<\/h3>\n
wpdb<\/code> class. That class is not a neutral translator. It builds queries in the MySQL flavour of SQL and sends them straight to a MySQL server. It also leans on MySQL behaviour, such as how the engine handles automatic ID columns and how it sorts text.<\/p>\nPlugins and Themes Write Raw MySQL Too<\/h3>\n
wpdb<\/code> results method. Those queries are written by hand, in MySQL syntax, by thousands of different authors.<\/p>\nHow to Check Which Database Your Site Uses Right Now<\/h2>\n
Check From the WordPress Dashboard<\/h3>\n
Check From wp-config.php and Your Host Panel<\/h3>\n
wp-config.php<\/code>, which defines the database name, user and host.<\/p>\nCan You Force It With a Translation Layer?<\/h2>\n
What About SQLite and Other Options?<\/h2>\n
How to Keep Your MySQL Database Fast and Healthy<\/h2>\n
wp-config.php<\/code> to cap them at five per post.<\/p>\nCommon Database Questions Site Owners Ask<\/h2>\n
Will Switching Hosts Change My Database Engine?<\/h3>\n
Does My Database Choice Affect SEO or Page Speed?<\/h3>\n
Getting Expert Help With Your WordPress Database<\/h2>\n