Last week, we completed a migration that switched our underlying database from MongoDB to Postgres. We faced a lot of interesting challenges, and the biggest one of them was a two-time rewrite of the codebase. This article is for developers considering using Prisma for their production workloads - don't. We wrote our backend in Prisma

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

A developer shares their experience migrating from MongoDB to Postgres and using Prisma for their backend. They highlight problems with Prisma's deployment, low performance, and lack of SQL-level joins. They ultimately recommend avoiding Prisma for production workloads.

We migrated to SQL. Our biggest learning? Don’t use Prisma

Prisma + PlanetScale: Built for each other, but not for production workloads

<blockquote>
No foreign key support
</blockquote>
<blockquote>
There is no concept of SQL-level joins in Prisma
</blockquote>
<blockquote>
On every insert, Prisma opens a transaction where it inserts and then returns the inserted record too, even if we do not want it.
</blockquote>
Careful, horror story.

Drizzle if you want an ORM and Kysely if you want a SQL query builder.

Kysely seems a good SQL builder if you don’t want an ORM, I can understand that Prisma might be too much for an AWS lambda.
In serverless enviroments you want to optimize as much as possible, so I understand the author of the post.
Kysely is more a DBAL (data base abstraction layer), so it’s not comparable to Prisma (which is a DBAL and also an ORM).