nikolasburk

https://www.learnchess.ai — The chess app I always wanted (I've tried a lot of apps in the last years but they always lacked some fundamental feature and/or had terrible UX).

Author of the blog post here, let me know in case you have any questions around the Prisma Postgres stack!

I wrote the blog post for this, feel free to drop any questions and the Prisma team will help!

Hey there, I worked on the benchmarks from the Prisma-side.

First off: Thanks for your feedback and questions, we're trying to create a meaningful comparison of ORMs and will be iterating on the benchmark setup and re-run them at some point, so your input is very much appreciated!

It's not clear how many records were generated in the sample dataset for these benchmarks.

To clear the confusion: We've indeed used a sample size of 1000 records for the benchmark. If you click on the hyperlinked "real-world infrastructure" in the intro paragraph on benchmarks.prisma.io, the pop up shows you this information.

I'm more interested in what latency and resource consumption look like for each query under any type of load.

This is great feedback and we were already considering adding this kind of information to the next iteration of the benchmarks. Thanks for this input!

The issues that we were seeing with Prisma [3] were latency in acquiring a connection and executing a query when many queries were running simultaneously (with idle connections available in the pool and a high connection limit on Postgres).

That sounds like something our Engineering team may want to look into! Did you by any chance create a GitHub issue for this? It would be super helpful for the team to have more context on the issues you're describing here, so they can get fixed.

I'd also be curious about the difference in performance for something like a nested `updateMany` where depending on how the query is generated, could deadlock or place a lock on more rows than necessary -- and where the generated queries actually matter.

This is something that hasn't been on our radar yet but I'm taking a note off for the next benchmark iteration as well!

Thanks again, please let us know if you have any further questions about Prisma or the benchmarks.

Our pricing for Prisma Postgres indeed presents a bit of a mental shift compared to traditional database providers:

We charge for query volume, not for compute!

We believe that ultimately this is a more intuitive way for developers to think about database cost.

Generally, our goal is that developers need to only think about _queries_ — we'll take care of everything else to make sure those queries can run efficiently. Developers shouldn't need to worry about compute, scaling, downtime, etc.

I just answered the same questions on Twitter [1], so just quoting that:

Neon is a lot more feature-rich right now (since PPG just came out) and has awesome stuff like branching.

On the long-run, we expect to have a similar feature set. Additionally, our underlying tech has the benefits of avoiding cold starts and likely being more cost-effective.

That being said, I see it as a major benefit that with Prisma you not only get a DB but an entire data layer (incl global caching and real-time DB events) thanks to the first-class integration of our other products like Accelerate and Pulse [2].

[1] https://x.com/nikolasburk/status/1851522983346532669

[2] https://www.prisma.io/blog/announcing-prisma-postgres-early-...

Nikolas from Prisma here! I've been around for almost 8 years (since the Graphcool days) and this description is pretty accurate but I can add a bit more color. The major product evolutions we've had were:

- Graphcool: A GraphQL BaaS written in Scala.

- Prisma 1 (see [1]): A GraphQL proxy server between DB and app server. This was essentially the "GraphQL engine" of Graphcool that we ripped out and made it available as an open-source component. However, its auto-generated CRUD GraphQL API never was meant to be consumed by a frontend. Instead, it was the abstraction layer for the app server to interact with the DB (at first only for GraphQL APIs on the app server via `prisma-binding`, then the first version of Prisma Client that worked with any API layer — both of these were thin JS/TS layers that talked to the GraphQL proxy server where the actual DB queries were generated).

- Prisma 2+ aka Prisma ORM (see [3]): We realized that with Prisma 1, we were essentially competing with ORMs but that our architecture was way too complex (devs needed to stand up and manage an entire server where other ORMs could be used with a simple `npm install`). So, we rewrote the Scala "DB-to-GraphQL" engine in Rust to be able to provision it via a download during `npm install` and run it as a sidecar process on the app server, added a migration system and Prisma ORM was born. That being said, it has evolved a lot since then. We dropped GraphQL in favor of a way more efficient wire protocol [4] and have continuously reduced the footprint and responsibility of the query engine (e.g. you can now use Prisma ORM with standard Node.js DB drivers [5]).

If you want more details, I talked more about this evolution on Twitter [6] a while ago.

This launch is a huge milestone for us and it's definitely one of the most exciting launches I've been a part of at Prisma!

[1] https://www.prisma.io/blog/prisma-raises-4-5m-to-build-the-g...

[2] https://github.com/prisma-labs/prisma-binding

[3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

[4] https://www.prisma.io/blog/prisma-5-f66prwkjx72s

[5] https://www.prisma.io/docs/orm/overview/databases/database-d...

[6 ] https://x.com/nikolasburk/status/1384908813069869058

If you're already looking at Next.js + Tailwind but unsure about what to use for the DB, I'd recommend checking out the T3 stack [1].

It uses tRPC [2] for type-safe API calls and Prisma [3] for your DB. There's lots of content out there teaching how to use this stack to build sophisticated apps (e.g. this in-depth tutorial teaching how to build a social media app [4]).

Disclaimer: I work at Prisma and am also a huge fan of type-safety, so T3 is basically my dream stack.

[1] https://create.t3.gg/

[2] https://trpc.io/

[3] https://www.prisma.io/

[4] https://www.youtube.com/watch?v=jqVm5_G1ZEE&ab_channel=WebDe...

The Playground is an interactive learning environment for Prisma. Learn how to send database queries and explore migrations workflows with the Prisma ORM.

This looks fantastic, congrats to the launch!

Is there any post which goes into evolution of prisma from initial days of exposing graphql API directly to using it as wire protocol in the query engine?

To be honest, I think the most comprehensive resource for this is a Twitter thread [1] that I posted from my personal account that explains the different turns we took in the product direction :D

Otherwise, there's yhr blog post "How Prisma & GraphQL fit together" [2] that also touches on the same topics but might be a bit dated since it was published before we released the Prisma ORM for production use.

And now the likely removal of graphql as wire protocol. What are the key reasons to remove the use of graphql query language?

The short answer is that it would allow us to make us more optimizations for the bridge between JS- and Rust-land in Prisma Client. However, this is not an urgent issue for us at the moment so very likely won't become a priority in the near/mid-term future.

[1] https://twitter.com/nikolasburk/status/1384908813069869058

[2] https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c

Hey there, I'm Nikolas from the Prisma team. Just came here to quickly clarify this notion:

Prisma is an API server that puts a GraphQL API in front of a DB.

Prisma is an ORM which generates a JavaScript/TypeScript client library for your database.

Your description is very true for Prisma 1 (which has been in maintenance mode for several years and is officially deprecated by now [1]), but the latest version(s) of Prisma (v2+) don't expose a GraphQL API any more. Prisma 1 also used GraphQL SDL for data modeling, the Prisma ORM on the other hand has its own, custom modeling language for describing database schemas in a declarative way and also comes with a flexible migration system.

That being said (and as Jens also mentioned elsewhere), the Prisma ORM does use GraphQL _internally_ as a wire protocol. However, as a developer, you _never_ touch this internal GraphQL layer and are not even supposed to be aware of it (you actually have to jump through a lot of hoops to even "find" it). It's also very likely that we'll replace GraphQL as a wire protocol in the future, so "GraphQL" really isn't something you should be thinking about as a developer who is using Prisma.

Hope that clarifies the situation a bit, let me know if you have any further questions around this topic.

[1] https://github.com/prisma/prisma1/issues/5208

Hey, Nikolas from Prisma here.

4. All the GraphQL Backend-as-a-Service like Prisma, Hasura etc...

Just wanted to quickly drop in to clarify that Prisma is not a GraphQL-as-a-Service tool any more but an ORM that gives you a type-safe JavsScript/TypeScript client for your DB and a migration tool. The main differences between Prisma 1 and the Prisma ORM (i.e. Prisma 2+) are explained here: https://www.prisma.io/docs/guides/upgrade-guides/upgrade-fro...

If you want to learn about Redwood, I'd also recommend Amy's talk about it from Prisma Day two weeks ago: https://www.youtube.com/watch?v=_zJ44wmo1Ro&ab_channel=Prism... :)

Hey there, I work at Prisma — awesome to hear it's been serving you well!

Since you mentioned NestJS, I just wanted to quickly plug a comprehensive tutorial that we've published today that explains how build a REST API with NestJS, Prisma, Swagger and PostgreSQL. I think it gives a really nice overview of the main workflows and best practices when using these tools together!

You can find it here: https://www.prisma.io/blog/nestjs-prisma-rest-api-7D056s1BmO...

This looks really cool!, congrats for the launch!

I noticed you're using Sequelize as an ORM for the Node.js version and was wondering if you evaluated other libraries for that.

I work at Prisma [1] and we're building a new kind of ORM for Node.js and TypeScript. We've also seen that many library authors (e.g. KeystoneJS, RedwoodJS, Blitz, Amplication, Wasp, ...) [2] and fullstack templates like Bedrock [3] are picking Prisma as their ORM instead of tools like Sequelize, TypeORM or lower-level libraries like knex.js.

I'm just curious to learn whether you were aware of Prisma and what made you pick Sequelize for this project in case you evaluated other options too :)

[1] https://github.com/prisma/prisma

[2] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

[3] http://bedrock.mxstbr.com/

Nice, thank you for digging these up!

I do find it confusing I always thought Prisma was GraphQL related.

This is a common misconception that stems from our history as a company and being early contributors to the GraphQL ecosystem. With the move to Prisma 2 however, there is no native GraphQL layer in Prisma any more. I've talked about this extensively in a recent livestream on Youtube [1] if you want to learn more :) There's also this article "How Prisma and GraphQL fit together" [2] that explains the historic dimensions of this if you're interested.

It's unclear what's the pros are of Prisma compared to TypeORM.

I guess you could argue that one benefit is the superior type-safety Prisma provides [3]. Other folks have also called out that they prefer way how data is modeled with Prisma (via the Prisma schema), the migration system as well as the active maintenance, regular releases, the active community, the support and thorough documentation of Prisma. Ultimately it'll come down to your personal preference though which one is the more appropriate for your project :)

[1] https://www.youtube.com/watch?v=hMWMPpy4ta4&list=PLz8Iz-Fnk_...

[2] https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c

[3] https://www.prisma.io/docs/concepts/more/comparisons/prisma-...

It means that Prisma will provide a data access layer (we call it "application data platform" [1]) similar to the custom data access layers built by big companies [2] (e.g. TAO by Facebook or Strato by Twitter) that enables application developers to better access their databases.

We've explained that in the blog post here in the "Open-source, and beyond"-section [3].

Does that help? :)

