Database & Data Access
Working with Supabase PostgreSQL in your module. Multi-tenant queries, Row Level Security, and the useModuleApi hook.
Database & Data Access
All modules share a single Supabase PostgreSQL database. Data isolation between tenants is enforced through Row Level Security (RLS) and the organization_id pattern.
useModuleApi Hook
The useModuleApi hook provides tenant-scoped CRUD operations:
Hook API Reference
| Method | Signature | Description |
|---|---|---|
query | (table: string) => PostgrestFilterBuilder | Start a SELECT query with automatic organization_id filter |
insert | (table: string, data: Record) => Promise | Insert with auto organization_id |
update | (table: string, data: Record, filters: Record) => Promise | Update scoped to tenant |
remove | (table: string, filters: Record) => Promise | Delete scoped to tenant |
supabase | SupabaseClient | Raw Supabase client (for advanced queries) |
organizationId | string | null | Current tenant UUID |
Creating Your Own Tables
Naming Convention
Prefix all your tables with your module slug to avoid conflicts:
Examples:
myanalytics_reportsmyanalytics_dashboardsmyanalytics_settings
SQL Migration
Always enable RLS on your tables. Without RLS, any authenticated user could access data from other organizations. The marketplace review will check for this.
Row Level Security (RLS)
RLS policies control which rows each user can access. The pattern for modules:
Common RLS Patterns
Read-only for regular users, write for admins:
User can only see their own records:
Using React Query
For complex data fetching, combine useModuleApi with TanStack React Query:
Direct Supabase Client
For advanced queries not covered by useModuleApi, access the Supabase client directly: