Why I keep choosing MariaDB

Users of open source software don’t always share their stories, simply because they are satisfied. That’s why we were delighted to accept an offer from database expert Richard Bensley to share why he has repeatedly used MariaDB over the years. 

I had a chat with Richard and learnt that he has seen MariaDB as a user, customer, and even an employee of MariaDB. Despite experimenting with other solutions, new and old, his passion for MariaDB and the people behind hasn’t faltered. 

Richard has been using MariaDB in large scale production since 2012 for financial platforms, CRMs and e-commerce for regional and international use. He told me about his experiences of database landscapes at countless clients and how MariaDB has always proven its worth as a strong, reliable, feature rich option, that is simple.

After a couple of general explanations I was cringing for anybody that has had to scale an app without choosing MariaDB from the start.

Richard thinks that since MariaDB 10 was released, it has proven itself to be more than just a fork, and the rate of innovation has yet to slow down. 

Here is in Richard Bensley’s own words why MariaDB is his tool of choice:  

Richard Bensley: Why I keep choosing MariaDB

I have been using MariaDB in production since the 10.0 release. With support for vectors on the way, I have even less reasons to use anything other than the most flexible, most cohesive RDBMS on the planet.

What do I mean when I say that? Let’s start with flexibility. Over the years I have demonstrated and optimised database workloads for a wide range of industries using a plethora of different hardware platforms. Everything from Raspberry Pi’s to big iron data centres, and globally available cloud solutions. And every time MariaDB fits the bill by providing easy access to tunable variables and flexible replication options.

And cohesive? A lot of people overlook the need to provide an appropriate data life cycle beyond their base requirements of an OLTP solution to handle their main applications. Growth is inevitable and being able to effectively scale OLAP services for data warehousing and reporting, read/write scaling, data compliance, archiving, onsite and offsite backups; it’s the same tools, same drivers, same protocols, same ecosystem.

Having a multitude of storage engines means servers can handle hybrid workloads on a per-table basis should you wish, or move them out to their own servers for more resources and a separation of concerns; again, same protocol, same tools. Those migrated tables can easily keep in touch within the same query using the CONNECT Engine, or even Spider if sharding is what you need.

Keep those reports and multi-billion row queries flying out the door using Columnstore on clustered local storage or anything that supports the S3 protocol, which you can also use for keeping table data in buckets. InnoDB and RocksDB are still as reliable as ever, even MyISAM got a significant leap in the form of Aria.

MariaDB doesn’t just have storage engines, it’s got features for every need:

• Need a cache? Create some tables using JSON data types or Dynamic Columns with the memory storage engine, or add regular tables to the dynamic replication filters.
• Need a queue? Combine SKIP LOCKED with your FOR UPDATE when selecting rows to enqueue and process.
• Need a multi-primary cluster or WAN replication? Use Galera.
• How about rolling back a table after an unfortunate update or delete? Use Flashback to replay the binary logs and reverse changes.
• Want to provide a multi-tenant database platform for your customers? Catalogs have you covered.

MariaDB in my opinion has always delivered above and beyond anyone’s expectations since their initial fork, and every new release is stronger than the last.

Richard Bensley is a Database Consultant and Developer at Vettabase Ltd.