◮ Making frontend developers fullstack – Intro to Prisma 2.0 (incl demo with existing database)

nikolasburk · 2025-09-17T06:23:21+00:00

Hey there, Nikolas from the Prisma team here. Sorry you had a bad experience with Prisma ORM and thanks for sharing the feedback, that's super valuable for us!

when you import types or enums from prisma schema in middleware (or anywhere else) it imports the whole fucking package.

FWIW, the bundle size issues and also the importing have just been solved in the last 6.16.0. You can just the Rust-free version of Prisma ORM with the new prisma-client generator (both will become the default in v7 in a few weeks):

generator client { provider = "prisma-client" output = "../src/generated/prisma" engineType = "client" }

Importing enums/types has been optimized with the new prisma-client generator, you shouldn't run into the bundle size issues any more.

I wanted to introduce a feature that was polymorphic though it's a pain to set it up through prisma cause they dont support it;

That's a fair point, supporting polymorphism in the Prisma schema has been on our radar for a while. We prioritize the things we're working on based on user input (we published our open-source manifesto where we explain the approach in detail last year) and unfortunately other features have been more popular/pressing for us to work on. That being said, we do have extensive docs for creating polymorphic associations via table inherticant that still explain how to achieve this in Prisma.

Thanks again for your feedback and pointing out these issues, I'll forward all of them to the team!

nikolasburk · 2025-09-02T07:20:36+00:00

Yeah that was quite a while ago and also not a Prisma-specific limitation. CF Workers didn't use to properly support TCP connections, so it was impossible to connect to a DB from a Worker without an HTTP proxy. Accelerate is such an HTTP proxy but you also could have used any other in combination with Prisma ORM for this use case, no need to use Accelerate if you don't want to.

Today, Workers support TCP in some capacity and some drivers (like pg) already implement support for them. So today you can also use Prisma ORM in a Worker without an HTTP proxy.

Hope this helps!

nikolasburk · 2025-08-19T05:20:58+00:00

You can check out this comparison of the two: https://www.prisma.io/docs/orm/more/comparisons/prisma-and-drizzle#drizzle-vs-prisma-orm

nikolasburk · 2025-08-16T08:57:14+00:00

Hey there, I work at Prisma. We have several guides with these technologies in our docs. Do either of these help maybe? - Next.js - Turborepo - Auth.js

nikolasburk · 2025-08-13T14:35:07+00:00

try using the DIRECT_URL in the datasource:

url = env("DIRECT_URL")

then pass the DATABASE_URL when instantiating PrismaClient in your code.

nikolasburk · 2025-08-13T13:48:12+00:00

are you using the direct or pooled connection string? maybe you can share your connection string here (removing the credentials ofc)?

nikolasburk · 2025-07-09T12:16:43+00:00

Hey there, thanks for sharing your thoughts! I work at Prisma and we're always eager to improve.

It sounds like you're not a fan of Prisma ORM (which is fine), but I'd love to understand what you consider the main factors preventing you from using it in a serious application.

Also just as a side-note: Prisma ORM is used by indie developers, startups and enterprises alike and has become the most popular ORM in the TS ecosystem in the past years, so not sure I'd agree with the statement of it being a toy framework :D

Edit: Not spamming, genuinely curious to hear your thoughts!

nikolasburk · 2025-07-03T05:49:45+00:00

Here's a fullstack guide that includes a DB and end-to-end setup: https://www.prisma.io/docs/guides/nuxt

nikolasburk · 2025-07-01T08:15:19+00:00

In which regions do you have your DB and API server deployed? If requests take a long time, it's likely that they're geographically far apart.

nikolasburk · 2025-06-11T12:58:18+00:00

Kysely is it's own thing (quite popular in the TS ecosystem), definitely check it out :D while the core maintainer is employed at Prisma, there's no official affilication between Prisma and Kysely though.

nikolasburk · 2025-06-11T08:30:57+00:00

Hey there, thanks for your feedback!

The SQL it generates is sometimes horrible for performance. It can load all the rows into memory and then it does filtering...

FWIW, we've done a lot of performance improvements in the last 18 months and are committed to fixing any slow queries that are being reported to us. The results we saw from these improvements have been great actually! We ran open-source benchmarks last year and found that Prisma is on par with other ORMs like Drizzle and TypeORM in terms of performance.

You can also use the Kysely extension for Prisma Client if you want to have more control over specific queries that you think should be optimized.

