My Experience with PRISMA so Far and Why I ... - Tech Tales

# Challenges Immediately after switching to Prisma, I realized my server was taking too long to respond. A single login request, which often took 700ms to complete, took over 10s. This delay is significant and could affect user performance. Requests made with Prisma were ten times slower than normal! I looked around to try and understand why this was happening or some errors that I could be making. Prisma documentation suggests indexing frequently queried columns such as username and email by adding @@index([username, email]). However, this does not solve the issue. Prisma is too slow, especially in queries that involve selecting data from more than one table. The database also has a cold start, which means that after the Prisma client disconnects, new requests will take time. PRISMA is also not designed to run on the edge, where vercel hosts their serveless functions. This implies that the servers are not up and running all the time in a serverless environment, thus the cold starts before Vercel spins the function and awakens the database. ## Here is what I have realized so far: - Prisma is not suited to run on the edge and thus the database sleeps when the Prisma client disconnects. Prisma takes time to connect again. - Every new insert via Prisma opened a database-level transaction (?). An extremely weird design choice by Prisma. This makes you exhaust your connection pool very fast. … - For every action (Create, Read, Update, and Delete) prisma returns the object by default even if you do not want it. Even for delete! - Prisma supports JSONB datatypes in Postgresql and MySQL. However, there is no way to update such data type. The existing way is to fetch the whole object, spread it, and then add or delete data, then post the same object again. This is utterly ridiculous.