Hello. My team decided to use Prisma as our ORM for our new set of services we're building using NestJS. It seemed to be going well, but we have a constant issue with the Prisma Schema being too restrictive. Basically we can't make any structural changes within our database without doing it via the Prisma schema. This is very strange to me as an experienced data engineer and DBA. It doesn't seem right that the ORM would dictate and control on this level. Are we missing something in terms of a config setting or similar that can relax the strictness?

One of my favorite things about Prisma is not having to write SQL migrations! However it sounds like your use case might be more advanced.

Could you clarify what kind of restrictions you’re running into? A possible alternative workflow if you’d prefer to make changes in SQL: 1. Create and execute migrations in SQL/your preferred tool. 2. Pull those migrations to Prisma using

npx prisma db pull

3. Save the migrations in Prisma with

npx prisma migrate dev

@Tasin Ishmam thank you for your response. I will look into this, but the restriction that Prisma places on us of requiring all structural parts of a database to be defined in a Prisma schema is way too strict for use in a complex, multi-service database environment. For example, if I want to add a control table to the database schema that is used by a different server process, Prisma kicks up issues and expects that table to be in the Prisma schema, instead of just ignoring it. Not good. Another issue we experienced last night was the renaming of a table. I had pluralised the name inadvertently, so needed to singularise it. When we ran the Prisma migration for this, we lost all the data in the table (I assume the migration dropped the table and recreated it). If this is the Prisma's default and there is no obvious way to prevent the dropping of data like this, then it is just not mature enough, or at least flexible enough and it would appear that it is designed for a very narrow workflow. Your (or anyone else's) thoughts on my comments will be appreciated.

Hi @starlord btc - what you can do is generate the migration file and then edit the sql directly in the

~/prisma/migrations/xxx

folder All the migration does is run the query so whatever you have in there is what is run..

@starlord btc Thanks for the feedback! The two features you mentioned are indeed not supported by Prisma at the moment. We have a feature request for ignoring tables during introspection, would be great if you left a comment or 👍 there so we can prioritize this feature. Prisma migrate will indeed delete records and there isn’t a non destructive way to rename tables at the moment. The migrate workflow is something we are trying to improve upon, but for the moment I would recommend running migrations manually in SQL (or modifying the migration files that prisma generates before executing them). Just add to what Richard said, you can use

prisma migrate dev --create-only

to create a migration file, but not execute it. Afterwards, modify the SQL file as you please, before running the

prisma migrate dev

command again to execute the migration.

Prisma places on us of requiring all structural parts of a database to be defined in a Prisma schema

This was a design choice we made early on to make the schema a single source of truth for the database database structure. This is perhaps not suitable for everyone.

Thanks for taking time to answer my questions @Tasin Ishmam and everyone. For now, we have taken the decision to go with TypeORM.

You’re welcome!