Choosing an AWS Database & Data Model

Start with the data and the access pattern

Database selection should begin with how the application reads and changes data, not with a favorite engine. Relational systems are a natural fit when data has well-defined relationships, transactions span related records, SQL is important, or integrity constraints are central to the design. Amazon RDS manages familiar relational engines, while Amazon Aurora provides MySQL- and PostgreSQL-compatible relational engines built around Aurora's distributed storage architecture.

A nonrelational model can be a better fit when the application's dominant access patterns do not require joins or a traditional normalized schema. DynamoDB is a key-value and document database designed around primary-key access and predictable scaling. Amazon DocumentDB provides a document model with MongoDB compatibility for applications that work naturally with JSON-like documents. ElastiCache keeps frequently used or short-lived data in memory when very low-latency access is more important than treating the cache as the system of record.

Operational and consistency requirements change the answer

Two workloads can store similar business entities yet need different databases. A financial workflow may prioritize relational transactions and constraints. A session or shopping-cart workload may need simple key-based operations at very high request rates. A content catalog may benefit from document-shaped records whose attributes vary. Database architecture therefore includes consistency needs, transaction boundaries, latency, geographic distribution, backup and recovery, security, and how much database administration the team wants AWS to manage.

Managed services also differ in how capacity is expressed. RDS commonly exposes instance and storage choices, DynamoDB offers on-demand and provisioned throughput modes, Aurora can use provisioned or serverless database capacity, and Amazon Redshift is optimized for analytical processing rather than transactional request paths. Comparing only storage price or engine syntax misses these operational differences.

• Relational: structured relationships, SQL, joins, and transactional integrity are primary concerns.
• Key-value: known key-based access patterns and horizontal scale dominate the design.
• Document: nested, document-shaped records and flexible attributes fit the application model.
• In-memory: caching, sessions, counters, or other latency-sensitive data benefits from memory-speed access.
• Warehouse/analytics: large scans, aggregations, and analytical SQL require a different execution model from OLTP.

Purpose-built does not mean one database per application

AWS describes its database portfolio as purpose-built because different data models solve different classes of problems. A single application can therefore use more than one store when each has a clear responsibility: for example, a relational system of record, DynamoDB for a high-scale key-value workload, and ElastiCache for hot data. This is often called polyglot persistence. It can improve fit, but it also introduces data synchronization, monitoring, backup, and operational complexity.

The practical boundary is ownership of truth. Before adding another database, decide which store is authoritative for each piece of data and how derived copies are refreshed. An analytics system such as Redshift should usually consume operational data rather than become the transactional database merely because it accepts SQL. Similarly, a cache is normally an acceleration layer rather than a substitute for durable source data.