Cloud-Native Databases: From RDS to Serverless – Making the Right Choice
TL;DR Managed Databases (RDS, Cloud SQL) eliminate 80% of operational overhead compared to self-hosted solutions. Serverless Databases (Aurora Serverless, Neon, PlanetScale) scale automatically – all the way down to zero. NewSQL databases …
TL;DR
- Managed Databases (RDS, Cloud SQL) eliminate 80% of operational overhead compared to self-hosted solutions.
- Serverless Databases (Aurora Serverless, Neon, PlanetScale) scale automatically – all the way down to zero.
- NewSQL databases (CockroachDB, Spanner) deliver ACID transactions with horizontal scalability.
- The choice between SQL and NoSQL depends on access patterns, not data volume.
- Multi-region replication is essential for business-critical applications – but costs 2-3× more.
The cloud database landscape has radically changed. Today’s database selection is no longer a binary decision between SQL and NoSQL. Serverless databases, NewSQL, multi-model engines, and purpose-built databases offer an optimal solution for every access pattern. The challenge isn’t a lack of options – it’s choosing the right one.
Managed vs. Serverless: Two Levels of Abstraction
Managed Databases like Amazon RDS, Azure SQL Database, and Google Cloud SQL handle patching, backups, and failover. You choose the instance size and can scale manually or via auto-scaling. Operational overhead drops by around 80% compared to self-hosted, while retaining full control over configuration and performance tuning.
Serverless Databases take abstraction a step further: no instance selection, no capacity planning. Aurora Serverless v2, Neon (Serverless Postgres), and PlanetScale (Serverless MySQL) scale automatically – including scale-to-zero for development environments. You pay only for actual usage. For variable workloads and development setups, this is a game changer.
SQL, NoSQL, or NewSQL? The Decision Matrix
Relational databases (SQL) remain the standard for transactional workloads with complex relationships: e-commerce, ERP, financial systems. PostgreSQL and MySQL dominate, both available as managed services across all major hyperscalers.
NoSQL databases are ideal for specific access patterns: DynamoDB for key-value and simple queries with guaranteed latency. MongoDB Atlas for document-based workloads with flexible schemas. Redis for caching and session management. Cassandra/ScyllaDB for write-heavy workloads with extreme throughput.
NewSQL databases combine ACID transactions with horizontal scaling: Google Spanner offers global consistency across continents. CockroachDB delivers PostgreSQL compatibility with automatic sharding. TiDB scales MySQL horizontally. The target audience: applications that need both transactional integrity and massive scalability.
Purpose-Built Databases: The Right Tool for Every Job
AWS has long advocated for “purpose-built databases” – the optimal engine for every access pattern. The principle holds: a graph database (Neptune, Neo4j) models relationship networks more naturally than a SQL join across five tables. A time-series database (TimescaleDB, InfluxDB) compresses and aggregates IoT data more efficiently than PostgreSQL.
The downside: each additional database engine increases operational complexity. Recommendation: start with PostgreSQL (covers 80% of use cases) and introduce a specialized engine only when PostgreSQL demonstrably hits its limits.
Multi-Region Replication: Availability Comes at a Price
For business-critical applications, single-region deployment is a risk: region-wide outages are rare – but they do happen. Multi-region replication distributes data across geographic regions and enables failover within seconds.
Costs are significant: cross-region data transfer, compute across multiple regions, and the complexity of conflict resolution in multi-writer setups. For read-heavy workloads, read replicas in other regions offer a pragmatic middle ground – cheaper and less complex than full multi-region active-active configurations.
Migration: The Safe Path to Cloud Databases
Database migrations are the riskiest phase of any cloud project. AWS DMS, Azure Database Migration Service, and GCP Database Migration Service offer managed migration with minimal downtime. The pattern: continuous replication from the source system, cutover during a short maintenance window, and a fallback option available for 48-72 hours.
Critical success factors: verify schema compatibility upfront (especially when switching engines), conduct performance tests under production-like load, and have a rollback plan executable within 30 minutes.
Frequently Asked Questions
Which cloud database is best for startups?
PostgreSQL on a managed service (Neon Serverless or Supabase for fast onboarding, RDS/Cloud SQL for greater control). PostgreSQL handles relational and JSON workloads, has a massive community, and scales well under significant load. Only evaluate specialized engines when facing specific demands (e.g., < 5ms latency globally, > 100k writes/second).
How much more expensive is a managed database vs. self-hosted?
Managed services cost 20-40% more than the raw compute and storage costs of a self-hosted instance. This premium is more than offset by reduced operational effort (patching, backups, monitoring, failover). A DBA costs 80-120k €/year – managed services for a typical production database range from 300-1,000 €/month.
When does a serverless database make sense?
Serverless databases are ideal for variable workloads (dev/test environments, SaaS with unpredictable traffic) and scale-to-zero scenarios. For stable, high-load workloads, provisioned instances are more cost-effective, as serverless pricing becomes more expensive than reserved instances under sustained load.
Can you use PostgreSQL for everything?
Almost. PostgreSQL supports relational data, JSON (JSONB), full-text search, geospatial data (PostGIS), time series (via TimescaleDB extension), and even vector search (pgvector). It’s sufficient for 80% of application use cases. Limitations appear under extreme latency requirements (< 1ms), very high write throughput (> 50k writes/sec), and globally consistent replication.
How do you minimize downtime during a database migration?
Through continuous replication: the source database is replicated to the target cloud environment in real time. Once replication is synchronized (lag < 1 second), the cutover happens within a short maintenance window (typically 5-30 minutes). AWS DMS, Azure DMS, and GCP DMS automate this process.
Header Image Source: Pexels / Brett Sayles
