You are one Postgres instance in Tokyo. What happens when it dies during my board meeting?

The full executive answer

I will give you the honest engineering answer, not the sales answer. Yes — today the system of record is a single-region Supabase Postgres cluster in Tokyo. If that region fails mid-meeting, the live application is down until it recovers. What is protected is your data: we run point-in-time recovery — PITR, continuous backup that lets us restore the database to any moment — so a failure means an outage, not data loss. Board packs and reports you have already exported as documents remain in your hands regardless.

In disaster-recovery language: our RPO — recovery point objective, how much data you could lose — is near zero because of continuous PITR. Our RTO — recovery time objective, how long until we are back — is the honest gap: we have not yet run a real disaster-recovery drill, so I will not quote you an RTO number that a drill has not evidenced. Our own reliability code literally flags availability as a target, not a measurement — the platform is built to refuse to present unmeasured numbers as commitments, and I hold myself to the same standard.

The roadmap is concrete: first, a rehearsed restore drill — PITR restore plus a second-region restore — to put a measured number on RTO; that is written into our README as the gate before any availability SLA. Second, the multi-region cell architecture already exists in configuration — EU and India cells are defined and unprovisioned — so standing up a second region is provisioning work, not re-architecture. For a board-meeting-critical deployment, the compensating control today is simple and practical: the board pack is generated and exported before the meeting, so the meeting artefact never depends on live uptime.