Supabase PostgreSQL 15
Database Integration by Supabase Inc.
Description
Managed PostgreSQL database serving as the primary persistent data store for the entire peer mentor platform. Hosts all relational data including organisations, contacts, activities, expense claims, certifications, user roles, and audit logs. Row-Level Security (RLS) policies enforce multi-tenant data isolation across all tables.
Detailed Analysis
Supabase PostgreSQL 15 is the central nervous system of the peer mentor platform, serving as the single source of truth for every business record — organisations, contacts, activities, expense claims, certifications, and audit trails. Its Row-Level Security architecture provides enterprise-grade multi-tenant data isolation, meaning each organisation's data is cryptographically separated at the database layer, not just the application layer. This reduces regulatory risk and simplifies compliance audits. The managed Supabase Pro subscription bundles 60,000 monthly active users, 99.9% uptime SLA, and built-in observability — eliminating the need for a dedicated database operations team.
Cost scales predictably with storage size, compute load, and user growth, making budgeting straightforward. The offline-first fallback strategy ensures field workers retain access to critical data even without connectivity, directly improving the quality of service delivery in remote locations.
This integration underpins every other system capability — 25+ repository components depend on it directly. Initial setup requires Supabase project provisioning, schema migrations, and RLS policy configuration across all tables, which should be scoped as a dedicated infrastructure sprint before feature development begins. Environment variables (SUPABASE_URL, SUPABASE_ANON_KEY, SUPABASE_SERVICE_ROLE_KEY) must be managed in CI/CD secrets from day one to prevent credential leakage. Ongoing maintenance includes monitoring query latency (alert threshold: >500ms), disk usage (alert at 80%), and connection pool exhaustion.
The offline-first cache layer (Drift/SQLite) adds complexity to the data layer and requires thorough testing of sync edge cases. External dependency risk is moderate: Supabase outages affect all app functionality, but the 99.9% SLA and offline fallback mitigate this. Team members need familiarity with PostgreSQL RLS policy authoring and Supabase dashboard tooling.
Supabase PostgreSQL 15 is accessed exclusively via the supabase_flutter SDK using the PostgREST HTTP API layer, not direct TCP connections. All queries are mediated through RLS policies that evaluate the JWT claims of the authenticated session — service role key bypasses RLS and must never reach mobile clients. PostgrestException is caught at repository boundaries and mapped to typed domain errors. Transient connection failures trigger exponential backoff retry; constraint violations trigger transaction rollback.
Offline resilience is implemented via Drift/SQLite as a local read cache with queued write operations that sync on reconnect — staleness is surfaced via UI indicators. Performance targets are <200ms for standard queries and <1s for aggregation queries, enforced via Supabase observability alerts. The 128-supabase-stats-views component provides pre-aggregated materialised views to avoid expensive runtime aggregations. RLS policy evaluation time is tracked as a key metric alongside active connections and row counts per table.
Using Components (26)
Dependencies (3)
Authentication
| Type | Api Key |
| Requirements | Supabase project URL, Supabase anon/service role API key, JWT secret for RLS policy verification |
| Scopes | readwriterls_bypass (service role only) |
Configuration
SUPABASE_URL
SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY
Error Handling
Monitoring
Performance
| Latency | < 200ms for standard queries, < 1s for aggregation queries |
| Availability | 99.9% uptime SLA on Supabase Pro plan |
Cost Implications
| Pricing Model | Monthly subscription with usage-based overages |