Question about Prisma Migrations and "public" Schema
Hi! I noticed that in my recent Prisma migrations, the generated SQL now includes "public"."table_name" for table creation and foreign keys, but in my older migrations, it was just "table_name" without the schema prefix. I haven’t changed anything in my schema.prisma regarding schemas.
Why does Prisma now add the "public". prefix in migration SQL?
Is this a new default behavior in recent Prisma versions?
Is there any impact or best practice I should be aware of?
Thanks for any clarification!
12 Replies
You selected the bot's instantaneous insights. Let me compile your answer right away!
Great questions!
1. Why does Prisma now add the "public". prefix in migration SQL?
Prisma has improved its handling of database schemas, especially for PostgreSQL. In recent versions, Prisma is more explicit about schema usage and now includes the
Yes, this is a result of ongoing improvements in Prisma's schema and migration logic. The explicit schema prefixing (e.g.,
- If you use only the
Prisma has improved its handling of database schemas, especially for PostgreSQL. In recent versions, Prisma is more explicit about schema usage and now includes the
"public". prefix in generated SQL to clearly specify the schema where tables and constraints are created. This helps avoid ambiguity, especially in databases with multiple schemas or when using features like multi-schema support.
2. Is this a new default behavior in recent Prisma versions?Yes, this is a result of ongoing improvements in Prisma's schema and migration logic. The explicit schema prefixing (e.g.,
"public"."table_name") is part of Prisma's efforts to make migrations more robust and predictable, particularly as features like named constraints and multi-schema support have been introduced and refined in Prisma 3 and later. This ensures that migrations behave consistently, regardless of the database's default search path or existing schema configuration What's new in Prisma? (Q3/21).
3. Is there any impact or best practice I should be aware of?- If you use only the
public schema (the default in PostgreSQL), this change is mostly cosmetic and should not affect your application.
- If you use multiple schemas or plan to, being explicit with schema prefixes helps prevent migration or query issues.
- When upgrading Prisma, review the Named Constraints upgrade guide to ensure your constraint and index names are handled as expected.
- Always introspect your database (prisma db pull) after upgrades to keep your Prisma schema in sync with the actual database state.
Let me know if you need more details!But in my project, I want to maintain consistency. What should I do now?
🤔 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.
@Prisma AI Help But in my project, I want to maintain consistency. What should I do now?
@Nurul (Prisma) Sorry for mention please see the problem.
Did you upgrade your prisma version recently?
Which database are you using? From what I remember we added schema name in migrations a long time back
Yes i updated prisma.
Postgresql Database.
You shouldn't run into any issues.
All the migrations going forward should have the schema prefixed before the table name.
First one is old schema and it's not added public
and second one new schema migration here i see the public. so now should i add public in old migration?
No, I won't recommend editing the already generated old migration files.
Are you facing any issues due to this change?
No...
Cool, then you should keep old migrations as it is.
Thank you so much