Things to Consider About Prisma Before Adding it to Your Next Project

My team recently decided to assess alternatives to TypeORM, the ORM we currently use with one of our Postgres databases. After evaluating several tools, we decided to use the Prisma library. Prisma provides a higher level of abstraction to the database than TypeORM. It was built to be more intuitive than traditional ORMs and provides built-in solutions to common problems. I’ve really enjoyed using Prisma’s declarative schema and generated types so far. I think it’s a better fit for our use case than TypeORM and handles tasks more elegantly. All that to say, after using this library for a bit now, there are a few Prisma quirks I wish I would’ve discovered during our investigation phase. I thought I’d share them in hopes that someone looking for similar information might stumble upon this.

SQL Views

After spinning up an initial database with placeholder schema, we started working on a more robust data model. There’s some data that we wanted to store as a materialized view. Prisma provides some documentation about how to create views, but there are some serious gotchas. As they note, their steps are a workaround that “will not work with Prisma Migrate or introspection.” This means that we would have to use a custom migration system if we decided to introduce views to the Prisma ecosystem. That’s not ideal.

I’ve heard devs make the case that views aren’t necessary, so this may not be an issue for everyone. Either way, we didn’t necessarily need a view for our data, so we implemented without it. However, we’re still hoping to get support for views in Prisma in the future.

Absence of Down Migrations

Similar to views, I’ve heard opposing opinions about the value of down (or rollback) migrations. This debate is valid considering I’ve been on some teams that test and maintain down migrations and some that don’t. Prisma doesn’t support a roll-back pattern. Their documentation says, “Prisma Migrate does not currently roll back a migration without resetting the database.” The migrations only progress, so any changes will just result in another migration file.

This isn’t necessarily a gotcha. It’s more just something to consider depending on your project’s needs or processes. Prisma has some documentation about this as well as other known limitations to the Prisma Migrate module here.

Prisma Seed

This is a small quirk but feels worth mentioning since it took a bit for me to discover. Prisma’s docs outline a process for seeding a database via the prisma db seed command. Whenever I’ve run that command, I this error:

Error: This feature is currently in Preview.

There may be bugs and it's not recommended to use it in production environments.

It’s pretty easy to set up a script or a function to do the seeding of a database rather than using this command, but it would have been helpful for the documentation to mention that this feature is still in beta.

Yarn PnP Support

Our project uses Yarn Berry (or Yarn 2… or Yarn 3… I’m still not really sure what they’re calling it), which automatically uses the Plug’n’Play (PnP) feature of yarn. Yarn PnP removes the existence of node_modules in a project. Yarn instead generates a file called pnp.js that holds various mappings to speed up the project’s package access. This all sounds amazing (and it mostly is), except Prisma relies heavily on its node modules.

Consequently, Prisma does not support PnP — there’s an open GitHub issue for it. Multiple workarounds are suggested in that thread, and my team ultimately did get Prisma working in our Yarn Berry project. However, it was not without issues and lots of trial and error. It wasn’t a dealbreaker for us that Prisma lacks explicit PnP support, but it’s certainly something to take note of if you’re using Yarn Berry.

Prisma Quirks I Wish I’d Known About

That’s my roundup of things I wish I would’ve known about Prisma! Let me know in the comments if there are others I missed.