1 supabase instance for each tenant?
I’d love to hear from anyone who’s actually done it—especially around:
- Managing multiple Supabase Auth configs and keys
- Running 4+ Supabase projects locally or in the cloud
- CI/CD and migration strategies across multiple instances
- Whether the benefits (e.g. security, isolation) were worth the added complexity and cost
For context, here’s our current setup:
- Single Database: One Supabase PostgreSQL instance shared by all tenants
- Schema Isolation: Each tenant has its own schema (e.g., tenant_x, tenant_y, tenant_z)
Tenant-Aware Access:
- A custom TenantDB class sets the search_path dynamically based on the tenant ID
- Ensures complete data isolation across schemas
This has worked well so far—it's efficient and isolates data cleanly.
But we’re evaluating a switch to instance-per-tenant for added isolation and regulatory compliance.
Would love to hear your experiences, challenges, or advice before diving into this migration
- Managing multiple Supabase Auth configs and keys
- Running 4+ Supabase projects locally or in the cloud
- CI/CD and migration strategies across multiple instances
- Whether the benefits (e.g. security, isolation) were worth the added complexity and cost
For context, here’s our current setup:
- Single Database: One Supabase PostgreSQL instance shared by all tenants
- Schema Isolation: Each tenant has its own schema (e.g., tenant_x, tenant_y, tenant_z)
Tenant-Aware Access:
- A custom TenantDB class sets the search_path dynamically based on the tenant ID
- Ensures complete data isolation across schemas
This has worked well so far—it's efficient and isolates data cleanly.
But we’re evaluating a switch to instance-per-tenant for added isolation and regulatory compliance.
Would love to hear your experiences, challenges, or advice before diving into this migration