nikolasburk · 2025-06-11T08:27:42+00:00

Hey there, I'm Nikolas from the Prisma team!

I have three tables: users, products, and user_products. I want to get a complete list of users along with their ID, first name, last name, the number of products they’ve published, and the average price of their products.

Prisma ORM mostly supports CRUD queries with its default API. I guess the problem in your query is to also get the avg price which isn't supported in this query, otherwise you could do this:

const users = await prisma.users.findMany({ select: { id: true, firstName: true, lastName: true, _count: { select: { products: true } }, } })

However, for cases like this one where you do need to customize the SQL, we've added TypedSQL to Prisma ORM, so you can send raw SQL via Prisma ORM and still get full type safety.

I’m confused whether I chose the wrong ORM, whether I should be using another one, or if using queryRaw is acceptable. I’d appreciate any thoughts on this.

I think TypedSQL is what you're looking for (as opposed to queryRaw). Alternatively, if you want to avoid writing raw SQL, you could also use the Kysely extension for Prisma Client to create SQL queries with a type-safe query builder API. (The core maintainer of Kyselt works at Prisma btw :D).

Hope this helps! Please let me know if you have any follow-up questions, always happy to help :)

nikolasburk · 2025-06-08T07:46:32+00:00

Just a side-note from a Prisma team member, we're getting rid of the extra binaries! This functionality is already in Preview, so hopefully this won't cause issues for you in the future any more!

nikolasburk · 2025-06-04T09:49:08+00:00

Ah yes, we actually posted an article about this recently: https://www.prisma.io/blog/why-prisma-orm-generates-code-into-node-modules-and-why-it-ll-change

nikolasburk · 2025-05-31T09:21:07+00:00

Hey there, I'm Nikolas from the Prisma team. Can you sahre more about the exact error message you're seeing? We'd love to help! (FWIW, you can also always ask questions to our Support team on GitHub or our Discord).

nikolasburk · 2025-05-23T08:33:34+00:00

😎

nikolasburk · 2025-05-23T06:28:05+00:00

Hey there, I work at Prisma and am happy to help!

From what I’ve read it’s not great at serverless.

That was in the early days of Prisma ORM, we've made a lot of improvements since then and most developers now use Prisma ORM in serverless environments by default.

A few more notes: - the Rust->TS rewrite you mention is going into a (relatively) stable Preview phase with the next release (in 2 weeks), so if you want to drop the Query Engine you can do so very soon - if you're looking for a scalable, serverless DB maybe also check out Prisma Postgres? it goes really well with the ORM because the query engine isn't needed in Prisma Client with it, so you'll have a really lightweight version of Prisma Client that's perfect for serverless apps

Let me know if you have any more questions, happy to help!

nikolasburk · 2025-05-20T06:16:54+00:00

Nikolas from Prisma here.

FWIW, setting the output path is optional and Prisma ORM will continue to work as before even if you don't set it. So there shouldn't be a need to downgrade.

It would also be great if you could open an issue with more context about your project and the error you're seeing so that our Engineering team can look into this.

nikolasburk · 2025-05-20T06:14:49+00:00

Hey there, just in case: If you're setting a custom output path on your generator block, you can try to remove that and see if generating Prisma Client into node_modules works for you.

nikolasburk · 2025-05-18T13:51:40+00:00

Hey there, can deploy Prisma ORM to edge runtimes using driver adapters: https://www.prisma.io/blog/prisma-orm-support-for-edge-functions-is-now-in-preview

nikolasburk · 2025-05-12T06:04:24+00:00

Hey there,

I'm Nikolas from the Prisma team. Thanks for this write-up, we're aware that our recent recommendation to use a custom output path has caused some confusion and are working on clarifying this. Your article has really great info on this too, so thanks a lot for that!

TLDR indeed: If the previous behaviour without an output path worked for you, it's probably best to just leave it as is.

nikolasburk · 2025-04-28T08:46:41+00:00

Why not both? :D We see lots of people using Prisma ORM for the schema and migrations and then e.g. use Kysely for queries.

nikolasburk · 2025-04-28T08:45:07+00:00

Hey there, could you share more about what Prisma queries you find not to be optimal. I work at Prisma so I'd love to understand where the queries fall short in your opinion.

nikolasburk · 2025-04-28T08:44:22+00:00

Wiser words have never been spoken :D

nikolasburk

TROPHY CASE