aws-database

Describe your workload — data model, access patterns, and scale — and the Skill routes you through a selection procedure. New SQL applications typically land on Aurora DSQL or Aurora PostgreSQL, while key-value workloads with defined access patterns route to DynamoDB.

Aurora DSQL is the default for new applications needing serverless operations, multi-region active-active writes, and zero maintenance. Choose Aurora PostgreSQL only when you need features DSQL lacks, such as pgvector, PostGIS, stored procedures, or triggers.

Yes, the Skill works with or without the AWS MCP server. When the MCP server is available it is recommended for documentation lookups and skill retrieval, but knowledge cards and llms.txt documentation URLs provide fallback fact sources.

Yes, migrations route to the managed equivalent: RDS for Oracle, ODB@AWS, or RDS for SQL Server. If you want to change engines entirely, the refactor path recommends Aurora PostgreSQL with AWS SCT and DMS for schema conversion and data movement.

Use MemoryDB only when you explicitly need multi-region active-active writes, since ElastiCache cross-region replicas are read-only. For all other in-memory workloads, ElastiCache (Valkey) offers the same durability and latency at lower cost with a serverless option.

DynamoDB requires access patterns to be designed upfront, does not support JOINs, and has a 400KB item limit. It is not recommended for small-scale workloads, ad-hoc queries, or applications with frequently changing access patterns.