# Exercise 2: Database on Kubernetes or Managed Service?

`PetPal` runs on EKS in eu-west-1 (3 AZs). The platform team proposes moving the 600 GB PostgreSQL database from RDS into the cluster using the **CloudNativePG** operator "to save money and keep everything in one place".

## Deliverables

1. **Comparison table** (RDS Multi-AZ vs CloudNativePG on EKS with EBS gp3) across: availability/failover, backups and PITR, upgrades, performance tuning, cost (instances + storage + people), security/compliance, operational skills required.
2. **Failure scenarios**: for each — AZ outage, node termination, EBS volume degradation, accidental `kubectl delete ns` — describe what happens and the recovery time in both options.
3. **If they proceed**: the Kubernetes design — StorageClass settings, cluster of 3 instances spread across AZs, PDB, anti-affinity, resource requests/limits, backups to S3 (base backups + WAL archiving), monitoring, and how app Pods connect (read/write vs read-only Services).
4. **Data protection**: `reclaimPolicy`, deletion protection, Velero/snapshots, and RBAC preventing accidental deletion.
5. **Recommendation** with conditions under which you'd change your mind.

## Requirements Checklist

- [ ] Table covers all dimensions with honest trade-offs (operator automates failover/backups; RDS removes the ops burden; cost includes engineering time).
- [ ] Notes that EBS volumes are zonal: after an AZ outage, a replica in another AZ must be promoted (operator handles it) — the old Pod can't move with its disk.
- [ ] Design: `WaitForFirstConsumer`, `Retain`, encryption, `allowVolumeExpansion`; 3 instances with zone spread; PDB; WAL archive to S3 with PITR; Prometheus metrics/alerts.
- [ ] `kubectl delete ns` mitigation: Retain policy, backups outside the cluster, restricted RBAC, admission policy/finalizers.
- [ ] A clear recommendation with criteria (team skills, scale, cost, compliance).