How AWS relational databases compare

Relational databases have long been a fairly standard solution for a variety of (and almost all) software use cases that large or small businesses need to solve.

Today, with the widespread availability of NoSQL databases, in-memory databases, or data lake databases, that volatility is even greater. But nevertheless, whenever a decision is made to migrate a current on-premises database to the cloud, a relational database as a target remains the easiest option for this migration.

Let’s take a closer look at the following databases that could be part of such an effort:

• oracle
• aurora
• Microsoft SQL Server
• MySQL and PostgreSQL
• Maria DB

We will clearly explain how it differs from others, including its disadvantages. We then provide typical real-world use cases to put them into context. Finally, I will share my views on which to choose between different databases depending on your case.

AWS Oracle DB

Oracle DB has arguably been the most widely used commercial database of the past several decades. Whenever a company needs a robust, high-performance database solution, Oracle DB has always been the first choice. There are many good reasons for that.

What’s the difference?

Oracle is a robust and feature-rich platform that can accommodate a vast array of disparate setups and requirements. Over time, this DB has become the solution of choice when you need state-of-the-art reliability, scalability, and maintainability on your on-premises hardware infrastructure.

Main benefits

Here are some of the key benefits you get when you choose a mature database system like Oracle.

✅ Great support and options for effective backup and restore activities.

✅ Wide possibilities of how to tune the performance of DB solutions in your system. Long after that, the solution is already in production. The support and maintenance activities within this platform are very easy to set up and highly effective.

✅ Advanced customization of DB solutions. Oracle DB supports a wide range of features to choose from, providing system integrators with a robust set of platform features that include triggers, partitions, subpartitions, automated primary key sequences, views, etc. There are many options for building your own system. , snapshots, data constraints, unique keys, join keys, foreign keys, composite indexes, etc.). They will support you with everything.

✅ Easily manage database activities and processes. Dedicated management console and dashboard, and many administrator-only tools built by Oracle and ready to use.

✅ Support for multi-user environments. If your requirement is to support thousands of different active users simultaneously, Oracle is the answer.

Main disadvantages

Oracle DB is extremely flexible when it comes to vertically scaling performance. However, if you want strong horizontal scaling, it’s less important. This means you can easily upgrade to more powerful CPU, more memory, and storage space on your cluster DB.

However, when data grows significantly over a short period of time, which is often the case with data in the cloud, performance bottlenecks become more noticeable and difficult to resolve. Distributing data across multiple clusters and expecting them to grow dynamically will be a key requirement going forward. In this case, Oracle DB may start to become more limited than it can meet your future needs.

Another possible disadvantage is the cost. Oracle DB supports many features, many of which come at a cost. Even more so if you have multiple clusters in place and need physical performance upgrades. This means that software tuning of data models is no longer enough. For more management tools and features, you must purchase an Enterprise license. This further increases already high costs.

Finally, Oracle DB is not a native AWS DB service, so you can’t expect full support from AWS. I would rather focus on Oracle support. But then Oracle and AWS issues are handled in parallel by two different support teams.

when to choose

If you are already using Oracle DB in your current on-premises solution, choosing the cloud version of Oracle DB is the most natural decision. It also makes migrating and switching to cloud-based solutions much easier.

Therefore, choose AWS Oracle DB if:

• Cloud DB is expected to support the same processes and functionality as the on-premises version for the foreseeable future.
• We’re not going to integrate DB with too many AWS native services right away.
• We do not expect the current amount of data to increase significantly in the short term.
• It requires support for a huge amount of functionality. This means it’s difficult to lose some of what’s currently in place when switching to the cloud.
• The system must support hundreds (or more) of active users at the same time.

Usage example

• Large-scale communication systems for billing, CRM, and middleware data.
• Custom DB implementation for automotive database systems. It integrates with several different custom or third-party vendor tools.
• Packaged system solutions for the banking industry. Oracle is already a fixed part of vendors’ packaged solutions and will eventually integrate additional custom DB components into one complex implementation.