[1] https://imgur.com/O1lwo0v.png

[2] https://imgur.com/Hb9VOWN.png

[3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

Transactions are supported in Prisma, see this guide in our docs [1].

I guess the post refers to our opinionated stance on "long-running transactions" which Prisma indeed does not at the moment. The best resources to learn about this are on GitHub [2] and our blog [3].

[1] https://www.prisma.io/docs/guides/performance-and-optimizati...

[2] https://github.com/prisma/prisma/issues/1844

[3] https://www.prisma.io/blog/how-prisma-supports-transactions-...

This is a pretty extensive list! Are all of these points are full blockers for you or are there individual points that you care more about while others might be rather "nice to have"? If most of them are real blockers, you probably shouldn't use Prisma [1], and that's ok :)

Prisma certainly is not perfect and whether you should use it depends on your project and individual requirements. What I can tell you is that we are shipping releases [2] with new features and improvements every two weeks. We are also very eager to learn about more use cases that people want to accomplish with Prisma. The best way to bring these to our attention is by commenting on existing GitHub issues and creating new ones if the one for your use case doesn't exist yet. This helps us prioritze and implement these new features. We also have a roadmap [3] where you can see all the features that we are currently working on.

Hope that helps for now!

[1] https://www.prisma.io/docs/concepts/overview/should-you-use-...

[2] https://github.com/prisma/prisma/releases

[3] http://pris.ly/roadmap

Just as a side-note, we have migration guide from Prisma to TypeORM in our docs: https://www.prisma.io/docs/guides/migrate-to-prisma/migrate-...

https://news.ycombinator.com/item?id=26888735

Fully agree, Zapatos is super nice – and so are similar tools like pgtyped and Slonik. We actually mention all these in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-...

I think the main difference of these libraries compared to Prisma is the level of abstraction. If you want to work with SQL and you appreciate type-safety, then all of these tools will be fabulous options for you! If you want to work on a somewhat higher level of abstraction but still have full type-safety, Prisma will be more appropriate.

:heart:

We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes.

The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.

pgtyped is awesome! We mention it along with similar tools like Slonik and Zapatos in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-...

We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes.

The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.

This statement is certainly provocative (great that it was the first thing picked up here :D) but I'm happy to explain our rationale for this a bit more.

SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations.

SQL is complex, it's easy to shoot yourself in the foot with and its data model (relational data / tables) is far away from the one application developers have (nested data / objects) when working in JS/TS. Mapping relational data to objects incurs a mental as well as a practical cost!

This is why we believe that in the majority of cases (which for most apps are fairly straightforward CRUD operations) developers shouldn't pay that cost. They should have an API that feels natural and makes them productive. That being said, for the 5% of queries that need certain optimizations, Prisma allows you to drop down to raw SQL and make sure your desired SQL statements are sent to the DB.

I see Prisma somewhat analogous to GraphQL on the frontend, where a similar claim could be: "Frontend developers should care about data, not REST endpoints". GraphQL liberates frontend developers from thinking about where to get their data from and how to assemble it into the structures they need. Prisma does the same by giving application developers a familiar and intuitive API.

Hey, Nikolas from Prisma here!

Can you elaborate what exactly you mean with "GraphQL integration"? You might be referring to Prisma 1 which was a "GraphQL layer for your database". Prisma 2 (which we are referring to with this article) doesn't have a native GraphQL integration any more :)

Prisma is very different from Sequelize in various ways (see our docs [1]):

- Your data model lives in the Prisma schema

- Database access doesn't happen via model instances but via the Prisma Client API [2] which always returns plain JS objects making your queries much easier to reason about - Prisma Migrate auto-generates migrations based on your data model (and lets you customize these migrations when needed)

- Prisma comes with Prisma Studio out of the box – a modern database GUI

- Prisma is not a community-project but built by a VC-funded company

– We care a lot about our community, documentation, and providing support (something we've seen lots of developers complain about with other ORMs)

[1] https://www.prisma.io/docs/concepts/more/comparisons/prisma-...

[2] https://www.prisma.io/client