3 ms·
I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those
by Tade0 3y ago
I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those engines) is either available in the documentation or visible upon install/build - you can actually make it point to specific executables instead of downloading each time using environment variables but again - it's in the docs.
I picked Prisma because I'm not actually a backend developer and the tradeoffs were okay for my use case.
I wish performance was better, but a few indexes here and there went a long way.
The only surprising bit for me was peak memory usage - it comes in bursts and can get to hundreds of MB when doing even a simple query.
The queries themselves are also kind of out there in terms of complexity but so far I haven't found a reason to rewrite them in raw SQL, since that isn't where our performance bottlenecks are at the moment.
The lack of rollbacks is one legitimate pain point and I wish they addressed it.
- mattacular 3y ago> The lack of rollbacks Could you elaborate on this part?
- Tade0 3y agoHere's a comment from their team about this: https://github.com/prisma/prisma/discussions/4617#discussioncomment-215868 https://github.com/prisma/prisma/discussions/4617#discussion... Tl;dr it's a design decision, not everyone (including me) agrees.
- superwalker 3y ago[flagged]
- DanielHB 3y agoI added prisma to a server I have and I was surprised it was running out of memory when using "prisma migrate deploy" (only migrations, not actually just running prisma client). The server was configured to use only 512mb of RAM though. It seems prisma migrate needs quite a bit of RAM.