Running a database yourself means dealing with backups, replication, patching, failover, capacity planning, and 3am pages. Managed cloud databases offload most of that. This lesson maps the landscape.
The Managed-Service Layers
From most-managed to least-managed:
- Serverless databases — scale to zero, pay per request
- Cloud-native managed — Aurora, AlloyDB, Spanner, Cosmos DB
- Standard managed — RDS, Cloud SQL, Azure SQL Database
- VM + database — EC2 + Postgres yourself
- On-prem / co-located
You generally want to live as high on this list as price and feature constraints allow.
Standard Managed Relational Databases
| Cloud | Service | Engines |
|---|---|---|
| AWS | RDS | Postgres, MySQL, MariaDB, Oracle, SQL Server |
| Azure | Azure Database for PostgreSQL/MySQL/MariaDB | Postgres, MySQL, MariaDB |
| GCP | Cloud SQL | Postgres, MySQL, SQL Server |
| Azure | Azure SQL Database / Managed Instance | SQL Server |
What you get:
- Automated backups, point-in-time recovery
- Minor-version patching during a maintenance window
- Read replicas with one click
- Multi-AZ / zone-redundant high availability
- Encryption at rest and in transit
- Metrics, logs, and alerting integrated with the cloud monitoring stack
What's still on you:
- Schema design and migrations
- Indexes and query performance
- Connection pooling at the app layer
- Right-sizing the instance and storage
Cloud-Native Reimplementations
Amazon Aurora
Aurora speaks Postgres or MySQL but stores data in a distributed, log-structured storage layer that replicates 6 ways across 3 availability zones. Faster failover (often under 30 seconds), better replication lag, up to 15 read replicas sharing the same storage.
Google AlloyDB
Postgres compatible. Separates compute from storage, uses columnar acceleration for analytics, and offers cross-region replicas. Targets demanding OLTP workloads.
Azure Cosmos DB for PostgreSQL
Distributed Postgres (formerly Citus) — sharded across nodes for horizontal scale-out.
Distributed SQL Databases
These give you a SQL interface and ACID transactions but spread data across many nodes and regions.
| Google Spanner | Globally consistent, paxos-replicated; powers Google Ads. Pricey but unique. |
| CockroachDB | Postgres-wire-compatible; survives node and region failures. |
| YugabyteDB | Postgres + Cassandra wire compatibility. |
| TiDB | MySQL-compatible distributed SQL with HTAP capabilities. |
Use these when single-node Postgres can't keep up with writes or you need multi-region strong consistency. They're more expensive and have higher per-query latency than a single-node DB.
Managed NoSQL
| Service | Cloud | Notes |
|---|---|---|
| DynamoDB | AWS | Key-value & document; single-digit-ms latency at any scale; pay-per-request or provisioned capacity |
| Cosmos DB | Azure | Multi-model (SQL API, MongoDB API, Cassandra API, Gremlin); global distribution; tunable consistency |
| Firestore | GCP | Document DB with realtime listeners; great for mobile apps |
| Bigtable | GCP | Wide-column for huge analytical workloads |
| Cloud Memorystore / ElastiCache / Azure Cache for Redis | All | Managed Redis |
| OpenSearch / Elastic Cloud | All | Managed search |
Serverless Databases
Pay only for what you use; scale to zero (or near-zero) when idle. Great for spiky workloads and dev environments.
| Aurora Serverless v2 | Postgres or MySQL; scales between min and max ACUs |
| Neon | Postgres-compatible; branching like Git; scales to zero |
| PlanetScale | MySQL-compatible (Vitess); branching, deploy requests, no foreign keys by default |
| Cloudflare D1 | SQLite at the edge |
| Supabase | Hosted Postgres + auth + realtime + storage; great for full-stack apps |
| DynamoDB on-demand | True per-request billing |
Cloud Data Warehouses
Different beast — columnar, optimised for analytics over huge datasets. Don't use them as your transactional DB; sync data into them.
- AWS Redshift
- Google BigQuery — serverless, scan-priced
- Snowflake — multi-cloud, separates compute and storage
- Databricks SQL — built on Delta Lake
- ClickHouse Cloud — open-source columnar, very fast
Cost Models
Be aware of how each service bills:
- Provisioned (RDS, Cloud SQL) — you pay for the instance whether or not it's used. Storage and IOPS billed separately.
- Per-request (DynamoDB on-demand, BigQuery) — pay per read/write or per byte scanned. Spiky traffic friendly; runaway queries can be expensive.
- Serverless ACU/RU (Aurora Serverless, Cosmos DB) — pay for compute units consumed. Usually a min floor.
- Storage — usually billed per GB-month. Backups and replicas count.
- Egress — pulling data out of the cloud or across regions can dwarf compute costs. Watch this.
Choosing Between Managed and Self-Hosted
| Reason to self-host | Reason to use managed |
|---|---|
| Heavy customisation (custom extensions, kernel tuning) | You don't want to wake up at 3am for a failed replica |
| Compliance restricts cloud usage | You'd rather pay engineers for product, not for ops |
| Cost at very large scale (100s of TB) | You want one-click multi-AZ HA |
| Vendor lock-in concerns | You want point-in-time recovery for free |
For 95% of teams, managed wins. The remaining 5% generally know who they are.
Practical Migration Path
- Start with managed Postgres on your cloud (RDS/Cloud SQL/Azure DB)
- Add read replicas when reads dominate
- Add a Redis cache for hot read paths
- Move to Aurora / AlloyDB / Spanner only when you've outgrown a single primary
- Sync analytics into BigQuery / Redshift / Snowflake
Don't pre-optimise. Most products never need step 4.