---
title: Which AWS Database Should I Use?
description: Pick the right AWS database in 60 seconds — relational, NoSQL, document, ledger, vector, or in-memory. Answer 4 questions to get an opinionated recommendation with links to comparisons and service pages.
url: https://www.factualminds.com/decide/which-aws-database/
category: database
publishDate: 2026-04-30
updateDate: 2026-04-30
---

# Which AWS Database Should I Use?

> Stop scrolling AWS docs. Answer four questions and get a one-screen recommendation with the comparison guide that goes deeper.

## How this decision tree was built

We mapped this tree against the recommendations we make in real architecture reviews. Each leaf links to the comparison guide and service page that go a level deeper. The tree intentionally covers the choices CTOs and senior engineers wrestle with — not every esoteric variant.

If your scenario does not match a clean leaf, the most likely answer is a hybrid: Aurora as the system of record, DynamoDB or ElastiCache for hot paths, and OpenSearch or S3 Vectors for search. That is a common, healthy production shape.

## Start Here

data-shape

## Decision Questions

### data-shape: What does your data look like?

_Pick the closest match — we'll narrow further with the next question._

- "Strict relational tables with joins, transactions, and a fixed schema" → rdbms-ops
- "Documents (JSON-shaped objects), flexible schema, per-record reads" → document-scale
- "Key-value or wide-column at high request rate" → kv-scale
- "Time-series, events, or telemetry" → time-series-volume
- "Embeddings / vectors for AI search or RAG" → rec-vector
- "Graph relationships (social, fraud, knowledge graph)" → rec-neptune

### rdbms-ops: How comfortable are you operating PostgreSQL/MySQL yourself?

_Aurora abstracts more, but RDS gives finer control._

- "Want fully managed with global reads, autoscaling storage, and serverless option" → rdbms-scale
- "Want managed but classic — predictable instance sizing, traditional engine versions" → rec-rds
- "Need MySQL/Postgres-compatible at planet scale with strong consistency" → rec-aurora-dsql

### rdbms-scale: Is the workload steady, spiky, or globally distributed?

_Aurora has a Serverless v2 option for spiky and a Global Database for multi-region._

- "Spiky / unpredictable / dev/test — want to scale to zero" → rec-aurora-serverless
- "Steady production with multi-AZ — want best price-perf" → rec-aurora-provisioned
- "Multi-region active-active or active-passive" → rec-aurora-global

### document-scale: How critical is single-digit-millisecond latency at high concurrency?

_DocumentDB is MongoDB-compatible. DynamoDB is purpose-built for low-latency at any scale._

- "Yes — millions of reads/sec, < 10 ms p99 required" → rec-dynamodb
- "No — but my app is already written against the MongoDB driver" → rec-documentdb
- "Just need flexible JSON in a relational engine I already run" → rec-postgres-jsonb

### kv-scale: How hot is the working set?

_ElastiCache is in-memory. DynamoDB scales horizontally with sub-10 ms p99._

- "Hot working set fits in memory; need sub-millisecond reads (sessions, leaderboards, rate limiting)" → rec-elasticache
- "Working set doesn't fit in memory; need single-digit ms at any scale" → rec-dynamodb
- "Wide-column / Cassandra workload" → rec-keyspaces

### time-series-volume: What is the ingestion rate?

_Timestream is purpose-built for high-volume time-series with cheap long-term storage._

- "Millions of points/sec — IoT, observability, financial ticks" → rec-timestream
- "Lower volume, but need to query across years of data" → rec-redshift-ts

## Recommendations

### rec-rds: Amazon RDS (Postgres or MySQL)

The classic choice when you want managed Postgres or MySQL with predictable instance sizing and full engine compatibility.
**When to use:**
- You need exact open-source engine version + extension compatibility
- You want predictable, instance-based pricing
- Your team is already comfortable with traditional Postgres/MySQL ops
**When NOT to use:**
- You need autoscaling storage, multi-AZ writers, or scale-to-zero — use Aurora
- You're hitting connection limits — try RDS Proxy or evaluate Aurora
**AWS services:**
- [AWS RDS Consulting](/services/aws-rds-consulting/)
**Comparisons:**
- [RDS vs Aurora](/compare/aws-rds-vs-aurora/)
- [Heroku Postgres to AWS RDS migration](/compare/heroku-postgres-to-aws-rds/)

