MariaDB is a community-developed, commercially supported fork of MySQL that is intended to remain free and open-source software under the GNU General Public License (the same license that MySQL started under). As just mentioned, it was forked because of MySQL’s acquisition by Oracle where many of the initial MySQL developers were afraid that because of how MySQL competed against the Oracle database, progress would be slowed or stopped on MySQL. MariaDB's API and protocol are compatible with those used by MySQL, plus some features to support native non-blocking
operations and progress reporting. This means that all connectors, libraries, and applications which work with MySQL should also work on MariaDB. However, for recent MySQL features, MariaDB either has no equivalent yet, such as geography, or deliberately chose not to be 100% compatible. This list of incompatibilities will likely continue to grow with each version.

MariaDB and .NET

Using .NET with MariaDB is easy to configure because of how similar the APIs are for MariaDB and for MySQL. To be honest, they are so identical that the easiest way to consume MariaDB in a .NET application is to use the same MySQL NuGet package and connection approach that we went over in the MySQL section. The MariaDB team does not really spend any time building connectors, and instead works to ensure that the connectors that are out there, such as those built by the MySQL team, are compatible.

Setting up a MariaDB Database on Amazon RDS

Now that we know how to setup our .NET application to access MariaDB, let’s go look at setting up MariaDB in Amazon RDS. Log into the console, go to RDS, select Create database. On the Create Database screen, select Standard create and then MariaDB. You will have a list of versions, starting with version 10.2 at the time of this writing up through the most recent release.

The rest of the set-up screen, surprisingly enough, will look eerily familiar if you just went through the MySQL setup steps; mainly because they are identical! You will have the same three options for the Template that you would like to use (Production, Dev/Test, and Free tier) as well as all of the configuration sections that follow.

Since we took the Free tier route with MySQL, let’s mix it up a little bit and go with the Dev/Test version for MariaDB and we can talk about some of the areas that we glossed over when creating the MySQL database.

The first of these is after you create the database instance identifier and have provided the master user information and is entitled DB instance class. There are three options available for instances:

• Standard classes (includes m classes) – provide a balance of compute, memory, and network resources and is the best all-around choice for many different database workloads.
• Memory-optimized classes (includes r and x classes) – have large memory allocations to support those database workloads that process large data sets in memory.
• Burstable classes (includes t classes) – are the only option available for the free tier and are designed to provide a baseline CPU performance with the ability to burst above this baseline as needed.

Selecting one of these options changes the instances that are available in the instance drop-down from which you make your selection. Selecting the standard classes as shown in Figure 1 will present a drop-down of the m-class instances.

Figure 1. DB Instance class selection for MariaDB (and MySQL)

Selecting one of the other options will filter the list in the drop-down to the applicable classes.

Caution: The lowest m instance class, db.m5.large, with 2vCPUs, 8 GB RAM, and 4,750 Mbps network connectivity will run you $124.83 a month in US East 2, so even a momentary creation has the chance to cost you! The t instance classes are the ones that include the free tier versions.

The next section in the setup is the storage section, with the same options that you had when going through the MySQL steps, though the default values may be different based upon the instance class that you selected. After the storage section is the second “greyed out” area that we saw when we walked through setting up MySQL, Availability & durability.

One of the best features of RDS is how it makes the installation and configuration of a new RDBMS painless when you think about what you would have to do to manage the configuration and maintenance of a standby instance on your own. For those instances where your data needs to be as available as possible, the ability to create (and forget about) a standby instance by checking a radio button can’t be overlooked. Creating a replica will configure a synchronous standby replica in a different Availability Zone than the primary DB instance. In the case of a planned or unplanned outage of the main instance, RDS will automatically failover to the standby. When using a multi-AZ deployment, however, you will be paying approximately twice as much for the duplicated instances as shown in Figure 2.

Figure 2. Estimated monthly costs with standby enabled

Once you have selected the appropriate availability option, in this case we chose to enable a standby instance, the rest of your experience will be the same as it was for MySQL, setting up Database authentication and Additional configuration. You can keep the defaults in these sections and go ahead and create your database or change the values as desired to get a better understanding of each area.

With identical pricing between MySQL and MariaDB, and similar APIs and other interactions, you may be wondering what the differences are between the two.

Selecting between MySQL and MariaDB

Our recommendation when you are trying to select between MySQL and MariaDB? All other things being equal, go with MariaDB. Why? Primarily because of the advanced capability that MariaDB offers such as its optimization for performance and its ability to work with large data sets. MariaDB has also spent a lot of effort adding query optimizations for queries that use joins, sub-queries, or derived tables; so, its overall performance is better than you will find with MySQL. Lastly, MariaDB provides better monitoring through the introduction of micro-second precision and extended user statistics.

However, there are occasions when MySQL makes more sense than does MariaDB, generally, when you are using some of the features available in MySQL that are not available in MariaDB, such as geographical processing, JSON stored as binary objects rather than text, or MySQL authentication features such as the ability to authenticate to the database via roles or the ability for a user to activate multiple roles at the same time.

The key is that both are available, and both provide support for .NET development. However, you do not have to limit your choices to just MariaDB or MySQL, as there is another open-source database that is supported in Amazon RDS that is worth a review. And that'll be the next post!