A managed database is a vendor-run engine (Postgres, MySQL, SQL Server, …) or a managed NoSQL store (DynamoDB-style, Firestore-style) where patching, backups, failover, and read replicas are mostly their job. You choose instance size, region, and access rules — then connect with a connection string or SDK.
Relational (RDS, Cloud SQL, Aurora): tables, joins, transactions (ACID) — still the default for business logic and reporting. Key-value / document / wide-column (DynamoDB, Cosmos, Bigtable-shaped): scale-out patterns, different consistency models, great for high-throughput narrow access paths — harder ad-hoc querying unless you add search indexes.
The cloud provider secures the platform; you secure credentials, schema, and who can run queries. Leaked connection strings in email, tickets, or shared folders are a classic failure mode — use secret managers and IAM database auth where offered.
Coffee’s own managed-db sidecar (SQLite under vault) is the homelab echo of “a database as a service on your LAN” — different scale, same separate process + API idea as in the Coffee Server course.
DATABASE1-CORE.html presents a “Managed Clusters” style console: instances, metrics chrome, data grid — useful for learning what operators stare at in RDS-like UIs. DATABASE2-EDITAUTOSAVE.html leans into row editing UX. Neither replaces learning SQL or your vendor’s backup/restore drill.