Sometimes it feels like you’re bound to hit MySQL eventually, regardless of where you dig on the Internet. It lies beneath the biggest sites, such as Lucent, Facebook, Drupal, WordPress, Google, Joomla and countless other major frameworks, and it’s so huge it has its own letter in the LAMP stack (Linux, Apache, MySQL, Perl or PHP or Python). From that standpoint, it comes as no surprise that this open source database has branched off into a series of specialized forks. The two most prominent are MariaDB and Percona.
This is a deeper look into how and why they come about, along with some advice on what to consider before diving into either fork Step one is nailing down a bit of a background on MySQL itself.
A Brief History of MySQL
In the early 1990’s, just as the World Wide Web was being introduced to the world, a network monitoring service named Minerva created an affordable, stripped-down version of SQL called MiniSQL or just mSQL. It wasn’t open source, but it was free for non-commercial use and sported a price tag in the hundreds for businesses. It appeared just as web standards were being cobbled together and mini-servers were taking off, so it became a backbone of the emerging web infrastructure.
A few years later, Allan Larsson, David Axmark and Michael “Monty” Widenius adapted mSQL into a more robust interface they named MySQL. The legend says it was named after Widenius’ daughter My.
When Sun bought MySQL in 2008, the development community became suspicious of the new owners and the forks began in earnest.
The Evolution of MariaDB
Widenius and Axmark left MySQL shortly after the buy out, and Widenius made very public criticisms of Sun and Oracle as acting contrary to the spirit of open source. Along with 20 of MySQL’s former top developers, he began a “Save MySQL” campaign.
Oracle bought Sun shortly afterward. For Widenius, that moment marked the birth of MariaDB (maintaining the theme by naming the product after another one of his daughters Maria), an open source alternative to MySQL that would be developed in concert with the community; it was meant to stay free perpetually under the GNU license.
The team was able to secure WikiMedia to make the switch to MariaDB in support of open source. As a result, MariaDB had added 10 million users by the end that year. To make switching easier for organizations of all sizes, MariaDB has been built to be a simple “drop-in” replacement for MySQL, coordinated to match MySQL’s APIs. For storage, it replaced the InnoDB engine with Aria and Percona’s XtraDB.
Percona Enters the Scene
Peter Zaitsev and Vadim Tkachenko introduced the open source Percona in 2006. The two had spent a great deal of time supporting MySQL and saw what the businesses really wanted from MySQL; they incorporated those aspects and made it more affordable, which is why some people consider Percona more of a branch of MySQL than a full fork like MariaDB.
Percona is perhaps best known for taking the InnoDB and retooling it into XtraDB, which lies at the root of Percona’s major code enhancements. In other aspects, Percona hews closer to the developments in MySQL than MariaDB, since its concerns are related to improving server performance. For example, Percona pulls in scalability, availability, security and backup features from the Enterprise version of MySQL.
A Few of the Other Forks
- Drizzle: This open source fork originates from the abandoned MySQL 6.0, and is intended for the web infrastructure and cloud community. The main idea is that it uses a microkernel architecture, using plugins like query cache and authentication.
- OurDelta: This fork was designed to enhance feedback cycles and bring MySQL code up to date with innovation on the web. OurDelta made it easier to test in more environments, although it no longer exists as a separate project as these enhancements were folded back into the MariaDB 5.1 release.
- WebScaleSQL: This is another fork that some consider a branch of MySQL 5.6. It was built in 2014 in association with developers from Facebook, Google, LinkedIn and Twitter, and it was made to deal with some of the most common problems with massively replicated databases operating on server farms. WebScaleSQL’s goal was for the deduplication of efforts built independently by social media companies, and it is now saved on GitHub under the GNU license.
Percona or MariaDB: Which Is Better?
Of course, there’s no easy answer to that question. MariaDB (v. 10.1) and Percona Server (v. 5.6) are both production ready, and both can be dropped in fairly easily as a replacement to MySQL v. 5.7, which is the latest production-ready release.
Many companies won’t see a difference in performance unless there are specific capabilities they need or bottlenecks they want to overcome. Here are some reasons, other than the fact both are open source, why you might consider one over the other.
Five Reasons to Consider MariaDB
In addition to WikiMedia, companies supporting MariaDB include most Linux offshoots like Red Hat and SUSE; in 2013, Google announced it was joining those companies in moving its largest servers to MariaDB. Look at MariaDB if you:
- Want to take advantage of an active international community of developers, not just those from Oracle.
- Need to stay up to date with the latest developments in technology.
- Have stakeholders that require immediate security patches.
- Want to get started on upgrade features before they are released in MySQL.
- Expect alternate storage engines to be built into the code, such as Connect and Cassandra for NoSQL backends, Spider with built-in sharding or Percona’s TokuDB to deal with fractal indexes.
Five Reasons to Consider Percona
Percona estimates there are around 2 million installations, even at companies like Acquia, HP, Flickr, Etsy, Opera and Tumblr. Look at Percona if you:
- Want queries to come back with results faster. Percona have released several benchmarks favourably comparing their XtraDB storage engine against InnoDB in vanilla MySQL.
- Need to see better consistency in running a variety of very powerful servers.
- Have plenty of I/O and large working sets that should be handled with no sharding.
- Want to reduce maintenance time. Percona includes enhanced utilities for online backup and table import/export.
- Tunability. Percona includes additional instrumentation within the MySQL internals to help with monitoring and tuning.
Concerns Before Switching
Your main concerns in making this type of commitment should be operational. Make a list of what information you’ll need to gather, beginning with:
- Possible migration paths.
- Key configuration tuning variables.
- How to reload tables, if that becomes necessary.
- Whether you need to reconfigure a stand-alone InnoDB server or use something like Percona’s XtraDB.
- Any documentation on how your applications integrate with the new cluster.
- What will be necessary to avoid downtime in the migration.
- How the change can be accomplished gradually.
The MariaDB site notes three points to consider before you upgrade:
- Views with definition ALGORITHM=MERGE or ALGORITHM=TEMPTABLE were accidentally swapped between MariaDB and MySQL. You will have to re-create views created with either of these definitions.
- MariaDB has LGPL versions of the C connector and Java Client. If you are shipping an application that supports MariaDB or MySQL, you should consider using these.
- Consider trying out the TokuDB storage engine or some of the other new storage engines that MariaDB provides.
You’ll find there are many considerations before installing Percona, based on the source of the code and whether you are installing over a recent version of MySQL or MariaDB. Note that Percona offers repositories for yum (RPM packages for Red Hat, CentOS and Amazon Linux AMI) as well as for apt (.deb packages for Ubuntu and Debian).
Remember that MariaDB was developed to add more features and to optimize queries; it offers scalability features including multi-source replication, allowing a single server to replicate from several sources. Be careful about planning out any complex replication schemas that bridge MySQL with other implementations. You will be able to replicate from MySQL v. 5.6 to MariaDB v.10, but not the other way around.
Percona has devoted more of its resources to improving the database and how it manages network interactions. Users come to Percona looking for enhanced availability in addition to high throughput and scale. As Percona stays closer to current MySQL releases, it’s a more conservative option in terms of application compatibility; IT professionals looking for detailed diagnostics and performance metrics tend to prefer Percona.
For the TL,DR summary: MariaDB is better for advanced features, the latest security and adapting to new tech. Percona excels at database performance and diagnostics. Either one will put you in good company with cutting edge technology firms around the world.