Managed Databases
Beginner 13 min read Managed Databases

Relational Managed Databases

SQL engines, operated for you

Managed relational databases (RDS, Azure SQL, Cloud SQL) run PostgreSQL/MySQL/SQL Server for you: automated backups, patches, HA and storage scaling, so the team owns schema and queries — not the operating system.

RDSrelationalPostgreSQLMySQLmanaged databaseAzure SQLCloud SQL
Prerequisites: Cloud Service Models
Before we start

What you will learn

  • Explain what 'managed' removes from your operational burden
  • Compare RDS, Azure SQL and Cloud SQL offerings
  • Choose engine vs fleet per workload
In 60 seconds

You provision an engine (Postgres/MySQL/SQL Server), a size, storage and a network. The provider runs the server, backups, patching, replicas and failsafes — you write SQL and design schemas.

Introduction

What is this?

AWS RDS (Aurora, MySQL, Postgres, MariaDB, Oracle, SQL Server) with multi-AZ deployments; Azure SQL Database (single DB, elastic pools, managed instance) and Azure Database for PostgreSQL/MySQL; GCP Cloud SQL (MySQL/Postgres/SQL Server) with high-availability configs. Managed layers: automated backups + PITR, automatic minor patching, storage auto-scaling, encryption, and read replicas via a button.

Motivation

Why do you need it?

  • Removes patching, backups and fail-over from the engineering backlog.
  • Storage auto-scaling prevents 'disk full' outages.
  • HA (multi-AZ/availability) is built-in rather than DIY-tested.
  • The team writes SQL, not systemd units.
Think about it

Mental model

Imagine

A restaurant with a kitchen brigade vs cooking at home

Think of

Managed relational databases

You write the menu (schema/queries); the brigade (provider) does dishwashing (patches), inventory (backups) and fire drill (failover). You stop worrying about the kitchen catching fire.

Mechanics

How it works

  • You pick engine + version + instance size + storage class + network (VPC/subnet, security group).
  • The provider creates a primary node and optional synchronous standby in another AZ.
  • Automated backups run to object storage with point-in-time recovery (usually 7-35 days).
  • Maintenance windows apply minor patches; major upgrades need a manual, tested step.
  • Read replicas copy asynchronously for scale-out reads and failover candidates.

Managed DB topology.

Primary
Storage
Backups
Read replicas
Failover
Hands-on

Examples

Provision a managed database

Provision a managed database
# AWS RDS PostgreSQL
aws rds create-db-instance --db-instance-identifier app-db \
  --db-instance-class db.t3.medium --engine postgres \
  --allocated-storage 100 --master-username appuser \
  --master-user-password 'ChangeMe!9' --multi-az
# Azure SQL Database
az sql db create -g app-rg -s app-sql --name appdb \
  --edition GeneralPurpose --capacity 2 --compute-model Serverless
# GCP Cloud SQL
gcloud sql instances create app-db --database-version=POSTGRES_14 \
  --tier=db-custom-2-4096 --region=us-central1

All three: engine, size, storage, credentials — then the provider operates it.

Real world

In production

  • An e-commerce backend runs Aurora PostgreSQL with auto-pause scaling and a read replica for reporting.
  • Azure SQL elastic pool sizes shared serverless capacity for a suite of SaaS tenants.
  • Cloud SQL serves a mobile backend with automated backups and a failover replica in another zone.
Guidelines

Best practices

  • Set parameter groups/tuning deliberately; don't rely on defaults for prod.
  • Prefer small instances + read replicas over one huge instance.
  • Enable automated backups and PITR; set a sensible retention.
  • Keep connections pooled and bounded; use managed proxy/sidecar for migrations.
Watch out

Common mistakes

  • Treating a managed DB as a free reign: the server is gone, but capacity planning isn't.
  • Running migrations against prod serverless DB with auto-pause (the cold-start surprise).
  • Ignoring maintenance windows: minor upgrade downtime hits at 3am unexpectedly.
  • Defaulting params that force huge memory/connections mismatched to instance size.
Root cause analysis

Common issues

Error
Instance status 'storage-full'
Root cause

Storage auto-scaling threshold or quota reached

Fix

Increase allocated storage or data retention (purge/archive tables) before the freeze.

Error
Long failover during maintenance
Root cause

Multi-AZ not enabled or replica lag

Fix

Enable multi-AZ/HA; test failover drills against RTO.

When things break

Debugging tips

  • Slow query: check RDS Postgres/SQL insights / query store first — explain is fast.
  • Storage auto-scaled? Confirm the free-space threshold alarms exist.
  • Failover happened? Read the failover event history and replica promotion timing.
  • Connection churn: enable connection pools (PgBouncer/Azure connection pooling) and set max_connections.
Interviews

Interview checkpoint

Practice

Hands-on lab

Provision, Tune and Query a Managed Database
30 min · beginner
In progress
Objectives
  • Provision a small managed database with a chosen engine
  • Connect, load data, and enable PITR
  • Point-in-time restore a dropped table

Provision, Tune and Query a Managed Database

30 min · beginner

0/4 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/1
1

Which is typically still the engineer's job on a managed database?

Go deeper

Official documentation

AWS — Amazon RDS
docs
Azure — SQL Database
docs
GCP — Cloud SQL
docs