Is the future of MySQL PostgreSQL (Or MariaDB, or TiDB, or ...)?

 I am not intentionally trying to upset anyone with this blog post or minimize the efforts of many brilliant people whom I admire. However, I connected with several people over the 2025 holidays who all had the same question: What is the future of MySQL? At the upcoming FOSDEM conference, several events will discuss this subject and push a particular solution.  And in several ways, they are all wrong.

Oracle has not been improving the community edition for a long time now. They have laid off many of their top performers in the MySQL group. We got almost a good decade and a half out of Oracle's stewardship of the "world's most popular database", and we should be thankful for that. However, now that time is over, it is time to consider future options that will involve no updates, CVEs, or innovation for what is the MySQL Community Edition.

There are several choices available.

Nothing!

The first choice is nothing. Many folks run old, end-of-life versions of MySQL. There are many instances of MySQL 5.7. There are some fantastic features in later versions of the software. But if those features are not needed or desired, then why upgrade? MySQL has always had a minimalist appeal for those who have little need for features like JSON, material views, and the like. This vanilla approach will be the default for many who do not change it if it is still working in the school of software management. 

Pros: You do not have to make any changes.
Cons: You are taking on technical debt like the Titanic took on water. You may get a few years out of this, but this path is fraught with hungry dragons.

The Elephant

PostgreSQL? This is a great database, offering numerous valuable features and making it a solid choice. It is reasonably easy to port schemas and data from MySQL to PostgreSQL. You will want to run a connection pooler. You will need to keep an eye on the vacuum status. You will need to learn to pick from an embarrassing number of indexing options, with B+ tree probably still being your primary choice.  A significant benefit is that PostgreSQL becomes a little faster each year. This is a sound choice for the future. But this is a big change, and a bridge too far for many.

Why? To a long-time MySQL user, PostgreSQL is much more complex to set up. It is more than capable, with its Swiss-knife-like set of options and extensions. The replication setup seems like putting together tinker toys. And if you do not know how to monitor for transaction ID wrap-around, it can bite you. MySQL has been set-and-forget operationally, whereas PostgreSQL needs more attention. 

Pros: This is the way to go for a robust, really open-source database. This is my recommendation most of the time.
Cons: Some of the long-term issues seem archaic, and you have to pay attention to its operation. 

What about the forks and/or branches? 

MariaDB

MariaDB forked from MySQL fifteen years ago. In many cases, it is an easy port from MySQL to MariaDB. That is, unless you make heavy use of JSON or MySQL Cluster. MariaDB recently acquired Galera Cluster, a similar replication concept to MySQL Cluster, but not interchangeable.  MariaDB had been hiring some of the top talent (Joro, Jeb, et al) that Oracle MySQL let slip away. MariaDB shares a lot of DNA with MySQL, but it has since diverged from MySQL. This is a 'may be close enough' option for some.

Pros: This is probably the second easiest port. Has some cool features not in Community MySQL.
Cons: MariaDB has some clunky parts, like its JSON implementation, which may not affect you. And many have been turned off by the soap opera foundation, corporation, crippled stock IPO, SkySQL dramas of the last few years.

Percona

Percona has been enhancing upstream Oracle MySQL for years, and the majority of its revenue was from MySQL. It has some clever features that Oracle should have added years ago. It is rock solid and as close to Oracle's product as possible. But if the upstream dries up, what happens downstream? And with Galera being purchased by MariaDB, will the Percona fork users be forced to move to the seal? Percona has also had employee turnover that could impact its branch. 

Pros: As close as you can get to mainstream Oracle MySQL as possible.
Cons: Can Percona carry the torch for MySQLdom if or when Oracle walks away? Doubtful at this time.

Oracle

Well,  you could actually pay for Enterprise Oracle MySQL. One of Percona's founders has been quoted as saying that Oracle really does not have customers, only hostages. 

The last fifty years of computing history are full of folks who bet against Larry Ellison and lost. 

But having to pay for something that was once free rubs me and others the wrong way. 

Pros: The change from the community edition to the enterprise edition is easy.
Cons: That change is usually felt as a sharp pinching feeling in the wallet. Oracle audits.

Cloud

The past decade has been great for those who wanted to get out of running their own databases and pay for someone else to run them. They take on the responsibility, and you get to pick which product you want. And at a certain level, a relational database from A is like the one from B. Add in an ORM or two, and the database is abstracted to absurdum. 

