A relational database was, for a long time, quite a standard solution to various (and almost all) software use cases that large or small companies had to solve.
Today the variability is much higher with the broader availability of NoSQL, in-memory, or data lake databases. But despite that, whenever the decision is made to migrate current on-premise databases into the cloud, the relational database as a target is still the most straightforward option for this transition.
We will take a closer look at the following databases that can be a part of such an initiative:
- Oracle
- Aurora
- Microsoft SQL Server
- MySQL & PostgreSQL
- MariaDB
I will be clear on how they differ from the rest and what sets them apart, including their disadvantages. Then I’ll bring them into context by demonstrating on typical real-world usage example. Lastly, I’ll share my view on deciding between the different databases for your case.
AWS Oracle DB
The Oracle DB was undoubtedly the most widely used commercial database in the last few decades. Whenever a company needed a robust and high-performing database solution, Oracle DB was the first choice. And for many good reasons.
How It Differs
Oracle is a robust and functionality-rich platform that can serve an enormous amount of even totally different setups and requirements. Over time, this DB became the ultimate go-to solution in case you require state-of-the-art reliability, scalability, and maintainability living on the on-premise hardware infrastructure.
Main Advantages
Here are some of the main advantages you get when choosing such a mature database system as Oracle:
✅ Great support and options for effective backup and restore activities.
✅ Wide area of possibilities for how to tune the performance of the DB solution inside the system. Even long after, the solution is already in production. Support and maintenance activities inside this platform are really easy to set up, and they are very effective.
✅ High customization of the DB solution. Since Oracle DB supports an extensive amount of functionalities to choose from, you as a system integrator have plenty of options to build a robust system consisting of exactly those functionalities that your platform needs (think triggers, partitions, subpartitions, automated primary keys sequences, views, snapshots, data constraints, unique keys, combined keys, foreign keys, composite indexes, etc.). It supports everything.
✅ Easy administration of database activities and processes. Dedicated administration consoles and dashboards, and many tools created by Oracle and dedicated solely to administrators to use out of the box.
✅ Support of multi-user environments. If the requirement is to support thousands of distinct active users at the same time, Oracle is the answer.
Main Disadvantages
Oracle DB is very flexible regarding vertical scaling of the performance. But less so when you need strong horizontal scaling. That means it is easy to upgrade to a stronger CPU, more memory, and storage space on a cluster DB.
But if your data grows significantly in a short time – which is the usual case that happens with data in the cloud, the performance bottlenecks will become more visible and harder to solve. Spreading the data across multiple clusters and expecting them to grow dynamically will become a main requirement going forward. In this case, you might find Oracle DB starting to be more limiting than fulfilling your future needs.
Another possible disadvantage might be the cost. Oracle DB supports many features, but many of them also come at a cost. Even more so if several clusters are in place and physical performance upgrades are necessary. That means software tuning of the data model is not sufficient anymore. For more administrative tools and features to be available, you will need to purchase an enterprise license. This will further increase the already high costs.
Lastly, Oracle DB is not a native AWS DB service, which means you shall not expect full support from AWS. Rather orient to Oracle support. But then deal with Oracle and AWS pain points in parallel and with two different sets of support teams.
When to Choose
Choosing the cloud counterpart of the Oracle DB is the most natural decision to take whenever your current on-premise solution is already using Oracle DB. It will also make the migration and switch to the cloud-based solution as easy as it gets.
Therefore, choose the AWS Oracle DB in the case:
- You expect the cloud DB will support the same processes and functionalities as the on-premise variant for the foreseeable future.
- You don’t plan to integrate the DB with too many AWS native services very quickly.
- You don’t expect the current data volume will grow significantly in a short period of time.
- You require the support of a huge amount of functionalities in place. That is, it would be difficult to lose some of them currently in place when switching to the cloud.
- Your system must support hundreds of active users at the same time (or more).
Example of Use
- Large telecommunication systems for billing, CRM, and middleware data.
- Custom DB implementations for automotive database systems, integrated with several different custom or third-party vendor tools.
- Packaged systems solutions for the banking industry, where Oracle is already a fixed part of the packaged solution from the vendors and eventually integrates additional custom DB components into one complex implementation.
AWS Aurora DB
In many ways, Aurora is the direct opposite of Oracle, even if it is still a relational database.
How It Differs
Autora DB is a native database service in AWS. AWS gives it full support and ongoing development and deeply integrates it with the rest of the AWS services ecosystem.
Aurora DB does not reach that level of functionality diversification as Oracle already has. But it was born in the cloud (unlike Oracle). Since AWS further develops Aurora, the functionality gap might eventually be smaller in the future than it is today.
In many ways, Aurora is already ahead of Oracle, especially regarding integration with other AWS cloud services. And since Amazon created Aurora with a cloud ecosystem in mind, Aurora is ready for massive data income and increase over time, so horizontal scaling is a strong property.
Main Advantages
I would say the main advantages of Aurora DB are:
✅ Very flexible expansibility of read-only DB copy instances. Those you can create just in seconds. Read-only instances share the same DB logs of the main database from which they originate. That means creating a new read-only database does not require synchronizing all the data; it does automatically by sharing the existing ones.
✅ Large data growth ready – horizontal scaling is a big feature of Aurora DB. Adding new clusters and expanding the scalability across different availability zones is as simple as it gets. Aurora is then very effective in selecting large amounts of data very fast.
✅ You can choose whether to use the server or serverless mode of Aurora DB. Some of the features will be missing in serverless mode. But you get a lot of flexibility and cost optimizations when choosing serverless mode.
✅ Automated backups and easy point-in-time revert. Another highlight is that Aurora DB can do easy daily backups, and restoring the full database to any point in time is much simpler. You can combine all the advantages of the cloud environment here, as always available free space, fast inner-AWS operations, and a dedicated Aurora DB feature that targets fast recovery times and short downtime.
✅ Support for either MySQL or PostgreSQL DB engine, so you can pick whichever suits you.
Main Disadvantages
- Even though Aurora is arguably the most feature-rich native relational database you can choose in AWS, it is still lagging behind Oracle in this regard. It’s understandable; Oracle had much more time to develop those features in the past. The fact remains that Aurora DB is, with each release, stronger and closer.
- There is no equivalent to Aurora DB in the on-premise space. You can argue that old databases built inside MySQL or PostgreSQL databases are a close match – and from a compatibility perspective, they surely are. But they are not the strict equivalent. That means the migration will not be so straightforward. You will need to customize and implement migration processes to ensure they will transfer data from on-premise and store it into Aurora DB, all in the correct data model format.
- Various AWS limits, especially those hard ones, are a factor that might, in some cases, detract from choosing this DB as a target to go forward. It is very likely you will be able to work around them all, but for some, you will need some more serious investment into refactoring, which ultimately can increase the overall costs of migration in comparison to another database target.
When to Choose
In a nutshell, choosing Aurora DB as the goto relational database in the AWS platform is never a bad decision, but do so, especially if:
- You will build a cloud system from scratch around a relational database.
- You expect the highest level of compatibility and integrality with as much as possible different native AWS services.
- You expect your data volume will grow significantly over a short time.
- You plan to start several spin-off proofs of concept (POC) projects where you can leverage all the advantages of the serverless version of a relational database.
Example of Use
- A serverless platform for analyzing large amounts of infrastructure picture data.
- Utilization of machine learning models to process your data lake information and generate business predictions for your business.
- Netflix uses Aurora DB for fast parallel query executions over their catalog data.
AWS Microsoft SQL DB
This database is, in some ways, comparable with Oracle. It was also created a long time before the cloud became a thing, and there are a lot of current on-premise users that are planning to migrate to the cloud, using the MS SQL DB as the source.
How It Differs
Despite those similarities, MS SQL DB is still the one that had much less use in the past in comparison to Oracle DB.
At least judging from my personal experience perspective. I was involved in multiple Oracle projects over the last two decades, but only in a handful of cases where MS SQL DB was involved. And frankly, I didn’t like to deal with it anywhere near as much as I did with Oracle DB.
Anyway, I still recognize a large segment of companies using the MS SQL DB as the main database that is the single point of truth to all the data.
Main Advantages
Main advantages that MS SQL DB has:
✅ Good integration with other Microsoft services and software, in case this is a feature you recognize as valuable to your case.
✅ Easy customization with custom code extensions, mostly in the form of Javascript code modules. This can be useful when dealing with more complex business processes and jobs to be scheduled over the database.
✅ Quite simple from an administration perspective (at least in comparison to Oracle DB).
✅ It probably makes much more sense in the Azure cloud ecosystem, as there it is considered a native relational database system, much more compatible with other cloud services there.
Main Disadvantages
- Similarly to the Oracle DB case, as a non-native database in the space of AWS cloud, all the support and problem resolution has to be driven via separate dedicated MS SQL support teams.
- Less diversification of functionality support in general whenever comparing it to Oracle DB or Aurora DB.
- Not suitable for a large number of active users.
- Horizontal scalability is an even bigger issue than with the Oracle DB case.
When to Choose
MS SQL DB is best suited if you want to migrate the existing MS SQL DB on-premise into the cloud with as few distractions around as possible. Also, you don’t expect that integration with other AWS cloud services to much of an extent.
Then the MS SQL DB will live inside the AWS cloud as a fully managed database with unlimited storage and extended options for horizontal scalability and high availability compared to the on-premise alternative.
Example of Use
- Acting as a middle ground platform for custom integration of various database systems (could be even of a different type, for example, Oracle DB).
- Various smaller scale projects where the cost of the database solution is a thing to consider, and the budget is more limited (and does not allow to go for a full-fledged Oracle DB solution).
AWS MySQL and PostgreSQL DB
These databases are both open source by origin (although now already bought by bigger companies), ultimately giving them both benefits and disadvantages.
They are also not as feature-rich as other alternatives, especially in their native form. And while you can still use them both in AWS infrastructure in this form, I doubt this still makes too much practical sense.
How It Differs
When migrating the on-premise DB (be it MySQL or PostgreSQL) to the AWS cloud, you can just directly use Aurora with MySQL or PostgreSQL engine as a target and so get all the additional benefits Aurora DB has to offer.
Sure, it will mean some additional effort for the migration phase in comparison to the case when a native alternative would be chosen. But that additional effort will be only marginal.
Their main benefit lies in the costs and that they are best suitable for small project initiatives, where robustness is not really a topic.
Main Disadvantages
- Both are quite limited in supported functionality, and you need to be prepared for limited options for maintainability and administration.
- Not suitable for large-scale projects with many active users.
- Not best for high-performance solutions and where constant performance tuning is a strong requirement.
When to Choose
- If cost is the main topic and the budget is very limited.
- If the project initiative is rather small.
- If the data volume is rather small and there are no plans for significant growth.
Example of Use
- Personal projects initiatives where the cost of the infrastructure shall be as minimal as possible.
- Small POCs that would prove that the proposed concept can be realized.
- Small companies’ projects with small amounts of data.
- For small SaaS projects, not requiring an extensive amount of database loads, just data storage in a relational data model way is all that is really required.
AWS MariaDB
MariaDB is still a fully open-source database created by former MySQL developers (after MySQL’s acquisition by Oracle).
In terms of compatibility, any MySQL DB will run just fine inside MariaDB.
How It Differs
Function-wise, there are not many differences from MySQL to expect, but the open source property is the highlight.
Technically, there is quite a number of useful features that are available in MariaDB but not in MySQL.
Main Disadvantages
Quite similar to the MySQL case.
When to Choose
- If you absolutely love your current MariaDB on-premise implementation and don’t want to migrate to Aurora DB, for whatever reason.
- If you want to stay truly open-source with your database solution inside the AWS cloud ecosystem.
Example of Use
Quite similar to the MySQL case.
Final Words
Similarly, as Oracle DB was the solution in the on-premise world, it seems that Aurora DB is taking this place in the AWS cloud world. At least from the perspective of the feature sets, this is the closest you can get.
And even if you are not really after the main stakeholders, it is good to know there are still quite straightforward options on how to migrate your existing database into the AWS cloud.
Better yet – with this switch, you will automatically get features you were most likely lacking until then. Most importantly, better storage expandability, high availability, and horizontal scalability are all native features of the cloud environment.
