Staging-first SQL
All readiness SQL, migrations, views, indexes, and grants should be reviewed and executed first in staging. Production promotion requires explicit approval and rollback awareness.
Protected exports → database readiness visibility
Database Readiness Note
This note makes database readiness controls visible for donor review. It is documentation only. It does not execute SQL, alter Supabase schema, change RLS policies, modify credentials, or affect live production logic.
RLS verification
Every protected route should be tested against role, organization, programme, reviewer, and admin boundaries. Tests should include allowed, denied, and cross-tenant cases.
Indexes
High-use routes, exports, dashboards, MRV views, queues, and audit lookups should have supporting indexes and explain-plan review before donor-scale traffic.
Pooling
Connection pooling should be checked for serverless functions, export bursts, background jobs, and authenticated workspace traffic.
PITR/backups
Point-in-time recovery, backup retention, restore drills, recovery ownership, and incident communication should be confirmed before production scale-up.
Monitoring
Operational monitoring should cover database health, auth/session errors, function errors, failed exports, queue backlogs, background jobs, and suspicious access patterns.
Load testing
Staging tests should cover login, protected navigation, evidence read/write, export pack generation, MRV summary reads, and admin/reporting flows.
Background jobs
AI Advice, exports, satellite refresh, MRV checks, notifications, and queue processing need status, retry, ownership, and failure visibility.
Readiness boundary
The presence of this note does not certify the database as production-ready. It documents the control domains donors and technical reviewers should verify before production deployment or donor-scale use.