DBaaS: managed engines, plans, zone scoping and access control
The DBaaS domain tests managed-service reasoning: which engines Exoscale offers, how a service is scoped and reached, and what you still own once backups and patching are handled for you.
Engines and plans
Exoscale's managed catalogue covers relational (PostgreSQL, MySQL), streaming (Kafka), search and analytics (OpenSearch), observability (Grafana) and a Redis-compatible key-value store (Valkey). Services are created from plans that bundle vCPU, RAM and disk; the plan caps how much data and how many connections you can realistically serve. Size by RAM for working sets and connection overhead, not by raw disk alone.
What is managed, what stays yours
Managed means engine patching, backups and host health. It does not mean superuser access or arbitrary kernel modules. You get database users and connection URIs, TLS in transit, and a source-address filter controlling who may connect. Reach the service over a private network where possible; expose it publicly only with a tight source list.
Zone and resilience
A DBaaS service is created in one zone, and its backups live with it unless you export them elsewhere. There is no free cross-zone synchronous replication: if the requirement is zone-level survival, you build it - a replica or logical replication target in another zone, a tested promotion runbook, and backups copied out.
Worked example
An application needs PostgreSQL for 200 GB of data with a 40 GB hot working set and 300 concurrent connections. Reasoning: pick a plan whose RAM comfortably exceeds the working set plus per-connection overhead, not one that merely fits 200 GB on disk. Attach the app tier and the service to the same private network so traffic stays on the private fabric, set the source filter to the app subnet, enable automated backups, and schedule a monthly restore into a scratch service to prove the backup is usable. The cross-zone replica stays a separate, documented project.
Traps
Assuming managed equals multi-zone high availability; exhausting connection limits before CPU; opening the service to 0.0.0.0/0 "temporarily"; forgetting that a plan change may need a maintenance window; and treating an untested backup as a backup.