Managed databases in the cloud

A managed cloud database handles routine infrastructure and database maintenance. Your team still owns the data model, queries, access decisions and recovery requirements. Start with the workload, then verify exactly what the proposed service and configuration manage.

Pros and cons of managed databases in Australia

Describe the workload

An order system may need transactions and dependable writes. Reporting may involve large scans and aggregations. A catalogue with varied attributes may suit a document model.

Write down the data and relationships, important reads and writes, peak demand, growth, required access, acceptable downtime and acceptable data loss. Use measured traffic where available; label forecasts as assumptions.

Check the division of work

Amazon RDS supports several relational engines and manages tasks such as patching and backups. Cloud SQL provides managed PostgreSQL, MySQL and SQL Server. Neither service decides how your application should structure data or tune queries. Features also vary by engine, version and edition.

Assign an owner for schema changes, indexes, permissions, retention, backup settings and restore approval. Check the required engine features on the exact configuration before choosing it.

Managed operation still leaves configuration choices to your team. For Amazon RDS, compare automated backups with manually created snapshots, and decide who can create or restore them; AWS also provides IAM controls for defining users and permissions.

For Cloud SQL for PostgreSQL, confirm that the chosen version and edition provide the capabilities your application needs. Google Cloud documents multiple PostgreSQL versions and editions, so verify the specific combination rather than relying on general product compatibility.

Shortlist by database type

This is a shortlist, not a performance ranking. Test representative queries on the intended tier and region. Account for the application changes required by a different data model.

For Australian workloads, check where the instance, backups and replicas will be stored. Cloud SQL instances are available in the Americas, EU, Asia and Australia, so verify the specific location for your deployment against your organisation's requirements.

A managed service's connection method can affect application fit as much as its engine. Check the exact supported methods for your shortlisted service before deciding.

Managed database services: key features comparison

Make recovery part of selection

Set a recovery time objective for the longest acceptable interruption and a recovery point objective for the maximum acceptable age of recovered data. Check the service's available recovery window and test whether a restored copy supports an application action within those limits.

Point-in-time recovery for Amazon RDS DB instances creates a new DB instance; reconnecting and validating the application remain operational steps. High availability does not replace an earlier recovery point after a damaging write reaches live copies.

Cloud SQL for PostgreSQL point-in-time recovery can restore a live or deleted primary instance, but it always creates a new instance rather than replacing an existing one. Plan how the application will be pointed to the recovered instance and how its data will be checked before normal use resumes.

Check security and connection fit

Amazon RDS supports IBM Db2, MariaDB, Microsoft SQL Server, MySQL, Oracle Database and PostgreSQL. Cloud SQL for PostgreSQL supports the standard PostgreSQL client-server protocol and standard PostgreSQL connectors, but it does not support every feature of locally hosted PostgreSQL.

Check how applications will authenticate and connect. Amazon RDS supports access control through AWS Identity and Access Management (IAM), as well as database permissions and virtual private cloud placement. Cloud SQL supports secure external connections through the Cloud SQL Auth Proxy or SSL/TLS.

Review the exact PostgreSQL extensions and procedural languages your application requires. Cloud SQL supports PL/pgSQL and many PostgreSQL extensions, but its supported-extension list is the deciding reference for a particular requirement.

Compare recovery options

Check whether the service offers both automated and on-demand backups, and whether your team can create manual snapshots where needed. Amazon RDS supports automated backups and manual backup snapshots; Cloud SQL for PostgreSQL supports automated and on-demand backups, as well as instance cloning.

For Amazon RDS point-in-time recovery, transaction logs are uploaded to Amazon S3 every five minutes, and restoration is available within the configured backup retention period. Check the latest restorable time rather than assuming that a desired recovery point is available.

A restored Amazon RDS instance can be available while its storage continues loading data blocks in the background, so performance may not reach its full level until initialisation completes. Include validation and any required performance checks in the recovery test.

Check capacity and cost

Add the maximum connections from application copies, workers and other clients, then allow room for operations. Compare the total with the usable limit of the exact tier and test connection waits alongside query latency. Connection limits vary by service and configuration.

Separate running capacity, storage, backups, extra copies and data transfer in the cost estimate. BigQuery offers on-demand pricing that charges per TiB for queries and capacity-based pricing for the compute resources (slots) used to process queries.

Key performance and cost considerations