### rec-aurora-serverless: Aurora Serverless v2

Pay-per-second Postgres/MySQL that scales from 0.5 ACUs up — best fit for spiky, unpredictable, or dev/test workloads.
**When to use:**
- Traffic is spiky or unpredictable
- Dev/test environments where idle time dominates
- New product where capacity is unknown
**When NOT to use:**
- Steady high-traffic workload — provisioned Aurora is cheaper
- You need extension compatibility Aurora does not yet support
**AWS services:**
- [AWS RDS Consulting](/services/aws-rds-consulting/)
**Comparisons:**
- [Aurora Serverless vs Provisioned](/compare/aws-aurora-serverless-vs-aurora-provisioned/)
- [RDS vs Aurora](/compare/aws-rds-vs-aurora/)

### rec-aurora-provisioned: Aurora (Provisioned)

Default choice for steady production Postgres/MySQL — better price-perf than RDS, autoscaling storage, and 15 read replicas.
**When to use:**
- Steady production workload with predictable load
- You want the operational simplicity of managed Postgres/MySQL with cloud-native storage
- You need fast point-in-time recovery and faster failover than RDS
**When NOT to use:**
- Truly spiky workload — Aurora Serverless v2 is cheaper
- You depend on a Postgres extension Aurora does not yet support
**AWS services:**
- [AWS RDS Consulting](/services/aws-rds-consulting/)
**Comparisons:**
- [RDS vs Aurora](/compare/aws-rds-vs-aurora/)

### rec-aurora-global: Aurora Global Database

Active-passive or active-active across regions with sub-second cross-region replication — for SaaS that needs disaster recovery or low-latency global reads.
**When to use:**
- You have customers across multiple regions and need < 100 ms read latency
- You need a documented RPO < 1s and RTO < 1 minute
- Compliance forces a multi-region failover plan
**When NOT to use:**
- Single-region workload — pay only for what you need
- You can tolerate read replicas in-region instead
**AWS services:**
- [AWS RDS Consulting](/services/aws-rds-consulting/)

### rec-aurora-dsql: Aurora DSQL

Distributed Postgres with virtually unlimited horizontal scaling and active-active across regions. New for 2025 — best fit when traditional Postgres tops out.
**When to use:**
- Postgres-compatible workload that has outgrown a single Aurora cluster
- Multi-region active-active writes are a hard requirement
**When NOT to use:**
- You don't need horizontal write scaling yet — Aurora is simpler and cheaper
**Comparisons:**
- [RDS vs Aurora](/compare/aws-rds-vs-aurora/)

### rec-dynamodb: Amazon DynamoDB

Serverless key-value and document store with single-digit ms latency at any scale. Default NoSQL choice when you can model around access patterns.
**When to use:**
- You can design around access patterns, not relational normalization
- You need predictable < 10 ms p99 at millions of requests/sec
- Spiky traffic where on-demand pricing wins on cost
**When NOT to use:**
- You need ad-hoc joins or analytical queries — pair with OpenSearch or use Aurora
- Strong consistency across multi-row transactions is the dominant pattern
**AWS services:**
- [AWS Architecture Review](/services/aws-architecture-review/)
**Comparisons:**
- [DynamoDB vs RDS](/compare/dynamodb-vs-rds/)
- [MongoDB Atlas to DocumentDB](/compare/mongodb-atlas-to-documentdb/)

### rec-documentdb: Amazon DocumentDB

MongoDB-compatible managed service. The right migration target if your application already speaks the MongoDB wire protocol and you want managed AWS infrastructure.
**When to use:**
- Existing MongoDB application you do not want to rewrite
- You want backups, IAM auth, and VPC isolation managed by AWS
**When NOT to use:**
- Greenfield project — DynamoDB is usually a better fit
- You depend on a recent MongoDB feature DocumentDB does not yet support
**Comparisons:**
- [MongoDB Atlas to DocumentDB](/compare/mongodb-atlas-to-documentdb/)

