# Managed Postgres advanced lifecycle & data protection

bex's managed Postgres has CRUD + connection-info parity (w-postgres, docs/ADR009-postgresql-management.md), but Render exposes a deep second tier on a Postgres instance that bex defers (listed as "Deferred" in docs/ADR006-bex-api.md). Grouped by what each unblocks:

- **Lifecycle** — `POST /postgres/{id}/{suspend,resume,restart}`. Mirrors the compute lifecycle verbs; the CNPG Cluster already supports scale-down.
- **Data protection** (highest value) — backups + **PITR/recovery** (`recovery-info`/`recover`/`exports`) and the dashboard Recovery tab. Needs CNPG backup config (object storage; the etcd/OpenBao backup runbooks are precedent — docs/ADR011-etcd-backup-restore.md).
- **HA** — `enableHighAvailability`, `failover`, read replicas (`promote`/`replication`). `highAvailabilityEnabled` is hard-coded `false` today.
- **Access & connection** — `ipAllowList` (bex has only a `public` on/off toggle — a real security gap for public DBs), Postgres `users`, and the PgBouncer **pooler** connection strings (needs a CNPG `Pooler`; the connection-info shape already has the pooler fields stubbed).

Source: `docs/ADR018-render-parity.md` audit (w1/m13, 2026-07-08). Goal: pillar 1 (Render parity — managed data). Promote data-protection (PITR) first — it's the credibility gap for "managed" Postgres; the rest can follow as sized tasks. IP-allowlist is sub-hour and worth pulling forward on its own.
