Inspired by this comment in the Hacker News discussion, I posted polls on my LinkedIn network about the tendency (or perception of tendency) to abandon features without deprecating them in some of the most popular open source databases – MySQL, MariaDB, and PostgreSQL.
First, let’s look at why “Abandoning” features rather than formally depreciating them is even the problem. If you’re an experienced member of the community you know the features which are actively improved and which have not been getting any attention, despite bugs being reported. You know to stay away from those. As a new member of the community or just a casual user, you do not know that… and you may start to rely on features that are unstable or half-baked, getting into trouble. Clearly marking such features as depreciated if they have no plans to be developed in the future or as “Experimental” if you plan to improve them, but maybe later is what you should do for the benefit of the community.
Too often, though, Sales/Marketing reasons may intervene here, as it might be hard to “sell” something if you’re simultaneously saying it is not stable enough to rely on. This is short-term thinking, though, as tricking someone into using half-baked features breaks trust and will have serious negative long-term consequences.
Let’s look at the poll results.
More than half of respondents see such a tendency in MySQL. Not a good thing. Some folks commented to me about “Evil Oracle” causing trouble here. I do not agree – a culture of half-baked and abandoned features existed in MySQL since the early days. If anything, I think Oracle cleaned up a lot of technical debt that existed
Jonah H. Harris commented that chasing customers (a commercial approach to development) may contribute to such a state of things. I agree – I remember, especially during the early days of MySQL, there was a lot of push to build “checkbox features” so Sales could sell. For example, Subqueries were initially implemented with basically no optimizer, things were so bad at some point Google hacked the code to disable subqueries support on the parser level, so their developers could not accidentally use them and end up with unfixable bad queries.
This was not the only reason, though—there was a lot of culture experimenting in production. For example, a number of storage engines were created as “proof of concept” and quickly pushed into the server as “generally available” features—BLACKHOLE, ARCHIVE, and FEDERATED engines would be examples.
I was surprised to see how close MySQL and MariaDB results ended up being. I expected the MariaDB community to be much more positive about the project.
Because MariaDB started off from the MySQL codebase, it inherited a lot of technical debt, which was there to clean up.
I think, despite the existence of the “MariaDB Foundation,” MariaDB is still vulnerable to the “chasing the customers” issue; a very large portion of the development is actually done by MariaDB Corporation, and I wonder if there ever were cases when the Foundation would refuse to include some code authored by MariaDB Corporation, as maintainers believe it is not in the best interest of the project.
As you can see, the PostgreSQL situation is basically the reverse, with the majority thinking it does not have such a tendency. I think there are a number of reasons for this.
First, PostgreSQL has a much better extension system, and as such, many innovations originate as extensions first. If you look at extensions, there is a lot of abandonware – Github is littered with those, yet when it comes to the official PostgreSQL Server, it is much less so.
Second, I think the PostgreSQL Core team is much more conservative, for better and for worse, and look for high quality broadly useful features. I am not sure EDB’s $10M/year customer really wanting something would be reason enough to include it in PostgreSQL. From what I understand, there have been a lot of features that various respected PostgreSQL developers/companies attempted to get included in PostgreSQL but did not manage to do so.
Of course, this also means there are a lot of PostgreSQL Derived Databases (forks) where such customer-specific innovations may exist.
Third, I think the PostgreSQL community loves PostgreSQL, often to the fault, so there is likely a “halo” component to it as well.
Of course, this is just one small, non-scientific, and likely very biased set of polls, but I think it gives us a good insight into what is going on among the MySQL, PostgreSQL, and MariaDB communities. Congrats to PostgreSQL, and I think MySQL and MariaDB have some work cut out for them if they want to build a reputation of stable, abandonware-free databases.
About the Author
Peter ZaitsevPeter managed the High Performance Group within MySQL until 2006, when he founded Percona. Peter has a Master's Degree in Computer Science and is an expert in database kernels, computer hardware, and application scaling.
That was me. Fortunately there wasn’t much demand and eventually MySQL got better at dealing with subqueries.
“things were so bad at some point Google hacked the code to disable subqueries support on the parser level,”