What happens when a team moves a database into the cloud but forgets who is responsible for backups? Usually nothing, until the night it matters. That gap between what the provider handles and what the customer still owns is where most cloud database projects succeed or fail. This guide walks through the decisions that actually shape an implementation: picking the right service model, designing for residency and encryption, setting recovery targets, and cutting over without drama. (How to read a cloud region announcement)
Start With the Service Model, Not the Vendor
Before comparing engines, it helps to fix the vocabulary. The standard definitions come from NIST SP 800-145, which lays out five essential characteristics of cloud computing, three service models (IaaS, PaaS, SaaS), and four deployment models (private, community, public, hybrid). If you want the canonical wording, the NIST definition of cloud computing is worth reading in full, because it settles arguments that otherwise run for weeks.
On top of that vocabulary, cloud databases are usually grouped three ways:
| Model | What the provider runs | What you still own | Typical fit |
|---|---|---|---|
| Fully managed (DBaaS) | Engine, patching, backups, failover | Schema, queries, access, data | Most business applications |
| Serverless / autoscaling | Capacity provisioning and scaling | Query design, cost control | Spiky or unpredictable load |
| Self-managed on VMs | Network, hypervisor, hardware | Everything above the OS | Legacy engines, unusual tuning |
The boundaries are blurry, and vendors use the terms inconsistently. Treat any taxonomy as descriptive rather than standardised. A “serverless” database from one provider may behave nothing like another’s.
The practical tip: write down which model you are choosing and why, in one paragraph, before any proof of concept starts. Teams that skip this step end up in month three arguing about whether patching is included.
The Shared Responsibility Split Decides Your To-Do List
Every major provider publishes a shared-responsibility model. The provider secures the underlying infrastructure; the customer remains responsible for data, access management, and configuration. That sounds simple, and it is where most incidents originate.
In practice, the split shifts depending on the service. On IaaS, you patch the database engine. On a fully managed service, the provider patches it, but you still control who can connect, which network paths are open, and whether encryption keys are customer-managed or provider-managed. Configuration errors, not provider outages, are the dominant failure mode.
What actually works:
- Turn on the provider’s audit logging before the first application connects, not after.
- Restrict network access to known CIDR ranges from day one; retrofitting later breaks things.
- Decide key custody early. Most providers offer customer-managed keys through a key management service, but rotation duties and recovery paths differ. NIST’s key management recommendation (SP 800-57) is the reference most security teams use when writing that policy.
- Map every item on the provider’s responsibility list to a named owner on your side.
Common mistake: assuming a managed service means “no database administration.” It means less engine administration. Access design, query performance, and cost control stay firmly with you.
Residency, Transfers, and the Region You Actually Need
Region selection is a legal decision as much as a latency one. Under the GDPR, transfers of personal data outside the EEA are restricted, and the Schrems II judgment of July 2020 invalidated the EU–US Privacy Shield. A successor adequacy arrangement, the EU–US Data Privacy Framework, was adopted in July 2023, but adequacy reviews and litigation continue. Anyone designing replication across regions should read the GDPR text itself rather than a vendor summary of it.
The engineering consequence is concrete. If your primary sits in Frankfurt and your read replica sits in Virginia, you have created a cross-border transfer that needs a legal basis; a latency budget alone does not cover it. Replication topology is a compliance artefact.
A few habits that save rework:
- Draw the data flow before choosing regions. Include backups, snapshots, log shipping, and support-access paths. Support engineers logging in from another country can be a transfer event.
- Keep the region list short. Every additional region multiplies the transfer analysis.
- When a provider announces a new region, read the announcement for what it does not say: which services launch on day one, and whether the region sits inside your compliance boundary. A structured approach helps here, and this guide to reading a cloud region announcement covers what to check.
- Revisit annually. Adequacy decisions change, and so do your data flows.
Encryption and Key Management Without Guesswork
Encryption at rest and in transit is table stakes, and the standards are stable. AES-256, standardised in FIPS 197, remains the default for data at rest; TLS 1.2 and 1.3, defined in RFC 5246 and RFC 8446, cover data in transit. Providers enable both by default on most managed database services.
The interesting decisions sit above the algorithm:
- Who holds the keys? Provider-managed keys are simpler and usually fine for low-sensitivity data. Customer-managed keys give you a revocation lever, at the cost of an operational dependency: lose access to the key service and the database is unreadable.
- How often do keys rotate, and who tests the rotation? A rotation policy nobody has exercised is a hypothesis, not a control.
- Are backups encrypted with the same key? Sometimes not, and that surprises people during recovery.
For teams writing a formal policy, NIST SP 800-57 Part 1 is the reference document most auditors expect you to have consulted. It covers key lifecycle, cryptoperiods, and the division of duties around key custody.
Recovery Targets: Read the SLA, Not the Marketing Page
Two numbers anchor every recovery plan: the Recovery Point Objective (RPO), which is how much data you can afford to lose, and the Recovery Time Objective (RTO), which is how long you can be down. Both are defined in business continuity standards and in NIST’s contingency planning guide (SP 800-34 Rev. 1), which remains the most practical free method for deriving them from business impact rather than from gut feel.
Where cloud implementations go wrong is in translating those targets into service configuration. A provider’s SLA typically offers service credits, not guarantees. A 99.95% uptime commitment compensates you financially for downtime; it does not prevent it. Read the exclusions carefully, since planned maintenance and certain failure modes are often carved out.
Then test. A recovery drill for a managed database should cover restoring to a point in time; restoring last night’s snapshot alone is insufficient, and the drill should be timed. The first drill usually reveals that the documented restore procedure is missing a step, such as re-granting application roles after a restore to a new instance. Building a repeatable recovery drill for a managed database is worth doing before go-live rather than after the first incident.
Migration Patterns That Survive Contact With Reality
For moving an existing database into the cloud, two approaches dominate. Lift-and-shift moves the database onto managed infrastructure with minimal change. Incremental replacement, often called the strangler fig pattern after Martin Fowler’s description of wrapping legacy functionality until the old system can be retired, moves workloads piece by piece. (9481.org)
For heterogeneous migrations, where the source and target engines differ, schema and stored-procedure conversion is usually the largest single effort. Budget for it explicitly. Automated conversion tools get you most of the way; the remainder is hand work on procedural code, date handling, and collation differences.
A practical sequence that tends to work:
- Inventory what you have before choosing a target. Schema, data volumes, dependencies, and integration points all shape the plan, and a pre-migration inventory checklist prevents surprises.
- Migrate a non-critical workload first. Learn the tooling on something whose failure will not page anyone.
- Run source and target in parallel with replication, then compare row counts and checksums before cutover.
- Cut over behind a feature flag or connection-string switch so rollback is a configuration change, not a restore.
Where the workload spans teams or environments, splitting it across separate cloud accounts with clear boundaries reduces blast radius and simplifies cost attribution. The trade-offs are real, though, and this piece on when to split workloads across cloud accounts sets them out.
Cost, Performance, and the Benchmark Trap
Serverless and autoscaling databases bill per request or per capacity unit. That model is excellent for spiky workloads and uncomfortable for finance teams, because the bill tracks traffic rather than a fixed reservation. Two controls help: per-query cost visibility, and hard budget alerts set well below the monthly ceiling.
Published benchmarks deserve scepticism. Many are vendor-sponsored, and no neutral, comprehensive benchmark of cloud databases exists that anyone can cite confidently. Treat vendor numbers as directional and run your own test with your own query mix. A workload that is read-heavy with small rows behaves nothing like the analytics queries in a launch blog post.
Tracking transfer costs separately is also worth the effort, since data egress between regions or to the internet is frequently the line item nobody forecast. A clearer way to track cloud data transfer costs walks through the tagging approach.
Portability, Standards, and Lock-In
PostgreSQL and MySQL are available from essentially every major provider, which makes them the low-lock-in choice for most new workloads. Proprietary engines trade portability for managed features, and that trade is sometimes correct, particularly for globally distributed key-value access patterns. The SQL standard itself is ISO/IEC 9075, most recently revised in 2023, though every engine implements a dialect rather than the standard in full. (AWS Documentation)
The pragmatic position: choose the engine your team can operate, and keep schema migrations in version control so a future move is a project rather than an archaeology exercise. Teams that build a clear inventory of what runs where, and why, find later platform decisions much cheaper.
Compliance Evidence You Will Be Asked For
Two certifications come up in almost every procurement review: ISO/IEC 27001 for information security management, and SOC 2 under the AICPA Trust Services Criteria. Both are worth understanding before a customer asks. The important habit is to check the provider’s current certificate scope on its compliance page rather than trusting a summary slide, because scope varies by service and by region, and a certification that covers compute may not cover a newer database product.
Keep your own evidence too: configuration baselines, access reviews, restore test records, and key rotation logs. Auditors ask for proof of practice, not proof of intention.
Conclusion
A cloud database implementation is less about picking a product and more about drawing clean lines: which model you chose, who owns what under the shared-responsibility split, where data is allowed to travel, how keys are held, and how fast you can recover. Get those five things written down and tested, and the technology choice becomes the easy part. Start with the responsibility map, because everything else depends on it.
Frequently Asked Questions
What is the difference between DBaaS and a self-managed cloud database?
DBaaS means the provider runs the engine, patching, backups, and failover, while you own schema, queries, access, and data. Self-managed means you run the database on cloud virtual machines and own everything above the operating system, including patching and replication. DBaaS suits most business applications; self-managed suits legacy engines or unusual tuning needs.
Who is responsible for backups in a managed cloud database?
Usually both parties, in different ways. The provider typically runs automated backups and point-in-time recovery, but restoring, verifying, and testing those backups remains the customer’s job. A backup you have never restored is an assumption, so schedule a timed restore drill before go-live.
How do I choose a cloud region for a database holding personal data?
Start with the legal boundary, then optimise for latency. If the data is subject to GDPR, cross-border transfers need a lawful basis, and replication, backups, and support access all count as transfers. Shortlist regions inside your compliance boundary first, then pick the closest one that meets your latency target.
Do cloud providers guarantee database uptime?
No. Provider SLAs typically commit to a monthly uptime percentage and offer service credits if it is missed; they do not guarantee the service will stay up. Read the exclusions, which often cover planned maintenance and specific failure modes, and design your own redundancy around them.
How long does a cloud database migration usually take?
It depends mainly on heterogeneity. A lift-and-shift of a compatible engine can take weeks. A migration between different engines, with stored-procedure and schema conversion, usually takes months, because procedural code conversion is manual work. Migrating one non-critical workload first gives you a realistic estimate for the rest.
Is it worth paying for customer-managed encryption keys?
It depends on your threat model and regulatory obligations. Customer-managed keys give you a revocation lever and tighter audit trails, at the cost of an operational dependency on the key service. For low-sensitivity data, provider-managed keys are usually sufficient and simpler to operate.