### rec-postgres-jsonb: Aurora / RDS Postgres with JSONB

Often-overlooked answer. If you already run Postgres and just need a flexible JSON column for semi-structured data, JSONB is great — and you don't need a second database.
**When to use:**
- Postgres is already your system of record
- JSON shape is mostly stable; you need occasional flexibility
- You want one operational footprint, not two
**When NOT to use:**
- Document is the dominant access pattern at high concurrency — DynamoDB scales further
**Comparisons:**
- [RDS vs Aurora](/compare/aws-rds-vs-aurora/)

### rec-elasticache: Amazon ElastiCache (Valkey / Redis OSS)

In-memory store for sessions, leaderboards, rate limiting, and cache-aside patterns. Sub-millisecond reads when the working set fits in memory.
**When to use:**
- Hot working set < memory budget
- Sessions, rate limits, leaderboards, real-time counters
- Caching layer in front of RDS/Aurora to relieve read pressure
**When NOT to use:**
- Working set doesn't fit — DynamoDB scales further at predictable cost

### rec-keyspaces: Amazon Keyspaces (for Apache Cassandra)

Serverless Cassandra. Use only when you have an existing Cassandra workload — for greenfield wide-column use cases, DynamoDB is almost always a better fit.
**When to use:**
- Existing Cassandra application with CQL compatibility requirements
- You want Cassandra without operating a cluster
**When NOT to use:**
- Greenfield — DynamoDB is cheaper and operationally simpler

### rec-timestream: Amazon Timestream

Time-series database with automatic tiered storage — recent data hot, older data demoted to cheaper storage automatically. Cheaper than running InfluxDB or Postgres for high-volume telemetry.
**When to use:**
- IoT or observability ingest at millions of points/sec
- You need cheap long-term retention with fast recent queries
**When NOT to use:**
- Low ingest volume — Postgres TimescaleDB extension or Aurora is fine

### rec-redshift-ts: Amazon Redshift

Cloud data warehouse. Best fit when time-series queries are part of broader analytics workloads with joins across many tables.
**When to use:**
- BI dashboards and analytical queries beyond pure time-series
- You already have a Redshift footprint
**When NOT to use:**
- Pure high-volume time-series — Timestream is cheaper

### rec-vector: Amazon S3 Vectors or OpenSearch Serverless

Bedrock Knowledge Bases supports both as vector stores. S3 Vectors is the cheapest option for cold/medium-traffic RAG; OpenSearch Serverless wins on hybrid keyword + vector search.
**When to use:**
- You are building a Bedrock-based RAG pipeline
- You want a vector store managed by AWS, not a third party
**When NOT to use:**
- Already heavily invested in Pinecone or pgvector and the migration cost outweighs the savings
**AWS services:**
- [AWS Bedrock Consulting](/services/aws-bedrock/)
- [Generative AI on AWS](/services/generative-ai-on-aws/)

### rec-neptune: Amazon Neptune

Managed graph database supporting Gremlin, openCypher, and SPARQL. Use when relationships ARE the workload — not as a generic data store.
**When to use:**
- Knowledge graph, fraud detection, social/identity graph
- Multi-hop traversal queries are the dominant pattern
**When NOT to use:**
- You can model the relationships as a few joins in Postgres — start there

## FAQ

### How accurate is this decision tree for production workloads?
It captures the patterns we see across our consulting engagements, but every workload has trade-offs the tree cannot encode (compliance, existing operational expertise, multi-region requirements, etc.). Use it as a starting point, then validate with the linked comparison guides — and book an architecture review if the choice is load-bearing.

### Why is DocumentDB ranked behind DynamoDB for greenfield projects?
For new projects, DynamoDB has lower operational cost, better latency at high concurrency, and a more capable serverless billing model. DocumentDB is the right answer mostly when you already have a MongoDB application you want to keep without rewriting.

### When should I use Aurora DSQL instead of regular Aurora?
Only when you have outgrown a single Aurora cluster — typically when write throughput requires sharding or you need active-active multi-region writes. Aurora DSQL pricing and operational model is different from Aurora; do a proof-of-concept before committing.

---

*Source: https://www.factualminds.com/decide/which-aws-database/*