Skip to main content
supabase-schemas lets you run dozens of isolated app schemas inside a single Supabase instance. Each tenant gets its own app_<id> PostgreSQL schema with migration tracking — without paying for multiple Supabase projects.

GitHub

nometria/supabase-schemas

PyPI

supabase-schemas on PyPI

Install

pip install supabase-schemas

Setup

export DATABASE_URL=postgresql://postgres.your-ref:password@aws-0-us-east-1.pooler.supabase.com:5432/postgres

Usage

# Create a new tenant schema
supabase-schemas create acme-corp

# List all tenant schemas
supabase-schemas list

# Run migrations for a specific tenant
supabase-schemas migrate acme-corp --migrations-dir ./migrations

# Run migrations for all tenants
supabase-schemas migrate-all --migrations-dir ./migrations

# Drop a tenant schema
supabase-schemas drop acme-corp

How it works

Each tenant gets an isolated PostgreSQL schema:
-- Created automatically by: supabase-schemas create acme-corp
CREATE SCHEMA app_acme_corp;

-- Each schema gets its own tables, functions, and policies
-- Row-level security is scoped per schema
-- auth.users view is wired automatically
Migration tracking is per-tenant:
-- app_acme_corp.schema_migrations
id | name                     | applied_at
1  | 001_create_users.sql     | 2025-01-15 10:00:00
2  | 002_add_settings.sql     | 2025-01-20 14:30:00

Use cases

ScenarioHow
SaaS with isolated tenant dataOne schema per customer
White-label appsOne schema per white-label client
Development environmentsOne schema per developer
Feature branchesOne schema per branch

Cost comparison

ApproachMonthly cost (10 tenants)
10 separate Supabase projects~$250/mo (Pro plan × 10)
supabase-schemas (single project)~$25/mo (one Pro plan)
Schema isolation provides strong logical separation but not the same security boundary as separate Supabase projects. For compliance-sensitive workloads, evaluate whether schema-level isolation meets your requirements.