The Bad

I can't remember where I first heard about Prisma, but it was around 2 years ago. At the time, despite the fact that I was greatly impressed with what it could do and the approach it was taking, it seemed *too new* and yet to be considered battle-hardened enough. Various features such as transactions were missing, and the small community/userbase meant naturally meant documentation and bugs were not yet battle-tested. … - Forgetting to insert a field that is non-nullable - Typos in your query builder's string arguments - Selecting only specific fields will infer that the return type should include and *only* include those fields. - Ordering and filtering knows the types of the columns and what you can and can't do to each type. … - You quickly dive into having classes where 70% of the lines are just decorators. - Decorators aren't typesafe, it's possible to do a `@Column("varchar")` decorator on a `id: number` field. - Relations are messy, requiring having both `A` as a field in `B` *and* `B` as a field in `A` but no one tells you if you've done them wrong. … The main pitfall here is that most general purpose langauages (including TypeScript) just aren't good at describing or enforcing data models and (bi directional) relations. So, the Prisma team said *screw it, we're gonna write a custom language for this then generate the TypeScript types and client instead*. And in my opinion, that was a *fantastic* idea. Looking at the example (which can also be found on the main Prisma docs): … ## The Bad ### Prisma Schema can only be in a single file Far from a dealbreaker, but not ideal. There are a few third party solutions out there that will compile multiple prisma schema files together, but a first party solution doesn't feel like a lot to ask for - especially as the Prisma team is pushing the narrative that it's ready for production, and many databases out there have large numbers of tables which is going to result in a schema file that's thousands of lines long. Given that splitting code into different files/modules isn't exactly groundbreaking computer science these days, I would've really thought this would be done by now. ### Still many the typical limitations of an ORM Nested select queries work like a dream *but* like many other ORMs, more advanced queries like group-bys with nested relations or complex aggregates aren't really possible, at least not without falling back to raw SQL. Prisma also doesn't have a querybuilder API that can act as an intermediate step between the high level ORM API and raw SQL, which makes sense given their safety-first design philosophy, but also is sometimes missed for more complex queries. ### No nested create-many or delete API This one's pretty self explanatory. I don't really see any reason (apart from the complexity of the query generation) why we shouldn't be able to do a nested create-many like described here. Similarly, I also think there should be nested programmatic deletes rather than just specifying the cascade behaviour - after all, nested deletes already *kind of* exist when updating objects without deleting the parents. The API could just allow specifying (for one-to-one relations) which relations should be deleted along with the parent or not. ### Migrations API requires lots of care and manual intervention Ok, so the migrations API is actually *not* that perfect. Its features I mentioned earlier are still very much great, but I do have trouble with a few things: … Failed migrations, for some reason, require manually going into the database with write access to delete a failed migration entry. This is despite the fact that the migrations *do* run inside a transaction, so a failed migration has no effect on the database anyways. However, the docs honestly make it sound like migrations *don't* run inside a transaction by talking about manually applying or rolling back individual steps in the migration. My best guess is that Prisma didn't have a transactions API until not-that-long-ago (well, a year or so ago), and not a lot of effort has been made to update the migration API or docs to reflect this. … Combining with the previous point that Prisma recommends running Prisma CLI commands manually against your prod database to resolve failed migrations, it seems incredibly risky to me that someone will eventually press their arrow keys too many times and end up wiping the prod database. Migration creation also happens by looking at your development database and comparing it to your Prisma schema, instead of your previous migrations. This is another design decision which I don't agree with, as local dev database schemas can vary branch to branch and the developer may have forgotten to reset their database when they last switched the branch.