I mean, Prisma is just awful, that's hardly a problem of soft deletes.
At my previous job we used prisma, and what a terrible system, the amount of problems I saw there. Some have been fixed since, but it shouldnt take 3 major versions of an ORM to use an actual upsert operation instead of doing
if select() then update() else insert() at the client side, which is all sorts of wrong.
Or the 50ms of latency it introduced per query by starting a separate process that generated the queries, or the lack of schema flexibility, or the idiotic new join features that transforms rows into jsons in a destructive way.
I've hit a lot of rough edges with it too. A few off the top of my head:
- in memory joins (until they added the preview relationalJoin feature)
- no partial indexes
- no select for update
- no table partitioning (though if you do this out of band it all works fine)
- use of create type enum instead of check constraints makes maintenance of enumerated columns more challenging (IMO)
- little support for less common (but useful!) data types like geospatial, intervals, ltree, etc
- the reliance on wasm/rust makes debugging what it's doing difficult
- the connection pooling defaults are surprising (never reaps idle connections, AFAIK not cgroups aware and over provisions the pool size based on host CPU count)
For simple use cases it's appealing, and I suspect it's probably a better experience with nosql databases, but when you're used to taking full advantage of postgres' feature set it gets frustrating quickly.
There's issues in the tracker for basically everything above, and some may have even been solved by now - in a few more years it might be a better experience.
> in memory joins (until they added the preview relationalJoin feature)
This, to me, was the single issue that made me forever not take Prisma seriously. I get that “ship now, fix later” is a mindset, but you simply cannot ship an RDBMS wrapper that doesn’t handle JOINs. That’s an integral part of the system.
> the connection pooling defaults are surprising (never reaps idle connections, AFAIK not cgroups aware and over provisions the pool size based on host CPU count)
Tbf I have yet to find a piece of software that hasn’t messed up cgroupsv1. That’s not really an excuse – read docs – but at least everyone seems to make the same mistake.
At my previous job we used prisma, and what a terrible system, the amount of problems I saw there. Some have been fixed since, but it shouldnt take 3 major versions of an ORM to use an actual upsert operation instead of doing
if select() then update() else insert() at the client side, which is all sorts of wrong. Or the 50ms of latency it introduced per query by starting a separate process that generated the queries, or the lack of schema flexibility, or the idiotic new join features that transforms rows into jsons in a destructive way.
It's just bad software