MariaDB: story of a MySQL fork

MariaDB was born as a fork of MySQL that means they share the same code up to a certain point, that point was MySQL v5.1 (29 Sep 2009). The community decided to fork MySQL due to concernsabout the Oracle acquisition and what MySQL would become.

Oracle was mainly a software company and most of its core business was at the time, well, databasesOracle Database is the Oracle’s main product and it is often regarded as the standard database for the enterprise. With the acquisition of MySQL, the community feared that Oracle would limit the growth of what used to be a complete open source DBMS. The day Oracle announced the acquisition of Sun, Ulf Michael Widenius, the main author of MySQL, announced the fork of MySQL and the birth of MariaDB. The cofounder of MySQL took a handful of MySQl developers with him.

Oracle has since created derived products: MySQL Community Editions (the “original”, open source) and MySQL Standard, Enterprise editions that include closed source software and Oracle support.

A drop-in replacement

The main selling point of the newly born DBMS (Data Base Management System) was to keep compatibility with MySQL and to be a drop-in replacement for it.

Drop-in replacement means that a software using either won’t notice if you switch between the two and will continue working without any problem. This was done in order to provide users with an easy way to switch to the new software without disrupting their activities.

Maintaining MariaDB as a drop-in replacement was a right call to allow users to switch in the short period, but it would’ve been a double-edged sword in the long run: MariaDB would’ve had to implement every single change implemented by Oracle, and that would’ve defeated the original reason behind the fork. That’s why not all versions of MariaDB are compatible with MySQL (more in a while).

MariaDB, MySQL: storage engines

First and foremost MariaDB released Aria, a storage engine to replace the older, but still widely used, MyISAM. For a short while MariaDB used XtraDB (a storage engine from Percona) as default, to later return to InnoDB. It may not seem like a great feat now, but at the time MyISAM, the default MySQL storage engine, would employ table-wide locks that resulted in poor performance and query stacking.

In time MariaDB’s InnoDB, the current default engine, diverged substantially from MySQL’s InnoDB, leading to incompatibilities, up to the point that no version of MariaDB can be used as drop-in replacement for MySQL 8.

At the moment MariaDB supports the following engines:

  • InnoDB (since version MariaDB 10.3 it has diverged substantially from MySQL’s implementation)
  • XtraDB
  • Aria
  • MyISAM
  • ColumnStore
  • TokuDB
  • MyRocks
  • follow this link for a full list.

While MySQL supports:

  • InnoDB
  • MyISAM
  • Memory
  • CSV
  • Archive
  • Blackhole
  • NDB
  • Merge
  • Federated
  • Example

Notice that Memory, CSV, Archive, Blackhole, Merge, Federated, Example are also available in MariaDB.

The Big Blockchain Lie

Now that cryptocurrencies such as Bitcoin have plummeted from last year’s absurdly high valuations, the techno-utopian mystique of so-called distributed-ledger technologies should be next. The promise to cure the world’s ills through “decentralization” was just a ruse to separate retail investors from their hard-earned real money.

.. Faced with the public spectacle of a market bloodbath, boosters have fled to the last refuge of the crypto scoundrel: a defense of “blockchain,” the distributed-ledger software underpinning all cryptocurrencies. Blockchain has been heralded as a potential panacea for everything from poverty and famine to cancer. In fact, it is the most overhyped – and least useful – technology in human history.

In practice, blockchain is nothing more than a glorified spreadsheet. But it has also become the byword for a libertarian ideology that treats all governments, central banks, traditional financial institutions, and real-world currencies as evil concentrations of power that must be destroyed. Blockchain fundamentalists’ ideal world is one in which all economic activity and human interactions are subject to anarchist or libertarian decentralization. They would like the entirety of social and political life to end up on public ledgers that are supposedly “permissionless” (accessible to everyone) and “trustless” (not reliant on a credible intermediary such as a bank).

.. Yet far from ushering in a utopia, blockchain has given rise to a familiar form of economic hell. A few self-serving white men (there are hardly any women or minorities in the blockchain universe) pretending to be messiahs for the world’s impoverished, marginalized, and unbanked masses claim to have created billions of dollars of wealth out of nothing. But one need only consider the massive centralization of power among cryptocurrency “miners,” exchanges, developers, and wealth holders to see that blockchain is not about decentralization and democracy; it is about greed.

For example, a small group of companies – mostly located in such bastions of democracy as Russia, Georgia, and China – control between two-thirds and three-quarters of all crypto-mining activity, and all routinely jack up transaction costs to increase their fat profit margins. Apparently, blockchain fanatics would have us put our faith in an anonymous cartel subject to no rule of law, rather than trust central banks and regulated financial intermediaries.

A similar pattern has emerged in cryptocurrency trading. Fully 99% of all transactions occur on centralized exchanges that are hacked on a regular basis. And, unlike with real money, once your crypto wealth is hacked, it is gone forever.

.. Moreover, the centralization of crypto development – for example, fundamentalists have named Ethereum creator Vitalik Buterin a “benevolent dictator for life” – already has given lie to the claim that “code is law,” as if the software underpinning blockchain applications is immutable. The truth is that the developers have absolute power to act as judge and jury. When something goes wrong in one of their buggy “smart” pseudo-contracts and massive hacking occurs, they simply change the code and “fork” a failing coin into another one by arbitrary fiat, revealing the entire “trustless” enterprise to have been untrustworthy from the start.

.. Lastly, wealth in the crypto universe is even more concentrated than it is in North Korea. Whereas a Gini coefficient of 1.0 means that a single person controls 100% of a country’s income/wealth, North Korea scores 0.86, the rather unequal United States scores 0.41, and Bitcoin scores an astonishing 0.88.

As should be clear, the claim of “decentralization” is a myth propagated by the pseudo-billionaires who control this pseudo-industry. Now that the retail investors who were suckered into the crypto market have all lost their shirts, the snake-oil salesmen who remain are sitting on piles of fake wealth that will immediately disappear if they try to liquidate their “assets.”

.. Moreover, in cases where distributed-ledger technologies – so-called enterprise DLT – are actually being used, they have nothing to do with blockchain. They are private, centralized, and recorded on just a few controlled ledgers. They require permission for access, which is granted to qualified individuals. And, perhaps most important, they are based on trusted authorities that have established their credibility over time. All of which is to say, these are “blockchains” in name only.

Proprietary Postgres Forks: Keeping Code Forks Current is Hard

If we look at the dates listed in the Wiki, Greenplum is listed as starting in 2005. They’re not kidding, and unfortunately it seems Pivotal executed a “fork it and forget it” maneuver. The documentation admits Greenplum is based on Postgres 8.2, with elements of functionality from 8.3.

Like Amazon’s Redshift, this immediately disqualifies Greenplum from consideration for anyone using a newer version. Our own databases are on 9.4 pending an upgrade plan; there’s no way we could justify such a massive downgrade, even for horizontal scaling improvements. EnterpriseDB had a similar problem when they started selling their version of 8.3; they were far behind for years before they managed to reduce their version lag by only a few months. Greenplum never even bothered.

This may be an amazing product, but we can’t use it to replace existing Postgres 9.4 databases that need scaling. Will Greenplum catch up now that it’s been open-sourced? I can’t say. It would definitely be cool, but I’m not holding my breath. Incidentally, this is one of the reasons all of those projects on the Wiki have definitive end dates. Keeping up with Postgres after forking is extremely difficult if you don’t merge your enhancements back into core. It’s all too easy to fall hopelessly behind and become nothing but an academic concern.