managed-database-selection

Start by writing down the access pattern: read/write ratio, query shapes, item size, data volume, consistency needs, and latency budget. The pattern selects the database family, and the specific managed engine is a follow-on decision about operations and cost.

Default to relational because it lets you defer query design through joins and indexes. Move to NoSQL only when a concrete pattern forces it, such as write volume beyond one primary, key-oriented access, or data shapes relational serves awkwardly.

A read replica offloads read traffic but is not a backup or failover. A multi-AZ standby provides automatic failover for high availability. Snapshots and point-in-time recovery provide backups. Each must be provisioned for its own purpose.

Asynchronous replication lag is real and unbounded under load, so a replica may not have your latest write. Route read-after-write flows to the primary or use an explicit session-consistency guarantee instead of assuming the replica has caught up.

Use serverless or on-demand capacity for spiky, unpredictable, or development workloads where provisioning for peak wastes money. Steady, predictable traffic is cheapest on a right-sized provisioned instance.

Strong global consistency requires consensus across regions, which adds write latency because a write must reach a quorum before committing. Only a small set of engines like Spanner offer it, so decide the consistency requirement explicitly up front.