Choosing an AWS database service
Taking the first step
Purpose |
Help determine which AWS database or databases are the best fit for your organization. |
Last updated |
May 13, 2024 |
Covered services |
Introduction
Amazon Web Services (AWS) offers a growing number of database options (currently more than 15) to support diverse data models. These include relational, key-value, document, in-memory, graph, time-series, wide column, and ledger databases.
Choosing the right database or multiple databases requires you to make a series of decisions based on your organizational needs. This decision guide will help you ask the right questions, provide a clear path for implementation, and help you migrate from your existing database.
Understand
Databases are important backend systems used to store data for any type of app, whether it's a small mobile app or an enterprise app with internet-scale and real-time requirements.
This decision guide is designed to help you understand the range of choices available to you, establish the criteria that make sense for you to make your database choice, provide you with detailed information on the unique properties of each database—and then allow you to dive deeper into the capabilities that each offers.
What kinds of apps do people build using AWS databases?
-
Internet-scale apps: These apps can handle millions of requests per second over hundreds of terabytes of data. They automatically scale vertically and horizontally to accommodate your spiky workloads.
-
Real-time apps: Real-time apps such as caching, session stores, gaming leaderboards, ride-hailing, ad-targeting, and real-time analytics need microsecond latency and high throughput to support millions of requests per second.
-
Enterprise apps: Enterprise apps manage core business processes, such as sales, billing, customer service, human resources, and line-of-business processes, such as a reservation system at a hotel chain or a risk-management system at an insurance company. These apps need databases that are fast, scalable, secure, available, and reliable.
-
Generative AI apps: Your data is the key to moving from generic applications to generative AI applications that create differentiating value for your customers and their business. Often, this differentiating data is stored in operational databases powering your applications.
Note
This guide focuses on databases suitable for Online Transaction Processing (OLTP) applications. If you need to store and analyse massive amounts of data quickly and efficiently (typically met by an online analytical processing (OLAP) application), AWS offers Amazon Redshift, a fully managed, cloud-based data warehousing service that is designed to handle large-scale analytics workloads.
There are two high-level categories of AWS OLTP databases—relational and non-relational.
-
The AWS relational database family includes eight popular engines for Amazon RDS and Amazon Aurora. The Amazon Aurora engines include Amazon Aurora with MySQL compatibility, and Amazon Aurora with PostgreSQL compatibility. The other RDS engines include Db2, MySQL, MariaDB, PostgreSQL, Oracle, and SQL Server. AWS also offers deployment options such as Amazon RDS Custom and Amazon RDS on Outposts.
-
The non-relational database options are designed for specific data models including key-value, document, caching, in-memory, graph, time series, wide column, and ledger data models.
We explore all of these in detail in the Choose section of this guide.
Database migration
Before deciding which database service you want to use to work with your data, you should spend time thinking about your business objective, database selection, and how you are going to migrate your existing databases.
The best database migration strategy helps you take full advantage of the AWS Cloud. This might involve migrating your applications to use purpose-built cloud databases. You might just want the benefit of using a fully managed version of your existing database, such as RDS for PostgreSQL or RDS for MySQL. Alternatively, you might want to migrate from your commercial licensed databases, such as Oracle or SQL Server, to Amazon Aurora. Consider modernizing your applications and choosing the databases that best suit your applications' workflow requirements.
For example, if you choose to first transition your applications and then transform them, you might decide to re-platform (which makes no changes to the application you use, but lets you take advantage of a fully managed service in the cloud). When you are fully in the AWS Cloud, you can start working to modernize your application. This strategy can help you exit your current on-premises environment quickly, and then focus on modernization.
The following image shows how the AWS Database Migration Service
Consider
You're considering hosting a database on AWS. This might be to support a greenfield/pilot project as a first step in your cloud migration journey, or you might want to migrate an existing workload with as little disruption as possible. Or perhaps you would like to port your workload to managed AWS services or even refactor it to be fully cloud-native.
Whatever your goal, considering the right questions will make your database decision easier. Here's a summary of the key criteria to consider.
Choose
Now that you know the criteria by which you are evaluating your database options, you are ready to choose which AWS database services might be a good fit for your organizational requirements.
This table highlights the type of data each database is optimized to handle. Use it to help determine the database that is the best fit for your use case.
Database families | When would you use it? | What is it optimized for? | Related database engines or services |
---|---|---|---|
Relational |
Use when you're migrating or modernizing an on-premises relational workload or if your workload has less predictable query patterns. |
Optimized for structured data stored in tables, rows, and columns. They support complex queries through joins. |
|
Key-value |
Use for workloads such as session stores or shopping carts. Key-value databases can scale to large amounts of data and extremely high throughput of requests, while servicing millions of simultaneous users through distributed processing and storage. |
Optimized for consistent single-digit millisecond performance at any scale (meaning any number of writes and reads). |
|
In-memory |
Use Amazon ElastiCache when you need a caching layer to improve read performance. Use Amazon MemoryDB for Redis when you need full data persistence, but still need sub-millisecond read latencies. |
ElastiCache is optimized to support microsecond reads and sub-millisecond writes. MemoryDB supports microseconds reads and single-digit milliseconds writes. ElastiCache is an ephemeral cache while MemoryDB is an in-memory database. |
|
Document |
Use when you want to store JSON-like documents with rich querying abilities across the fields of the documents. |
Optimized for storing semi-structured data as documents with multi-layered attributes. |
|
Wide column |
Use when you need to migrate your on-premises Cassandra workloads, or when you need to process data at high speeds for applications that require single-digit-millisecond latency. |
Optimized for workloads that require heavy reads/writes and high throughput coupled with low latency and linear scalability. |
|
Graph |
Use when you have to model complex networks of objects, such as social networks, fraud detection and recommendation engine use cases. |
Optimized for traversing and evaluating large numbers of relationships, and identifying patterns with minimal latency. |
|
Time series |
Use when you have a large amount of time series data, potentially from a number of sources, such as Internet of Things (IoT) data, application metrics, and asset tracking. |
Optimized for storing and querying data that is associated with timestamps and trend lines. |
|
Ledger |
Use when your organization has to communicate with other entities (businesses, customers) and you need a way to verify and trust each other, or when you not only need to retrieve the current state of data, but need to prove how data mutated into the current state. |
Optimized for maintaining a complete, immutable, and verifiable history of database changes. |
Use
Just as there is no single database that can satisfy all possible use cases effectively at the same time, any particular database type discussed above, may not satisfy all your requirements perfectly.
Consider your needs and workload requirements carefully and prioritize based on the considerations covered above, the requirements you must meet to the highest standard, the ones you might have some flexibility on, or even the ones you can do without. This can form a system of values, that will help you make effective trade-offs, that lead to the best possible outcome for your unique circumstances.
Also consider that, usually, you will be able to cover your application requirements with a mix of best-fit databases. Building a solution with multiple database types allows you to lean on each, for the strengths it provides.
For example, in an e-commerce use case, you may use DocumentDB (for product catalogs and user profiles), leaning on the flexibility provided by semi-structured data (but also the low, predictable latency afforded by DynamoDB, when your users are browsing your product catalog). You may also use Aurora for inventory and order processing, where a relational data model and transaction support may be more valuable to you.
To help you learn more about each of the available AWS database services, we have provided a pathway to explore how each of the services work. The following section provides links to in-depth documentation, hands-on tutorials, and resources to get you started.
Explore
Architecture diagrams Explore reference architecture diagrams to help you develop, scale, and test your databases on AWS. |
Whitepapers Explore whitepapers to help you get started, learn best practices, and migrate your databases. |
AWS Solutions Explore vetted solutions and architectural guidance for common use cases for databases. |