Skip to main content
In this lesson we’ll focus on databases: what they are, why different types exist, and how to choose the right database for your workload. Across a country you’ll find many types of roads — interstates, city streets, jogging paths, cycling lanes, and shared-use paths. Each road type enforces different rules about who may use it and at what speeds. Highways are for fast-moving motor vehicles, city streets handle slower or mixed traffic, jogging paths are intended for pedestrians (sometimes cyclists) but not cars, and cycling paths are intended for bicycles only.
An isometric illustration of a city road network showing highways, city roads, a clock tower, buildings, vehicles and people. Labels point out features like Highways, Jogging Path, Cycling Path and City Road.
Just as roads are designed to meet different traffic needs, databases are engineered to satisfy different data and workload requirements. Each database type targets particular:
  • access patterns (random reads, streaming writes, analytical scans),
  • consistency and isolation guarantees (ACID transactions vs. eventual consistency),
  • latency characteristics (milliseconds for OLTP vs. seconds for OLAP),
  • scalability models (vertical vs. horizontal scaling),
  • and data shapes (rows/columns, documents, key-value, graphs, time-series).
For example:
  • A streaming service like Netflix needs databases that provide high write throughput, low-latency reads at scale, and horizontal elasticity.
  • A financial system requires strong consistency, ACID transactions, and strict durability.
  • A social network may combine document stores, key-value caches, and graph databases for different features.
AWS provides a wide range of purpose-built database services optimized for these varied use cases — relational, key-value, document, wide-column, time-series, graph, in-memory, and analytics databases. In this lesson we’ll review the major database types available on AWS, explain their core features, and give guidance on common use cases so you can confidently select the right database for each scenario — including preparing for the AWS Solutions Architect exam.
When choosing a database, match the database’s strengths to your application’s dominant access patterns and constraints (e.g., transactional guarantees, latency, scale, data shape). Often a system uses more than one database type — a pattern known as polyglot persistence.

​
Common database types, characteristics, and AWS services

​
Factors to consider when selecting a database

  1. Data model: relational tables vs. documents vs. key-value vs. graph.
  2. Consistency and transactions: do you need ACID transactions or eventual consistency?
  3. Query patterns: point lookups, range scans, joins, aggregations, graph traversals.
  4. Latency and throughput: single-digit millisecond reads vs. high write throughput.
  5. Scale and elasticity: expected growth, read/write distribution, and partitioning.
  6. Durability and backup needs: point-in-time recovery, replication, and backups.
  7. Operational overhead: fully managed service vs. self-managed instances.
  8. Cost model: storage, IOPS, data transfer, and provisioned capacity vs. on-demand.
  9. Indexing and secondary access paths: support for indexes, GSI/LSI, and search.
  10. Security and compliance: encryption, VPC integration, IAM controls, audit logging.
Choosing the wrong database for your workload can cause scalability, data consistency, or cost problems. Evaluate the dominant access pattern first — if reads are mostly point lookups, a key-value store might be ideal; if you need complex joins and transactions, choose a relational database.

​
Quick mapping: common scenarios to database choices

  • High-volume, low-latency lookups (millisecond reads): DynamoDB or ElastiCache.
  • Flexible JSON documents with rich querying: DocumentDB or DynamoDB (document model).
  • ACID transactions and complex joins: Amazon RDS / Amazon Aurora (MySQL/Postgres).
  • Low-latency caching for reads: ElastiCache (Redis).
  • Analytical queries across petabytes: Amazon Redshift or Athena over S3.
  • Time-series metrics and IoT: Amazon Timestream.
  • Graph relationship queries: Amazon Neptune.
  • Multi-model or mixed workloads: combine services (e.g., Aurora for transactions + Redshift for analytics + ElastiCache for hot reads).

​
Further reading and references

Use this lesson as a foundation to match database types to real-world application requirements. In subsequent sections we’ll dive deeper into individual services, design trade-offs, and sample architectures you can reuse in production and on the AWS Solutions Architect exam.

Watch Video