Cloud and Serverless Databases
A cloud database guide for non-developers: what managed and serverless really mean, plus the shared responsibility model, cloud costs, and data residency.
Outsourcing operations does not make responsibility disappear
Part 11 of 12 in "Databases for Non-Developers". This part looks at the gap between the expectation that "moving to the cloud solves everything" and the reality.
In the past, it was common for a company to buy servers, install databases, and physically replace broken hardware itself. Today you can spin up a database in the cloud with just a few choices, and the provider takes over parts of backups, updates, and failover.
But it would be a mistake to assume that "it's in the cloud, so it's safe" or "it's serverless, so there are no servers."
What is a managed database?
A managed database is a service where the cloud provider handles parts of the operational work: installation, updates, backups, monitoring, and replication. Just as we buy electricity from a power plant instead of running our own generator, the idea is to consume database operations as a service. The team can focus more on the data model and the application than on server administration.
The benefits are clear.
- Fast to get started
- Less repetitive operational burden
- Backup and disaster response features are relatively easy to configure
- Easy to scale capacity up or down with usage
But nothing is configured perfectly on its own. You may still need to decide backup retention, recovery regions, access permissions, how exposed the network is, encryption keys, logging, and cost alerts. The "public cloud storage bucket" incident from Part 10 happened not because cloud security is weak, but because no one checked the settings.
Serverless does not mean there are no servers
A serverless database reduces the burden of directly managing the size and number of servers, and automatically adjusts resources based on requests or usage. The actual servers are still running somewhere. They are just hidden behind the service.
It can be a good fit for new services with erratic usage. On the other hand, depending on the usage pattern, costs can be hard to predict, a system that has been idle can be slow to respond when it wakes up, and each product has its own limits.
Shared responsibility: who handles what?
The cloud provider secures the buildings, the hardware, the underlying services, and the management features. The customer organization still bears responsibility for things like:
- What data to store
- Who is allowed access
- Whether the application checks permissions properly
- Whether the collection and use of personal data is appropriate
- Whether backup and recovery targets fit the business
- Whether external exposure and network settings are correct
- Monitoring for unusual activity and responding to incidents
The boundary shifts depending on the service, so you need to check the contract and the responsibility model. "The cloud provider manages it" is not an explanation that holds up for the customer after an incident.
Costs go beyond the monthly fee
Cloud costs can include not just storage but also request counts, processing capacity, backups, replication, logs, transfers to other regions, and data sent out of the platform. When a small unit price meets large usage, the total can be far beyond what you expected. A sudden jump in the monthly bill — the so-called "cloud bill shock" — is hardly rare.
Even as a non-developer, you can ask for:
- Cost estimates for three usage scenarios: normal, growth, and spike
- Budget alerts and usage limits
- The biggest cost items and how to reduce them
- A comparison between disaster-preparedness costs and the risks accepted without them
- The cost of leaving the service and exporting your data
Where your data lives matters too
In the cloud, you can choose the region where data is stored. A region close to your users can help with speed. But depending on laws, customer contracts, disaster recovery plans, and subcontracting chains of outside vendors, you need to check where data is stored and replicated.
"We store it in a US region" does not explain every place the data is processed. You also need to look at whether it moves elsewhere through logs, backups, support processes, and analytics tools. Especially when personal data is involved, cross-border data transfers often carry separate legal requirements.
Real recovery matters more than an "automatic backup" toggle
Even if the admin screen says "automatic backups enabled," these questions remain:
- How far back can we restore — minutes or hours?
- How long are backups kept?
- If the operations account is compromised, are the backups protected?
- Can we recover from an outage in another region?
- Does the actual recovery time fit our business target (RTO from Part 5)?
- Are recovery drill results documented?
The existence of a feature is not the same as being prepared. That gap does not disappear when you move to the cloud.
Key takeaways Managed and serverless databases reduce the operational burden, but they do not remove responsibility. Access permissions, data use, configuration, recovery targets, costs, and data location are still judgments your organization must make. Confirm the actual settings and test results, not just the existence of automatic features.
Questions to ask in contract and design meetings
- Is the responsibility boundary between the provider and our organization documented?
- If the monthly bill suddenly jumps, who finds out, and when?
- In what format can we export our data to another service? (The exit strategy)
- How do we recover from a provider outage versus a compromised account?
- In which regions is the data actually stored, replicated, and processed — including logs and backups?
Next: how generative AI is changing databases — vector search, RAG, and what "good data" means in the AI era.
Series contents
- What Is a Database — and How Is It Different from a Spreadsheet?
- How Databases Keep Data Accurate
- What Kinds of Databases Are There?
- Databases, Data Warehouses, and Data Lakes
- Why Choosing the Right Database Matters
- Data Models and Data Quality
- What Is Data Governance?
- Less Personal Data, Only What You Need
- The Basics of Data Security
- Why Data Breaches Happen, and What to Do When One Does
- Cloud and Serverless Databases ← You are here
- Databases in the AI Era
About the Author

Jaehee Song
Enterprise data platform architect with 20+ years of experience building data systems for Fortune 500 companies. AI development educator who has taught vibe coding and AI development to hundreds of students. Founder of Seattle Partners, helping Korean technology startups navigate the US market.