Cloud platforms offer many database options: managed RDBMS, NoSQL, time-series, graph, in-memory, ledger, etc. The right choice depends on data shape, access patterns, scale, and operational needs.
This page is about the major categories and decision criteria. AWS service names dominate the examples; equivalents exist on GCP and Azure.
RDS provides managed PostgreSQL, MySQL, MariaDB, Oracle, SQL Server. AWS handles backups, patching, replication, failover.
Aurora is AWS's reimagining of MySQL/PostgreSQL with cloud-native storage:
For PostgreSQL workloads on AWS, Aurora is usually the right default. RDS PostgreSQL is fine for smaller workloads or when Aurora's pricing doesn't fit.
For most application backends, this is the default choice.
Key-value/document store. AWS-managed; fully serverless.
DynamoDB requires designing access patterns up front. The data model encodes the queries; you can't ad-hoc query DynamoDB efficiently.
DynamoDB has a learning curve. Most teams start with RDBMS; DynamoDB is for specific high-scale needs.
In-memory cache. Sub-ms reads. For:
Managed document store. MongoDB API compatibility (with caveats). For document-shaped data with JSON workflows.
Managed graph database. For genuinely graph-shaped problems (recommendations, fraud detection, knowledge graphs). Niche.
Time-series database. For metrics, IoT data, observability streams.
Not a database; a query engine over S3 data lakes. For analytical queries over large infrequently-accessed data.
Running PostgreSQL, MySQL, etc. on EC2 yourself. Pros:
Cons:
For most teams, the operational savings of managed databases exceed the cost premium. Self-manage only when there's a specific reason (regulatory, cost at scale, specific feature need).
Is the data relational with complex queries?
├── Yes → RDS / Aurora
└── No
├── Is access pattern predictable and high-scale?
│ ├── Yes → DynamoDB
│ └── No → Reconsider; might still want RDBMS
├── Is it cache-shaped (read-heavy, ephemeral)?
│ └── Yes → ElastiCache
├── Is it time-series?
│ └── Yes → Timestream or InfluxDB-on-EC2
└── Is it graph-shaped?
└── Yes → Neptune
For typical web apps: RDS PostgreSQL + ElastiCache Redis covers ~90% of needs.
Managed databases handle backups automatically. Verify retention period. Test restore occasionally — backups that have never been restored are aspirational.
Multi-AZ deployments are essential for production. The automatic failover handles AZ outages without manual intervention. Pay the extra cost.
CloudWatch metrics for RDS/Aurora/DynamoDB. Performance Insights for query-level analysis on RDS/Aurora. Custom metrics where needed.
Managed database costs include:
Unexpected cost spikes usually come from data transfer or storage growth.
Many cloud databases need connection pooling, especially with Lambda. RDS Proxy is the AWS solution; PgBouncer (community) is an alternative.
Database Migration Service (DMS) replicates from on-prem or self-hosted to managed services. Useful for migrations with downtime constraints.
Switching from RDS to Aurora is straightforward (compatible). Switching engines (Postgres ↔ MySQL) requires schema conversion. Switching paradigms (RDBMS ↔ NoSQL) is essentially a rewrite.