Cloud-Native Database Selection

Choosing a database in the cloud era is more complex than “PostgreSQL or MySQL.” Cloud providers offer 15+ managed database services each, spanning relational, document, key-value, time-series, graph, and vector workloads. The wrong choice means either fighting the database to do what it wasn’t designed for, or migrating later at massive cost. The right choice starts with understanding your access patterns, consistency requirements, and scale projections.

This guide provides a framework for selecting cloud-native databases based on workload characteristics, not marketing.

Database Decision Matrix

Workload Pattern	Best Fit	AWS	Azure	GCP
Transactional CRUD	Relational	RDS / Aurora	SQL Database	Cloud SQL / AlloyDB
Globally distributed	Multi-region relational	Aurora Global	Cosmos DB	Cloud Spanner
Document/flexible schema	Document store	DynamoDB / DocumentDB	Cosmos DB	Firestore
High-throughput key-value	Key-value store	DynamoDB / ElastiCache	Cosmos DB / Cache for Redis	Memorystore
Time-series metrics	Time-series DB	Timestream	Data Explorer	BigQuery (streaming)
Graph relationships	Graph DB	Neptune	Cosmos DB (Gremlin)	No native (use Neo4j)
Full-text search	Search engine	OpenSearch	AI Search	Vertex AI Search
Vector/AI embeddings	Vector DB	OpenSearch / RDS pgvector	Cosmos DB vCore	AlloyDB + pgvector
Data warehouse	Columnar analytics	Redshift	Synapse	BigQuery
Caching	In-memory	ElastiCache	Cache for Redis	Memorystore

Relational Databases

When to Choose Relational

ACID transactions are required
Complex joins across multiple tables
Well-defined, stable schema
Regulatory compliance requires structured data
Existing team expertise in SQL

Cloud Relational Comparison

Feature	Aurora (AWS)	Cloud SQL (GCP)	Azure SQL	AlloyDB (GCP)
Engine	MySQL/PostgreSQL	MySQL/PostgreSQL/SQL Server	SQL Server/PostgreSQL	PostgreSQL
Max storage	128 TB	64 TB	100 TB	128 TB
Read replicas	15	10	4	20
Multi-region	Aurora Global Database	Cross-region replicas	Geo-replication	Cross-region replicas
Serverless	Aurora Serverless v2	❌	Azure SQL Serverless	❌
Columnar	❌	❌	Columnstore indexes	Built-in columnar engine
Best for	High availability, scaling	Standard workloads	.NET ecosystem	Analytical + transactional

NoSQL Databases

DynamoDB Design Patterns

# Single-table design for e-commerce
TABLE_SCHEMA = {
    "TableName": "ECommerce",
    "KeySchema": [
        {"AttributeName": "PK", "KeyType": "HASH"},    # Partition key
        {"AttributeName": "SK", "KeyType": "RANGE"},    # Sort key
    ],
}

# Access patterns mapped to key design:
ITEMS = [
    # Customer profile:       PK=CUSTOMER#123, SK=PROFILE
    # Customer orders:        PK=CUSTOMER#123, SK=ORDER#2025-03-01#001
    # Order items:            PK=ORDER#001,    SK=ITEM#SKU-456
    # Product:                PK=PRODUCT#SKU-456, SK=DETAILS
    # Product reviews:        PK=PRODUCT#SKU-456, SK=REVIEW#2025-03-01#user123
    
    # GSI1: Order by status   GSI1PK=STATUS#SHIPPED, GSI1SK=2025-03-01
    # GSI2: Product by category GSI2PK=CATEGORY#Electronics, GSI2SK=PRICE#0099.99
]

NoSQL Selection Guide

Feature	DynamoDB	Cosmos DB	Firestore	MongoDB Atlas
Data model	Key-value/document	Multi-model	Document	Document
Consistency	Eventually/strong (per-item)	5 consistency levels	Strong	Configurable
Pricing	Read/write capacity units	Request units	Doc reads/writes	Instance-based
Serverless	On-demand mode	Serverless tier	Always serverless	Serverless instances
Max item size	400 KB	2 MB	1 MB	16 MB
Global dist.	Global tables	Turnkey multi-region	Multi-region	Atlas global clusters

Specialized Databases

Vector Databases (for AI/RAG)

Platform	Type	Dimensions	Best For
Pinecone	Managed vector DB	Up to 20K	Purpose-built, low latency
pgvector (RDS/AlloyDB)	PostgreSQL extension	Up to 2K	Existing PostgreSQL, small-medium scale
OpenSearch	Search + vector	Up to 16K	Hybrid text + vector search
Weaviate	Open source	Unlimited	Self-managed, flexible
Qdrant	Open source	Unlimited	High performance, filtering

Time-Series Databases

Use Case	Recommended	Why
IoT sensor data	Timestream / TimescaleDB	Optimized for high-write time-series
Application metrics	Prometheus + Thanos	Industry standard, PromQL
Business analytics over time	BigQuery / Redshift	SQL analytics, long retention
Real-time dashboards	InfluxDB / Timestream	Fast aggregation queries

Migration Considerations

Factor	Weight	Questions to Ask
Data volume	High	How much data? Growth rate?
Access patterns	Critical	Read-heavy or write-heavy? Query complexity?
Latency requirements	High	p99 latency target?
Consistency needs	Critical	ACID required? Eventual OK?
Team expertise	Medium	What does the team know? Training budget?
Vendor lock-in	Medium	Is portability important?
Cost at scale	High	Model costs at 10x current traffic
Compliance	Critical	Data residency? Encryption? Audit requirements?

Anti-Patterns

Anti-Pattern	Problem	Fix
Using relational for everything	Forcing graph queries into SQL joins	Use graph DB for relationship-heavy workloads
”We’ll scale later”	Choosing based on today’s data, ignoring growth	Model costs and performance at 10x scale
NoSQL without access pattern design	Random queries on DynamoDB → expensive scans	Design keys around access patterns first
Multi-database without justification	5 databases for 3 services	Consolidate unless workloads genuinely differ
Ignoring egress costs	Data transfer between services crushes budget	Co-locate databases with compute
No connection pooling	Lambda → RDS = connection exhaustion	Use RDS Proxy, PgBouncer, or serverless DB

Checklist

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For database consultation, visit garnetgrid.com. :::