Working with Multiple Schemas

1. Configuring Multiple Datasources

Note: Prisma supports exactly one datasource block per schema. Use one PrismaClient per physical database for cross-database workloads.
ApproachDetail
Multiple schemasOne client per database
File layoutprisma/schemas/billing/schema.prisma
GeneratorsDistinct output paths

2. Using Database Schemas

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
  schemas  = ["public", "auth", "billing"]
}
model User { id Int @id ... @@schema("auth") }
AspectDetail
PreviewpreviewFeatures = ["multiSchema"]
Default schemaFirst in schemas

3. Switching Between Schemas

ApproachDetail
Schema attributePer model @@schema
Search pathSet via URL param ?schema=auth

4. Managing Cross-Schema Queries

AspectDetail
Same DBJoins allowed (PG)
Different DBsNo joins; orchestrate in app

5. Implementing Multi-Tenancy Pattern

Single DB / shared schema

  • tenantId column on every row
  • Cheap, scalable
  • Requires row-level security

DB-per-tenant

  • Isolated data
  • Higher cost
  • One PrismaClient per tenant
ModelRecommended For
Shared schemaSaaS with many small tenants
Schema-per-tenantMid-size with regulatory needs
DB-per-tenantEnterprise, hard isolation

6. Using Database-Specific Schema Features

FeatureDB
CHECK constraintsPG/MySQL (preview)
Generated columnsPG/MySQL via raw SQL
Domain typesPG only

7. Handling Per-Schema Migrations

StrategyDetail
One migrations dir per schema--schema flag
OrderingApply shared dependencies first

8. Synchronizing Multiple Schemas

ToolUse
CI scriptLoop migrate deploy per schema
DB eventsPublish via Pulse / CDC

9. Configuring Per-Schema Connection Pools

AspectDetail
Per clientSeparate pools by design
Total capSum of all pools ≤ DB max

10. Testing with Multiple Schemas

PatternDetail
Per-test schemaGenerate random schema name
ResetDROP SCHEMA after suite