Prisma 2.0 Beta: Type-safe Database Access

I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised.<p>With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1]<p>Also Prisma2 has half of the features at &#x27;No &#x2F; Not yet&#x27; supported state - <a href="https:&#x2F;&#x2F;www.prisma.io&#x2F;docs&#x2F;reference&#x2F;database-connectors&#x2F;database-features" rel="nofollow">https:&#x2F;&#x2F;www.prisma.io&#x2F;docs&#x2F;reference&#x2F;database-connectors&#x2F;dat...</a><p>Well makes me wonder what&#x27;s wrong with TypeORM which supports 8 different databases with full feature support and migrations that work!<p>[1] <a href="https:&#x2F;&#x2F;www.prisma.io&#x2F;docs&#x2F;reference&#x2F;tools-and-interfaces&#x2F;prisma-migrate" rel="nofollow">https:&#x2F;&#x2F;www.prisma.io&#x2F;docs&#x2F;reference&#x2F;tools-and-interfaces&#x2F;pr...</a><p><pre><code> Data Validation Cascading delete Cascading update Renaming existing table Renaming existing column</code></pre>

Was really excited about this until I got to &quot;smart node module&quot;. Isn&#x27;t changing the contents of a package in node_modules going to break any kind of caching, de-duplicating etc? In my current project we install node_module` ahead of time and bake it into a docker image, it is quite common.

It&#x27;s alright isn&#x27;t it to get something done fast, until this huge amount of code that you will never understand bites you in the ass.<p>I&#x27;m secretly rewriting an API written in Prisma 1 into something lower level that actually allows me to write database queries, optimise what is going on, look into the <i>simple</i> underlying abstractions if things go wrong and essentially produce something I can reason about without just hoping nothing goes wrong under the hood.<p>Apollo codegen is what you want if you&#x27;d like your Typescript frontend to be consuming the API in a typesafe way.

I don’t know why this is not getting more up votes it looks pretty cool.<p>At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain.<p>I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage.<p>I’m not sure how it feels in practice, if anyone has experience with it please chime in.

The fact that the returned objects are plain old javascript objects (POJOs) that&#x27;s nice.<p>The smart module bit, it&#x27;s a bit scary.<p>basically all I want is a lightweight layer that exposes a promise api to deal with different databases in a uniform manner.<p>1) sync to schema.json (this json file contains info of all tables, their columns, indices and foreign keys). I can sync to db or from db. This lets me have my state of schema committed to git, and easily move from dev -&gt; staging -&gt; prod. Django migrations are a giant pain in the ass. Don&#x27;t do smart fancy node modules either.<p>2) autogenerated typescript types, this are nice. But again don&#x27;t do fancy node modules, have the typescript types committable to git repo. It makes it easy to diff and bisect when things fo awry.<p>3) Super light weight Object -&gt; sql. Access foreign relationships as promises (always). Make it very easy to debug the generated sql for perf reasons. Django does some bits well but it&#x27;s insanely slow at times. Doing things with raw sql should be just as fast as using a library.

Why on earth did Prisma take the choice to move away from a brilliant automatic GraphQL backend as a service to some kind of weird ORM?<p>Prisma became relevant during their Prisma 1 time, it was one of the first solutions to automatically generate GraphQL endpoints from DB schemas. It only had to keep going this way to lead the whole market. But they chose not too, and competing solutions such as Graphile beats prisma 1 so much now.<p>Meanwhile they have been stuck for 2 years in their new weird direction of Prisma 2, with no results to show for, and no clear vision. The GraphQL server is gone, even though it was central to their product. Who cares about yet another ORM? I can generate types from any GraphQL endpoint automatically anyway!

This looks great and should surely cover most of the CRUD needs of simpler apps and hopefully even more. On the other hand, in my experience such complicated abstractions eventually leak, especially due to the complicated nature of the relational model and modern SQL.<p>For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1].<p>In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has:<p>1) Realtime parameter&#x2F;result type inference in their language of choice.<p>2) Has autocomplete and validation in their IDE<p>3) Is composable, allowing to join queries&#x2F;sub-queries..<p>So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;adelsz&#x2F;pgtyped" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;adelsz&#x2F;pgtyped</a>

I have been using it for a new project and it really is awesome. I can&#x27;t imagine going back to an ORM or another query builder now.

This seems to be solving mostly the same problem as the following libraries:<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;phiresky&#x2F;ts-typed-sql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;phiresky&#x2F;ts-typed-sql</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;Ff00ff&#x2F;mammoth" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Ff00ff&#x2F;mammoth</a> [3] <a href="https:&#x2F;&#x2F;github.com&#x2F;AnyhowStep&#x2F;tsql" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;AnyhowStep&#x2F;tsql</a> [4] <a href="https:&#x2F;&#x2F;github.com&#x2F;travigd&#x2F;vulcyn" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;travigd&#x2F;vulcyn</a><p>A query in one of those looks like the following:<p><pre><code> const rows = await select(list.id, list.createdAt) .from(list) .where(list.createdAt.gt(now().minus(`2 days`)).or(list.value.eq(0))) .limit(10); </code></pre> The resulting type of `rows` is inferred by TypeScript to the corresponding correct type (`{id: string, createdAt: Date}`)<p>Prisma solves the problem by generating code, while all of these do it completely in type-level within typescript. Prisma also seems to introduce its own query language, while the above linked libraries stay closer to SQL.<p>[1] was written by a friend of mine and I&#x27;m using it in production to great success. I wouldn&#x27;t recommend it though because it has repeatedly broken with new TypeScript updates since it uses very complex type structures and the dev has basically given up on it due to the complexity.<p>[2] is probably the most production-ready, though it has some design choices I&#x27;m not sure about.<p>[3] is the most well-designed, and can handle complex scenarios (including differentiating between join types etc). But it&#x27;s incomplete so far.<p>[4] I have not used.<p>Pure type-level has the advantage of not adding a compile-step and keeping everything in a tool you already know. But all of the above have the disadvantage that the resulting type structures are very complex - most TS devs would have a hard time understanding the internals of the libraries and the resulting type errors can be unreadable. They can also cause the TS compiler to slow down significantly (in the past [1] had exponential compile time when adding a new column, though this has been fixed).<p>Also, since the TS compiler uses heuristics in multiple places and the type system is not sound, Microsoft has introduced regressions that have broken [1] in every other release.

Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project and it&#x27;s been a pleasure to work with.

