in Development

Considerations Before Switching Servers


Changing databases is no trivial matter, but there are cases that call for it. Licensing, outdated databases, or drop in replacement are all factors to consider if your company is looking to make a switch. Keep in mind that not all databases can replace one another without having to change quite a bit of your code. The decision is based mainly on specific use cases, but let’s take a look at all the considerations for your team to make before switching:

Relational Databases (SQL) Vs. Non-Relational Databases (NoSQL)

A lot of people think that SQL is outdated, and the solution is to turn to non-relational databases. One of the main reasons is the need to handle large amounts of unstructured data. It really depends on what your specific needs are, and many companies actually use both types congruently. Here’s how the two differ:

Data Storage: SQL databases store data in a relational manner, meaning they use rows and columns. Rows store data entry info, and columns are separate data points. NoSQL databases have different data storing models. The main types are document, graph, key-value, and columnar.

Schemas: Records operate on a predefined schema, so each column has to be finalized before data entry and the rows depend on data from the columns. Making changes is tricky, often requiring that you go offline and make database-wide changes. This is one of the primary reasons people gravitate towards NoSQL; the lack of a schema model means that information can be easily added on the go.

Scalability: SQL uses vertical scaling, where more data requires a bigger server, and it therefore costly. NoSQL, on the other hand, operates with horizontal scaling across multiple servers, some even distribute across multiple servers automatically. The result is the ability to use multiple cheaper servers and cloud systems to keep costs down.

There’s no such thing as a one-system-fits-all approach when choosing between these two database models. It’s a matter of use case. If your data structure is working, and growth is average, you may not have any real need to make a change from the SQL status quo. NoSQL is great for product flexibility, because it allows quick pivots without major database rewrites. So, if your situation calls for a quick and efficient scaling in response to abrupt growth/change in data needs, NoSQL may be a better option.


MySQL & the Oracle Debacle

MySQL’s semi-recent sale to Oracle prompted many people to look for alternatives. The drop-in replacement for MySQL resulted from Oracle’s removal of MySQL’s GPL license, which worried users about the future. What has been happening is a large migration to MariaDB, which is also in the MySQL ecosystem. Let’s take a look at some of the changes with MySQL and why users are leaving Oracle-owned MySQL for MariaDB:

Whereas the original MySQL was free and open, Oracle announced that new enterprise extensions would be closed source. It is now Open Core, which is not the same as open source. This model is much more limited, the changes are as follows:

  • You depend on one vendor
  • You cannot do bug fixes independently or contact someone about bugs
  • You are limited to the original vendor’s platform, and subject to their price changes
  • Products are no longer checked by an open source community
  • Oracle’s code quality varies, and most of the time has to be rewritten before including it in MariaDB
  • It’s very difficult for users to get in contact with Oracle’s MySQL developers

As we mentioned before, most teams choose to gravitate from MySQL to MariaDB because it’s in the same ecosystem, and is a relatively easy process to make a switch.

MariaDB is open source, so anyone in the community can participate in development. Simlarly to MySQL, MariaDB is GPL, but it also contains LGPL drivers for C and Java. Usually, the use of these drivers means you don’t need to buy licenses for MySQL/MariaDB.

In comparison to most switching of databases, the jump from MySQL to MariaDB is relatively trivial. Simply uninstall MySQL and install MariaDB in its place — all development tools and connections should work without having to restore data. Format and file names are identical, so it’s just a binary drop.

There are a few inconsistencies between MySQL and MariaDB as a result of updates, etc. Find specific instances here.

Most of the reasons for switching from one database to another runs on a case by case basis. There’s surely no one-size-fits-all when it comes to databases. Unless there is a strong reason to make the switch, it’s usually not a priority for companies. While MySQL and MariaDB seem to be the easiest shift because they are in the same ecosystem, the considerations from MySQL to NoSQL is quite another story.

Some situations beckon change, but switching databases can be costly and time consuming, and should warrant strong reasons for doing so.