AWS Purpose-Built Database Strategy - The Workload Optimization Philosophy Behind 15+ Specialized Databases
We explain the design philosophy behind AWS's 15+ purpose-built database services, comparing them with Azure Cosmos DB's unified approach and GCP's Cloud Spanner/Bigtable, and discuss the benefits of choosing the optimal database for each workload.
There Is No One-Size-Fits-All Database
There has been a long-standing debate in the database world: should you use a single general-purpose database for all workloads, or should you use specialized databases optimized for each workload? AWS clearly takes the latter position. It provides dedicated managed services for each data model - relational, key-value, document, graph, time-series, in-memory, and wide-column. At the foundation of this design philosophy is the practical judgment to avoid the performance degradation, operational complexity, and cost increases that arise from using a database that doesn't match the workload's characteristics. Rather than compromising with a general-purpose database, AWS's approach is to create an environment where you can choose an engine optimized for your purpose.
Overview of the AWS Database Portfolio
AWS's database services number over 15. In the relational space, RDS supports MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server, while Aurora is MySQL/PostgreSQL compatible and AWS says it offers 6x the throughput of PostgreSQL and MySQL (as of October 2026). In the NoSQL space, DynamoDB is a key-value store providing single-digit millisecond latency, and DocumentDB provides a MongoDB-compatible document database. Additionally, Neptune is a graph database, Timestream is a time-series database (Timestream for LiveAnalytics stopped accepting new customers on June 20, 2025), QLDB is a ledger database (discontinued in 2025), and Keyspaces is an Apache Cassandra-compatible wide-column store. MemoryDB is a durable in-memory database with Redis compatibility, and ElastiCache specializes in the caching layer. Because each service is developed and operated by an independent team, the depth of optimization for each data model is in a different league.
Comparison with Azure Cosmos DB's Unified Approach
Azure takes a unified approach with Cosmos DB, a single service that supports multiple data models. Cosmos DB provides APIs for document, key-value, graph, and wide-column data, with global distribution and multi-region writes as standard features. The advantages of this unified approach are clear: lower learning costs and simplified management since there's only one service to operate. However, the unified approach has structural trade-offs. Graph query optimization doesn't match a graph-dedicated engine like Neptune. Cosmos DB's RU (Request Unit)-based pricing model can also be difficult to predict depending on the workload, potentially leading to cost management complexity.
Comparison with GCP's Database Strategy
GCP provides database services including Cloud SQL, Cloud Spanner, Bigtable, Firestore, and Memorystore. Cloud Spanner in particular is technically outstanding as a globally distributed relational database, with the strength of horizontal scaling while maintaining strong consistency. However, GCP's database portfolio has fewer options compared to AWS. Time-series databases must be substituted with Bigtable. While acknowledging Spanner's technical superiority, AWS clearly surpasses GCP in the breadth of its portfolio for addressing workload diversity.
Practical Benefits of Purpose-Built Databases
The greatest benefit of purpose-built databases is performance optimization tailored to workload characteristics. DynamoDB makes read/write throughput predictable through partition key design, Timestream has a storage engine specialized for time-series data compression and aggregation queries, and Neptune natively supports both Property Graph and RDF graph models with optimized query execution plans for graph traversals. There are operational benefits as well. Since each service is independent, a failure in one database is less likely to cascade to others. Scaling policies can be set independently for each workload, and cost allocation is clear. The affinity with microservices architecture is also high, naturally enabling the Polyglot Persistence pattern where each service owns its own data store.
Practical Guidelines for Database Selection
It's natural to wonder "which one should I choose" when faced with AWS's rich database portfolio. The basic principle of selection is to work backward from your data model and access patterns. If you need transaction processing, Aurora is suitable. For low-latency key-value access, DynamoDB. For relationship exploration, Neptune. In systems where multiple data models coexist, the recommended design is to combine the optimal service for each workload rather than forcing everything into a single database.
Summary
AWS's purpose-built database strategy is based on the clear design philosophy of abandoning the illusion of a one-size-fits-all database and providing engines optimized for each workload. Azure Cosmos DB's unified approach has the advantage of simplified management, but it can't match the depth of optimization for each data model that specialized services offer. GCP's Cloud Spanner is technically excellent as a globally distributed relational database, but it can't match AWS in portfolio breadth. Database selection should work backward from data models and access patterns to choose the optimal service for each workload. With over 15 specialized databases, AWS is one of the platforms that offer wide freedom of choice.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.