Cloud Databases

A cloud database stores and serves application data through cloud infrastructure. You provision it through an API or console. You reach it over a network.

The main benefit is not a new data model. It is a different operating model. A managed service can handle hardware replacement, software maintenance, backups, monitoring hooks, and failover mechanisms. You still own the data model, queries, access rules, recovery objectives, and application behavior.

That division matters. A managed database reduces infrastructure work. It does not make database design, security, performance, or recovery automatic.

The three layers of the decision

Start with three separate questions.

What data model fits the workload? Choose relational, document, key-value, graph, time-series, or another model from the required access patterns.
How much control do you need? Choose a self-managed engine on cloud compute, a managed engine, or a more abstract cloud-native service.
What operating outcome must you meet? Define latency, throughput, consistency, availability, recovery, security, residency, and cost requirements.

Do not begin with a provider logo. Begin with the reads, writes, transactions, and failure outcomes your application needs.

Common data models

Relational

A relational database organizes data into tables with a defined schema. It supports constraints, joins, and transactions across related records. It fits order processing, billing, inventory, and other work that depends on relational integrity.

Document

A document database stores records as documents, often in a JSON-like form. One document can hold a complete application aggregate. It fits catalogs, content, and profiles whose fields evolve over time.

Key-value

A key-value database retrieves a value through a unique key. It favors fast, predictable point operations over flexible queries. It fits sessions, preferences, feature flags, and known lookup patterns.

Graph and time-series

A graph database represents entities as nodes and relationships as edges. It fits relationship traversal, such as fraud links or supply-chain dependencies.

A time-series database organizes timestamped values for ingestion and time-window analysis. It fits telemetry, monitoring, and sensor data.

One production system can use more than one model. Each additional database adds another schema, security policy, recovery path, monitor, and failure mode. Add one only when a distinct access pattern justifies the operational cost.

Managed does not mean identical

Managed relational services usually preserve a familiar engine and connection model. This can reduce migration work. Service limits, supported extensions, maintenance behavior, and administrative access can still differ from a self-managed deployment.

Cloud-native distributed databases can add automatic partitioning, multi-region replication, or elastic capacity. These features change design choices. A partition key can determine where data lives and which transactions stay local. A consistency setting can change what a read is allowed to observe.

Compatibility has several layers:

Protocol compatibility: Can the existing driver connect?
SQL or API compatibility: Do queries and data types behave as expected?
Operational compatibility: Are backup, monitoring, maintenance, and failover controls equivalent?
Semantic compatibility: Do transactions and consistency guarantees preserve application correctness?

A familiar wire protocol does not prove full compatibility.

Scale starts with access patterns

Vertical scaling gives one database more compute, memory, or storage. Horizontal scaling distributes data or traffic across more resources.

Read replicas can add read capacity, but an asynchronous replica can return older data. A high-availability standby serves a different purpose. It exists to take over after failure and might not serve application reads.

Partitioning divides data by a partition key. A good key spreads storage and traffic while supporting frequent queries. A poor key creates a hot partition or forces expensive cross-partition work.

Measure before scaling. Track application latency, errors, connections, transaction rate, query load, storage growth, replica lag, and throttling. A larger database does not repair an inefficient query or a mismatched data model.

Consistency is an application requirement

Consistency describes which writes a read may observe and how concurrent operations appear to execute. Stronger guarantees can simplify application reasoning. Weaker or scoped guarantees can reduce coordination for some distributed workloads.

Ask concrete questions:

Must a user read a write immediately?
Must related records change in one transaction?
Can a report tolerate older replica data?
Can two regions accept writes at the same time?
What happens when a network path fails?

Do not label a workload "eventually consistent" without tracing the user-visible result of stale or reordered data.

Availability, backups, and recovery

Replication keeps additional copies that can support availability or read scaling. A backup preserves a recoverable state with a separate lifecycle. One does not replace the other.

Define two recovery objectives before choosing a topology:

Recovery time objective: the maximum acceptable outage duration.
Recovery point objective: the maximum acceptable period of data loss after a major incident.

Smaller objectives usually require more replicas, automation, testing, and cost. Test restores and failovers. A configured backup is evidence of intent. A successful restore is evidence of recovery.

Security remains shared

The provider protects the managed service infrastructure. You still control application identities, database permissions, network exposure, data classification, encryption choices, key access, logs, and retention.

Use private network paths when the service and workload support them. Grant the least privilege needed for management and data access. Protect data in transit and at rest. Keep credentials outside application code. Record where replicas, backups, and logs store regulated data.

Treat encryption keys as part of availability. Data that cannot be decrypted is unavailable, even when every replica is healthy.

Cost follows architecture

Cloud database cost can include compute, memory, storage, requests, input and output operations, backups, replicas, licenses, and network transfer. Region and availability choices also affect the bill.

Serverless or autoscaling capacity can match variable demand. Provisioned capacity can fit stable demand. Neither is automatically cheaper. Test with representative data and traffic. Include recovery copies and engineering work in the comparison.

Migration is a controlled change

A database migration moves data and then switches clients to a target. An engine change can also require schema, query, procedure, and application changes.

Use an ordered migration path:

Inventory data, dependencies, queries, and operational requirements.
Choose a target from workload evidence.
Convert and test schema or application behavior when needed.
Load existing data and replicate ongoing changes when the downtime target requires it.
Validate counts, critical records, constraints, queries, and performance.
Rehearse cutover, monitoring, and rollback conditions.
Switch traffic, verify behavior, and retire the source only after acceptance.

New writes complicate rollback after cutover. Plan how those writes return to the old environment or move forward to a corrected target.

When a cloud database is a poor fit

A managed cloud database can be the wrong choice when you need unsupported engine features, unrestricted host access, a disconnected environment, or a cost profile that favors existing infrastructure. It can also be wrong when network latency makes remote access unacceptable.

Avoid a specialized database when a familiar relational engine already meets the workload. Avoid several databases when one can satisfy the access patterns without harmful compromise.

Your path forward

First, learn the data models and transaction needs. Next, define service objectives and security boundaries. Then compare compatible services and prototype the hard paths. Finally, rehearse failure, restore, migration, and cost scenarios with representative load.

The durable skill is not memorizing a provider catalog. It is turning workload evidence into a database decision you can test and explain.