AWS Aurora DB

Aurora is in many ways the exact opposite of Oracle, even though it is still a relational database.

What’s the difference?

Autora DB is AWS’s native database service. AWS provides full support and continuous development for it, and deep integration with other AWS service ecosystems.

Aurora DB does not have the level of feature diversity that Oracle already has. But it was born in the cloud (unlike Oracle). As AWS further develops Aurora, the feature gap may be smaller in the future than it is today.

Aurora is already ahead of Oracle in many ways, especially when it comes to integration with other AWS cloud services. Additionally, since Amazon created Aurora with the cloud ecosystem in mind, horizontal scaling is a strong characteristic as Aurora can accommodate massive data revenue and growth over time.

Main benefits

The main benefits of Aurora DB are:

✅ Extremely flexible scalability of read-only DB copy instances. Create in just seconds. Read-only instances share the same DB log of the main database from which they originate. This means that if you create a new read-only database, you don’t need to synchronize all your data. It’s done automatically by sharing the existing one.

✅ Supports large-scale data growth – Horizontal scaling is a major feature of Aurora DB. It’s very easy to add new clusters to extend scalability across different Availability Zones. Aurora is very effective at selecting large amounts of data very quickly.

✅ You can choose between using Aurora DB’s server mode or serverless mode. Some features are not available in serverless mode. However, choosing serverless mode provides significant flexibility and cost optimization.

✅ Automatic backups and easy point-in-time restores. Another highlight is that Aurora DB allows you to easily perform daily backups and it is much easier to restore the entire database to any point in time. Here you can combine all the benefits of a cloud environment, including always available free space, fast operations inside AWS, and dedicated Aurora DB features for fast recovery times and low downtime.

✅ Supports MySQL or PostgreSQL DB engines, so you can choose what’s right for you.

Main disadvantages

• Aurora is probably the most feature-rich native relational database available on AWS, but it still lags behind Oracle in this regard. That’s understandable. Oracle used to spend much more time developing these features. The fact remains that Aurora DB is getting more powerful and closer with each release.
• There is no equivalent to Aurora DB in your on-premises space. You could argue that older databases built inside MySQL or PostgreSQL databases are nearly identical, but from a compatibility standpoint, they certainly are. However, they are not exactly equivalent. That means the transition isn’t that easy. To transfer data from on-premises and store it all in the correct data model format in Aurora DB, you must customize and implement a migration process.
• Various AWS limitations, especially severe ones, may in some cases be a deterrent to choosing this DB as a future target. It’s very likely that you can avoid all of them, but some will require a more serious investment in refactoring and will ultimately reduce the overall performance of your migration compared to another database target. Costs may increase.

when to choose

In short, choosing Aurora DB as your goto relational database on the AWS platform is never a bad decision, especially if you:

• Build a cloud system from scratch with a relational database at its core.
• We expect the highest level of compatibility and integration with the widest variety of native AWS services possible.
• Data volumes are expected to increase significantly in the short term.
• You plan to start some spin-off proof-of-concept (POC) projects that can take advantage of all the benefits of a serverless version of a relational database.

Usage example

• A serverless platform for analyzing large amounts of infrastructure imagery data.
• Leverage machine learning models to process data lake information and generate business predictions for your business.
• Netflix uses Aurora DB for fast parallel query execution on catalog data.

AWS Microsoft SQL DB

This database is comparable to Oracle in some ways. It was also created long before the cloud became popular, and there are many current on-premises users who plan to migrate to the cloud using MS SQL DB as a source.

What’s the difference?

Despite these similarities, MS SQL DB is still less used in the past compared to Oracle DB.

At least judging from the point of view of my personal experience. I have been involved in multiple Oracle projects over the past 20 years, and only a handful of cases involved MS SQL DB. And frankly, I didn’t like working with it as much as I did with Oracle DB.

In any case, I still find that most companies still use MS SQL DB as their main database, the single point of trust for all their data.

