How to exclude Supabase auth schema from Prisma migrations but still keep it updated?
I have a database on Supabase, and I’m using Prisma migrations.
Since I have multiple schemas with multiple files, how can I exclude the Supabase auth schema when generating a migration?
I still need the auth schema because of its relationship with my user_profiles table.
Also, how can I keep the auth schema updated while ignoring it in my Prisma migrations?
4 Replies
You opted for speed from this bot. Let's conjure up an answer right now!
Short answer: Use multi-schema, mark Supabase-managed tables as “external,” and baseline once. Then you can keep querying auth tables without Prisma trying to migrate them.
What to do:
1) Enable multi-schema so Prisma can see both your app schema(s) and Supabase auth:
This lets you reference auth.users in relations. [Prisma + supabase]
2) Exclude auth (and other Supabase-managed) tables from migrations using “external tables” so Prisma Migrate won’t modify them. Configure these in prisma.config.ts to tell Migrate to ignore them, while still allowing them in your Prisma schema. This is particularly intended for Supabase. [multiSchema push; Supabase migrate thread]
3) Baseline once, don’t reset Supabase system schemas:
- Pull the existing DB:
npx prisma db pull
- Create an initial migration from the current state, then mark it as applied without changing the DB: npx prisma migrate resolve --applied 0_init
- Avoid resets that try to drop Supabase’s auth tables and dependencies. [Prisma+Supabase discussion; Drop auth users error]
4) Keep auth updated:
- Supabase updates auth schema via its own migrations. Because those tables are external, Prisma won’t conflict. When Supabase changes auth, run prisma db pull to sync your Prisma schema types. If drift is detected solely due to Supabase-managed objects, resolve/baseline rather than attempting to migrate them. [Prisma+Supabase discussion; [Auth drift handling](https://github.com/prisma/pri
sma/issues/17734)]
Notes and caveats:
- @@ignore only affects Prisma Client, not migrations, so it won’t solve this. [@@ignore]
- Generated columns/extensions in Supabase auth can cause drift; external tables avoids needing to “fix” those in your migrations. [Generated columns issue; Drift on extensions]@Prisma AI Help It’s working now and I can generate migrations, but what will happen if Supabase changes their auth schema in the future?
I already added
export default defineConfig({
// required when using unstable features
experimental: {
externalTables: true,
},
// declare auth schema tables and enums as external
tables: {
external: [
"auth.audit_log_entries",
"auth.flow_state",
"auth.identities",
"auth.instances",
"auth.mfa_amr_claims",
"auth.mfa_challenges",
"auth.mfa_factors",
"auth.oauth_clients",
"auth.one_time_tokens",
"auth.refresh_tokens",
"auth.saml_providers",
"auth.saml_relay_states",
"auth.schema_migrations",
"auth.sessions",
"auth.sso_domains",
"auth.sso_providers",
"auth.users",
],
},
enums: {
external: [
"auth.aal_level",
"auth.code_challenge_method",
"auth.factor_status",
"auth.factor_type",
"auth.oauth_registration_type",
"auth.one_time_token_type",
],
},
});
This are from supabase
My initial migration included the auth schema. Could this cause problems later?
Will my future migrations break because of that?
🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
Hey, if you want to chat with bot you can use #ask-ai
Prisma won’t manage or validate structure for external tables. When Supabase updates auth, you should re-introspect (prisma db pull) and regenerate the client, migrations you generate won’t touch those external tables.