You can surrender all and let the cloud do the work. It used to be that DBAs fought hard for a 'golden truth of data' in which there was one copy of the data, with no redundancies, and that information was 100% correct. Then we replicated to read-only servers to take the load off the central read-write instance. Then the data was exported into NoSQL, eventually consistent, dunked in lakes, time-sliced, and sharded so that the one golden truth was gone. I see many big projects today trying to align slight variations in data to achieve a higher degree of confidence, and I know they are going to fail.

So you could just move everything to the cloud and let your cloud vendor worry about the icky backend stuff, just like you offloaded your RAID worries. 

Pros: The database issue is now someone else's issue.
Cons: Expensive, and you put a high level of trust in someone else doing everything right. 

Other MySQL Compatible Options

Yes, there are MySQL-compatible options. My fav is TiDB. But compatible is not precisely the same as MySQL. They work well and often do things better than MySQL.  But if you need to fire up a quick instance for a proof of concept or your kids' sports league, they are overkill.  At the bigger end of the continuum, they may be precisely what you need. 

Pros: Compatible at a certain level with what you are used to with MySQL.
Cons: May not be exactly what you need, and may not be compatible enough.

Conclusion

Time and the marketplace will pick winners. They may not be from the list above, as some new hero will ride in on their unicorn with a new database that solves all our problems. But do not hold your breath.

My prediction: A mix of the above will take over where Oracle is surrendering MySQL Community Edition's market share. The two predominant options will be a continued shift to PostgreSQL or a non-shift, keeping the version of the Community Edition currently running. The first is for those who strive for the best technological solution, with an eye on future improvements, which the PostgreSQL contributors routinely deliver. The second is for those from the school of thought that has found you do not mess with what is running well. 

Most of you will go with PostgreSQL. It is a solid technical choice, is getting better each year thanks to an amazing, dedicated team, and will do more than you need.

But I will still miss the spirit of MySQL AB, where I joined in 2007, where the feeling was that anything was possible. Almost two decades later, the current status is a sad way for such a dynamic project to limp to a halt.

Comments

Post a Comment

Popular posts from this blog

How PostgreSQL's Aggregate FILTER Will Spoil You

Using PostgreSQL will definitely spoil you. I recently had to use another database and found, to my chagrin, that aggregate filters were not included in their implementation of Structured Query Language. Specifically, there was no FILTER clause available. FILTER? To illustrate my dependency, let me start with some simple data. demo=# create table z (a int, b int, c int); CREATE TABLE demo=# insert into z values (1,10,100),(2,20,200),(3,30,300),(4,40,400); INSERT 0 4 demo=# select a,b,c from z;  a | b  |  c   ---+----+-----  1 | 10 | 100  2 | 20 | 200  3 | 30 | 300  4 | 40 | 400 (4 rows) demo=#  If I wanted the overall number of rows, I could use a simple COUNT(*). If I wanted an overall number of rows where one of the columns was of a certain value, I could add the logic for getting those rows to the WHERE clause. What if I wanted both?  Do I need two queries to do the work separately? Maybe a materialized view or a CTE (Common Tabl...
Read more

Incremental Backups in PostgreSQL 17

 The old adage that a DBA or SRE is only as good as their last backup is true.  PostgreSQL 17 added the ability to combine multiple incremental backups with a full backup to provide a complete data dictionary to recover a failed system. It is very easy to use. This is a quick example of using incrementals. I recommend watching this video by Robert Haas for more details and some discussion of backup strategies. Step 1 - Enable WALL Summerization The incremental backups require Write Ahead Log Summarization. It is likely not on your instance by default. But it is easy to enable. demo=# alter system set summerize_wal = 'on'; ALTER SYSTEM demo=# select pg_reload_conf(); pg_reload_conf  ----------------  t (1 row) Step 2 - Full Backup The examples below are much simpler than you will run into in real life.  The scenario is that we make a full backup on Sunday and do incrementals the rest of the week. Wednesday through Saturday are omitted below.  stoker@ThinkPa...
Read more

Can Artificial Intelligence Created Better Tables Than You?

 Artificial Intelligence is one of those conundrums where the ability to have some tasks handled for you contrasts with a mix of ego and pride that it may be better than you at those tasks.  I recently wrote a blog using another database about an AI-generated SQL that was quite sophisticated . But what about asking an AI to create a table with a specification like a DBA/SRE/Analyst might receive? I used Grok and entered the following prompt: Write the SQL to create a table on a PostgreSQL version 17 server to record data on customers. The data will include a first name, a last name, an address, a birthdate, and a unique UUID primary key. Partition the data by the year of birth. And produce some test data of at least ten records. I am sure many of us have started large projects given less instruction.  Notice: I did not denote the format for the address (US Post Office's format, or UK, or other). Nor did I set a name length. I wanted to see what assumptions were made by t...
Read more