Main benefits

The main benefits of MS SQL DB are:

✅ Great integration with other Microsoft services and software (if this is a feature you find valuable in your case).

✅ Easy customization with custom code extensions (mainly in the form of Javascript code modules). This is useful when dealing with more complex business processes or jobs that are scheduled on a database.

✅ Very simple from a management perspective (at least compared to Oracle DB).

✅ It probably makes more sense in the Azure cloud ecosystem because it is considered a native relational database system and is much more compatible with other cloud services.

Main disadvantages

• As with Oracle DB, as a non-native database in the AWS cloud space, all support and issue resolution must be driven by a separate and dedicated MS SQL support team.
• Feature support is generally less diverse when compared to Oracle DB and Aurora DB.
• Not suitable for large numbers of active users.
• Horizontal scalability is an even bigger issue than with Oracle DB.

when to choose

MS SQL DB is ideal if you want to migrate your existing on-premises MS SQL DB to the cloud with as little disruption as possible. Also, integration with other AWS cloud services is not as expected.

MS SQL DB then resides in the AWS Cloud as a fully managed database with unlimited storage and expansion options for horizontal scalability and high availability compared to on-premises alternatives.

Usage example

• It acts as an intermediary platform for custom integration of various database systems (sometimes of different types, such as Oracle DB).
• Various small projects where you need to consider the cost of a database solution and have a more limited budget (a full-fledged Oracle DB solution is not available).

AWS MySQL and PostgreSQL DB

Both of these databases are open source (although now they have already been acquired by large companies), which ultimately brings both advantages and disadvantages.

It’s also not as feature-rich as other alternatives, especially in its native format. Although it is possible to use both in this format in your AWS infrastructure, I don’t think it makes much practical sense.

What’s the difference?

If you want to migrate your on-premises DB (MySQL or PostgreSQL) to the AWS Cloud, you can simply use Aurora directly by targeting the MySQL or PostgreSQL engine and get all the additional benefits that Aurora DB provides.

Admittedly, it requires additional effort during the migration phase compared to if a native alternative was chosen. But that extra effort is only marginal.

Its main advantage is cost, making it ideal for smaller project efforts where robustness is not as important.

Main disadvantages

• Both have very limited feature support, so you should expect limited maintainability and management options.
• Not suitable for large projects with many active users.
• It is not ideal for high-performance solutions or where continuous performance tuning is strongly desired.

when to choose

• When cost is the main theme and you have a very tight budget.
• Your project efforts are relatively small.
• The amount of data is fairly small and you don’t plan on increasing it significantly.

Usage example

• Personal project work with the lowest possible infrastructure costs.
• A small scale POC to prove the feasibility of the proposed concept.
• Small business projects that use small amounts of data.
• For small SaaS projects, you don’t need a large database load, you really only need data storage in a relational data model way.

AWS Maria DB

MariaDB is a completely open source database created by former MySQL developers (after the acquisition of MySQL by Oracle).

In terms of compatibility, any MySQL DB will work well within MariaDB.

What’s the difference?

Functionally, it doesn’t differ much from MySQL, but it’s notable that it’s open source.

Technically, there are many useful features available in MariaDB that are not available in MySQL.

Main disadvantages

It’s very similar to MySQL.

when to choose

• You really like your current on-premises implementation of MariaDB, but for some reason you don’t want to move to Aurora DB.
• You want to keep your database solution truly open source within the AWS cloud ecosystem.

Usage example

It’s very similar to MySQL.

last word

Similarly, while Oracle DB was the solution in the on-premises world, Aurora DB seems to have its place in the AWS cloud world as well. This is the closest thing to it, at least in terms of feature set.

And even if you’re not actually pursuing key stakeholders, it’s good to know that there are still very easy options for how to migrate your existing database to the AWS cloud.

Even better, this switch automatically gives you features you were likely missing before. Most importantly, superior storage scalability, high availability, and horizontal scalability are all native features of cloud environments.