Which Database Should You Choose?

In part eight and part nine we covered RDS, Aurora and ElastiCache. But open the AWS menu and you'll find more than ten database services, and that's where people get lost.

The right question isn't "what's the best database?", because there's no single answer. The question is: what suits this particular data?

Questions to start with #

Before opening any service, answer these:

Question	Why it matters
What shape is the data?	Linked tables, varied documents, relationships or readings over time
How will you read it?	By key, with complex queries joining tables, by searching text or by aggregating millions of rows
How much reading versus writing?	Heavy reads can be solved with a cache and replicas; heavy writes need a different design
How big, and how fast is it growing?	Ordinary gigabytes, or data that grows without a ceiling
How accurate must it be?	A money transfer needs strict transactions; a like count can tolerate delay
How much can you manage?	A small team prefers a service that scales by itself
What does your team know?	Existing knowledge spares you many mistakes

Types of database #

Type	Shape of the data	AWS service	Example
Relational	Linked tables and transactions	RDS and Aurora	Orders, accounts, invoices
Key-value	A value fetched by its key, at huge scale	DynamoDB	Carts and user profiles
Document	JSON with varied fields	DocumentDB and DynamoDB	Catalogs and content
In-memory	Fast data	ElastiCache and MemoryDB	Caching and sessions
Wide-column	Cassandra-style rows with heavy writes	Keyspaces	Existing Cassandra systems
Graph	Connections between things	Neptune	Social networks and fraud detection
Time series	Readings over time	Timestream for InfluxDB	Sensors and metrics
Search	Text you search inside	OpenSearch	Site search and logs
Analytics	Aggregation over huge data	Redshift	Management reports
Files	Files of any kind	S3 with Athena	Logs and archives

Relational or NoSQL? #

This is the first decision, and the real difference is in how you think:

	Relational (SQL)	NoSQL
Design	Design the tables, then write any query	Define the queries first, then design around them
Queries	Flexible, with table joins	Limited, and fast along the path you designed
Transactions	Strong	Varies by service
Scaling	Reads are easy; writes usually mean a bigger server	Horizontal, with steady performance as it grows

Services you'll come across #

• DynamoDB: serverless key-value with steady performance at any size. We cover it in part twenty-one.
• DocumentDB: documents compatible with MongoDB, which suits you if you're moving an existing MongoDB application.
• MemoryDB: fast memory like Valkey but with durable data, so you can use it as a primary database and not just a cache.
• Keyspaces: compatible with Apache Cassandra, with no servers to manage.
• Neptune: for data whose value lies in relationships, such as "friends of my friends who bought this".
• Timestream for InfluxDB: for sensor readings and metrics. The older LiveAnalytics edition is closed to new customers.
• OpenSearch: text search and log analysis, usually a copy of your data rather than the main source.
• Redshift: a data warehouse for huge reports. We cover it in part twenty-three.

How to decide #

Go through the questions from top to bottom, and the first "yes" is your starting point:

This is a starting guide, not a law. One application usually uses more than one type, with each kind of data going where it fits.

A data layer that grows with your application #

You don't need all this from day one. Imagine an online store growing over time:

1. Launch: a single RDS database is enough. Once you take real orders, turn on Multi-AZ.
2. More visitors, heavier reads: add ElastiCache for main pages and sessions.
3. Reports start slowing the site: send them to a read replica.
4. Product search is weak: add OpenSearch and fill it from the database.
5. Management wants years of analysis: move the data to S3 with Athena or Redshift.
6. Visitors from around the world: move to Aurora Global Database.

Each step came after a real problem you measured, not before it. Every extra service means more cost, more complexity and one more thing that can fail.

Common mistakes #

• Choosing NoSQL because it "scales": then discovering you need queries you didn't design for.
• Running reports on the production database: one heavy query slows the whole site.
• Storing files inside the database: put them in S3 and keep the link in the database.
• Treating the cache as a source of truth: if it's lost, nothing important should go with it.
• Multi-AZ in development: double the cost, usually for no benefit.

Summary #

• Ask about the shape of the data and how you'll read it before any service name.
• Start relational unless you have a clear reason not to.
• One application uses more than one type, with each kind of data going where it fits.
• Add each service when you measure a real problem, not before.

Test yourself #

Before you move on, try these questions to check you've got this part. Each one is a practical scenario, and the explanation appears once you answer.

That completes the databases section. Your application now runs, scales and keeps its data safe, but how do visitors reach it by your site's name? That's the next section's subject, starting in part eleven with DNS and Route 53.