Databases on AWS: How to Choose

Publication date: August 16, 2022 (Document revisions)

Abstract

Amazon Web Services (AWS) offers 15+ purpose-built database engines to support diverse data models, including relational, key-value, document, in-memory, graph, time series, wide column, and ledger databases. With so many choices comes the responsibility for architects to pick the right database(s) for your use case requirements. The guidance in this paper is intended to help you ask the right questions to discover your requirements, and provide clear guidance on how to evaluate databases and their options.

Introduction

AWS provides multiple options for hosting databases, ranging from hosting your own database on AWS infrastructure to using a fully managed database with and without serverless options.

With hosted databases, AWS provides the infrastructure to host the custom database of choice. It’s still your responsibility to take care of the management needs of the database, such as operational (software installation, configuration, patching, and backups), availability, performance, scalability (capacity planning and scaling clusters for compute and storage), and security (network isolation, encryption, compliance programs such as PCI, HIPAA, FedRAMP, ISO, and SOC).

With fully managed AWS database services, administration tasks such as server provisioning, patching, setup, configuration, backups, and recovery are simplified by AWS. AWS continuously monitors your databases to keep your workloads up and running with self-healing storage and automated scaling. This enables your teams to focus on high value application development tasks such as schema design, query construction, and optimization, leaving AWS to take care of operational tasks on your behalf.

The choice within managed databases expands further. You can lift and shift your self-managed databases such as Oracle, SQL Server, MySQL, PostgreSQL, and MariaDB to Amazon Relational Database Service (Amazon RDS). For better performance and availability, you can move your MySQL and PostgreSQL databases to Amazon Aurora and get better throughput.

Non-relational databases such as MongoDB and Redis can be used as document and in-memory databases for use cases such as content management, personalization, mobile apps, catalogs, and real-time use cases such as caching, gaming leaderboards, and session stores. In most cases, workloads and applications can be migrated to a managed service without needing to rearchitect your applications, using the same database skill sets.

It’s a recommended microservice architecture pattern to loosely couple functional components, each with their own database per service. Data is then exposed only via the service API, and developers of each service are empowered to choose the best database solution that fits their data access patterns and needs. This leads to adopting a purpose-built database strategy that enables evolving the database solutions independently for each service that can be scaled with changing requirements, data access patterns, and features.