Those, who prefer a more old-school approach, may find PgTyped [1] interesting: you write SQL and you have typings in TypeScript. Still very alpha, but promising.<p>I&#x27;m working on integrating PgTyped into Huncwot [2]<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;adelsz&#x2F;pgtyped" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;adelsz&#x2F;pgtyped</a> [2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;huncwotjs&#x2F;huncwot" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;huncwotjs&#x2F;huncwot</a>

Edit: please read nikolasburk&#x27;s answer below which makes a lot of sense. The docs weren&#x27;t an attempted attack on all ORMs but rather a description of problems with certain Javascript ORMs.<p>My original post:<p>This looked interesting at first but this reads like someone either don&#x27;t know a thing about JPA and Entity Framework or are deliberately misrepresenting them:<p>&gt; ORMs are libraries that map tables in your database to classes in your programming language. Prisma on the other hand is an auto-generated query builder that exposes queries which are tailored to your models. All Prisma Client queries return plain old JavaScript objects.<p>Yep, tables maps to classes, but guess what gets returned?<p>Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages well thought out design and extensive metaprogramming abilities this can all be done without making up a new language also.<p>This is probably the harshest I&#x27;ve been here on HN, but smearing good solutions really doesn&#x27;t sit well with me.

I LOVE massivejs[1], a query builder type library for Postgres in nodejs. Is prisma2 like massivejs but for typescript?<p>If someone’s tried both, would love a quick comparison :)<p>[1] <a href="https:&#x2F;&#x2F;massivejs.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;massivejs.org&#x2F;</a>

How does this compare to TypeORM? First time hearing about this project, and it looks interesting

We started using Prisma 1 for our project and ran really fast into missing features that are really missing for a complete product.<p>But with a few workarounds it was possible to make it work and is quite nice to use.<p>Example of missing features:<p>Primary key as a combination of two relational models: <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;3553" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;3553</a><p>Database Constraints <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;728" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;728</a><p>Cascading Deletes <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1262" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1262</a><p>Upsert <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2194" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2194</a><p>On delete restrict <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2701" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2701</a><p>Mutation CreateOrConnect <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;3724" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;3724</a><p>Improving performance with Indexes <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1300" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1300</a><p>Multiple field unique constraint <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;171" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;171</a><p>Interface types <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;83" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;83</a><p>Embedded Types <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2836" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;2836</a><p>Declarative support for multi-field unique constraints <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1237" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;1237</a><p>Support union types <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;165" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;165</a><p>Transactions for multiple mutations <a href="https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;74" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;prisma&#x2F;prisma1&#x2F;issues&#x2F;74</a>

I’ve been using Prisma in development and highly recommend it. There’s nothing like it out there!

How does it differ from Hasura?

Not getting warm with any query&#x2F;ORM library out there.<p>My own take of interfacing with an SQL database with Typescript: a query generator that uses mapped types a lot to infer result set types from queries and a schema file.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;hoeck&#x2F;typesafe-query-builder" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;hoeck&#x2F;typesafe-query-builder</a><p>Not sure if thats a good idea and if the Typescript inference even scales that well when using lots of tables.<p>Any feedback and criticism would be welcome.

Why generate types from a query when you can write a schema for your objects and then write queries where types can be inferred based on object types and query constructs?<p>Some ideas from a recently open sourced project:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;facebookexperimental&#x2F;fquery&#x2F;blob&#x2F;master&#x2F;tests&#x2F;test_operators.py" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebookexperimental&#x2F;fquery&#x2F;blob&#x2F;master&#x2F;t...</a>

Makes sense, non-type-safe language, we can push type safety guarantees to the persistence layer by coupling the domain models to the type-safe data models.

Looks very interesting. At the moment we&#x27;re using a Node.js + Postgres + Sequelize ORM [1] + Express setup in production and are very happy. All lot of features and very robust setup.<p>Any production ready experience with Prisma?<p>[1]: <a href="https:&#x2F;&#x2F;sequelize.org&#x2F;v5&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sequelize.org&#x2F;v5&#x2F;</a>

Hi there, I&#x27;m a prisma 1 user and am wondering if there is thorough docs on how to transition over to prisma 2.<p>Also what breaking changes or not-yet-implemented features of prisma1 should I be aware of.<p>----<p>Edit: I see there&#x27;s a &quot;I currently use Prisma 1, what should I do?&quot; section. Any other info would be greatly appreciated.

Is mongo support in yet? I tried the Prisma2 beta a couple of months ago and it was still on the way.

I wish I was not stuck on Ms SQL server. The JS ecosystem tends to ignore it or treat it as a second class citizen. Would love to check this out otherwise.

Will SQL Server databases be supported at some point?

Looks cool! Is there a business model around prisma?

Does this work with pnpm since node_modules&#x2F;@prisma&#x2F;client changes based on the project it&#x27;s in?

Is real-time subscriptions on the roadmap? It&#x27;s the most killer feature of Hasura and Postgraphile IMO.

So is that some sort of &quot;ActiveRecord&quot; for Javascript? It looks pretty darn cool.