- The RDBMS currently used for most of your existing projects
- Coding needs, such as the capability to execute scripts in specific ways
- Interoperability needs, especially when working with other organizations
- Automation needs, such as the capability to execute scripts in response to events or at a specific time
- Security concerns that may override other needs for data storage
- Data storage size or type requirements
- Management requirements
For developers, the overwhelming first priority in choosing an RDBMS is using the same database that the organization uses to ensure a smooth transition from the test to the production environment. An exception to this rule occurs when the organization plans to consolidate RDBMS products and is therefore moving to a new product to meet specific needs. Given that the number of RDBMS engines available today is huge, RDS is unlikely to ever support them all. As of this writing, RDS supports six database engines, each of which has characteristics in its favor, as explained in the following list:
- Amazon Aurora: This product is essentially a MySQL clone. If you like MySQL, you probably like Amazon Aurora as well. However, according to a number of sites, Amazon has managed to make Aurora faster, more scalable, and inclusive of a number of interesting additional features. Of course, you pay a higher price for Amazon Aurora as well, so if you don’t need the extra features, using MySQL is probably a better choice. The articles at 2ndWatch and Ivan Zoratti’s blog provide a more detailed comparison of Amazon Aurora to MySQL.
- MariaDB: This is another MySQL clone, but it also has a significant number of additional features. You need to consider a few major differences when choosing this product. For one thing, MariaDB is pure open source, which means that it uses a single license that is easier to manage than MySQL. However, because of the licensing, enterprise customers deal with equivalent open source implementations in MariaDB (such as thread pool), instead of the original MySQL implementations, which can result in compatibility issues. MariaDB is also currently locked at the MySQL 5.5 level, so you may not have access to the latest MySQL features needed to make your application work.
- MySQL: This product isn’t quite as old as some of the other RDBMS offerings that Amazon supports, but it does serve as the standard to which other products are judged. The problem with being the leader is that everyone takes pot shots at you and tries to unsettle your customers, which is precisely what is happening to MySQL. You can read about some of the pros and cons of choosing MySQL. The fact is that MySQL sets the standard, so it likely provides the most stable and reliable platform that you can choose when these issues are the main concern.
- Oracle: This product has been around for years, so it has a long history of providing great support and significant flexibility. What sets Oracle apart from a few other products, such as MySQL and SQL Server, is that Linux administrators and developers tend to prefer it. As with MySQL, Oracle is a standard setter that everyone likes to compare with other products, even when those comparisons aren’t a good match. Unlike other products in this list, viewing Oracle Cloud as a separate product from the enterprise setup is essential; the two products aren’t completely compatible and have differing feature sets. You can find some pros and cons of using Oracle Cloud.
- PostgreSQL: This is a combination product in that most people view it as an open source version of Oracle but also go to great lengths to compare it with MySQL. Developers like PostgreSQL because it provides a significant number of features that MySQL tends not to support. In addition, the transition for developers from Oracle or SQL Server is relatively easy because PostgreSQL tends to follow their lead. However, MySQL tends to provide better ease of use and is somewhat faster than PostgreSQL. You can find some interesting pros and cons about this product at Anchor and DigitalOcean.
- SQL Server: This product provides essential RDBMS functionality with a considerable number of add-ons. The important thing to remember about SQL Server is that Microsoft created it for Windows, and everything about this product reflects that beginning. In general, administrators find that working with SQL Server is relatively easy unless they need to use a broad range of those add-ons. Developers like SQL Server because it integrates well with the Microsoft language products. You can read pros and cons about this product at InfoWorld, The Register, and SQLServerF1.
Even with this short overview of the various choices, you can see the need to research your RDS choice completely before committing to a particular option. In some cases, you may need to configure a dummy setup and perform tests to see which option works best for your particular application. After you begin to fill the RDBMS with real-world data, moving to another database engine is usually an expensive, error-prone, and time-consuming task. The smart developer takes additional time to make a good choice at the outset, rather than discover that a particular choice is a mistake after the application moves into the development (or, worse yet, production) stages.