Reasons to avoid Prisma

Prisma is a pretty popular (1.5 million weekly downloads!) ORM for the Node ecosystem. I’ve used it at work in various small projects due to its purported popularity. After having had it in our ecosystem for over around months, I have some thoughts:

It uses a proprietary schema file format

The prisma/schema.prisma format on its own is fine.
```
model User {
  id    Int     @id @default(autoincrement())
  email String  @unique
  name  String?
  posts Post[]
}
```
However, it is not easily open to extension or analysis by other ecosystem tooling that would be brought by JSON, YAML or TOML. Despite that, this blog knows how syntax highlight these code blocks, so I suppose that’s good enough.

Either way, it irks me that it’s not in a generic format or in an actual programming language format (JS / TS).
Primsa requires a particular environment variable for database connections

This seems innocent enough:
```
datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}
```
However, this configuration isn’t in your app code. That means you can’t compose your credential string using what’s available in your app’s purview. In our cases, we’re using docker deploying to a kubernetes cluster that automatically injects various DATABASE_ environment variables. Our setup doesn’t precompose DATABASE_URL with username and password inlined, so instead we need to use a custom entrypoint.sh that concatenates all these variables together so its suited for Prisma.
Thousands of issues

Every open source project that’s popular has thousands of issues open in their project repositories. Prisma is no different.

Having not kept any records from my previous encounters researching odd bugs and looking for generally useful features, I can’t say how many issues are noise or how many are pleas for features stuck in limbo. We all know what you say about open source though, of course, “PRs welcome.” Still, it’s never a good sign when your database connector, effectively the most foundational component of your application (after all, if you could not fetch or save data, would you even have an application?) is has so many issues tied to it.

As an amusing example
Ever use AsyncLocalStorage? Well, with Prisma that kind of just… breaks? There’s an alleged workaround but it could end up causing a memory leak. Surely, all of that is superfluous but it’s someone’s plan that’s just been ruined, superfluous or not.
Bonus! Bundling Prisma with a Next app in Standalone Mode (output settings) is tricky

Standalone Mode is ideal for a docker image target because it removes dev-dependencies and other unused dependencies, leaving you with only compiled source and the necessary dependencies to run on demand. Well, the Prisma cli is necessary for migrations but it’s not an actual runtime dependency, so Standalone Mode strips it right out and you have to do some trickery to put the right executable dependency back into the Standalone Mode node_modules/.bin folder.

It’s all weird. Sure, it might be induced by our ecosystem but it’s not quite as easy as I’d have hoped.
Bonus! ZIRP is dead, EE reigns, how does Primsa make money and keep this going?

Accelerate is cool, but doesn’t everyone have one of those serverless-databases these days? So far it’s worked but in this economy it’s just way harder.

Now, the actual query experience? It’s fine. For me the first 80% of an ORM is to handle simple SELECT INSERT UPDATE DELETE queries. Then everything else is probably object relational mapping. You can read all about the Object-relational impedance mismatch. There’s always going to be a weird situation where you need to write your own raw SQL (with a prepared statement, hopefully). I think it’s good to expose the object mapping utilities back to the user so they can rebuild the interface themselves, but most ORMs do not go out of their way for that.

Alas, Prisma has been fine. I haven’t spent much more than a dozen maintenance hours on our internal projects that used Prisma, so it’s not gotten in the way too much either.