3 min Reading Time<\/p>\n
The cloud database landscape has radically changed. Today\u2019s 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\u2019t a lack of options – it\u2019s choosing the right one.<\/strong><\/p>\n Managed Databases<\/strong> 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.<\/p>\n Serverless Databases<\/strong> 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.<\/p>\n Relational databases (SQL)<\/strong> 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.<\/p>\n NoSQL databases<\/strong> 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.<\/p>\n NewSQL databases<\/strong> 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.<\/p>\n AWS has long advocated for \u201cpurpose-built databases\u201d – 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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).<\/p>\n<\/details>\n 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 \u20ac\/year – managed services for a typical production database range from 300-1,000 \u20ac\/month.<\/p>\n<\/details>\nManaged vs. Serverless: Two Levels of Abstraction<\/h2>\n
SQL, NoSQL, or NewSQL? The Decision Matrix<\/h2>\n
Purpose-Built Databases: The Right Tool for Every Job<\/h2>\n
Multi-Region Replication: Availability Comes at a Price<\/h2>\n
Migration: The Safe Path to Cloud Databases<\/h2>\n
Frequently Asked Questions<\/h2>\n
Which cloud database is best for startups?<\/strong><\/summary>\n
How much more expensive is a managed database vs. self-hosted?<\/strong><\/summary>\n