
Prisma – Database tools for modern application development - octosphere
https://www.prisma.io/
======
yodon
Back when prisma was emerging out of graphcool, every google documentation
search sent me to graphcool, every graphcool page was full of broken links,
and the shiny new prisma docs were unusable (including unviewable on my iPad
that I use for researching tech I might use while sitting on the couch). It
painted such a clear picture of a company that absolutely does not get the
importance of API documentation to the success of an API that I've never been
able to get myself to go back and give them a second evaluation.

Does their documentation today feel like the doc team and technical writing
team have an actual seat at the table or does it still feel like the place is
run by a bunch of architecture astronauts who think docs just happen after the
fact?

~~~
timsuchanek
Thanks for your upright feedback! You must have caught us in a bad moment, in
the transition one year ago from Graphcool to Prisma we indeed needed to do a
lot of work in the docs. Nowadays the Google experience should be much better,
while our docs actually represent the product.

Would be great if you can give it another try, as I'm convinced that the docs
improved significantly over the last year. Disclaimer: I work at Prisma.

~~~
yodon
They do look a lot better now in a way that suggests the doc side is maybe
getting some actual love and attention. Will try to carve out some time to dig
deeper.

------
welder
It's been interesting watching Prisma, formerly Graphcool, transition from
backend-as-a-service to open source backend to client ORM library. They also
use bleeding edge patterns, so I always know where to go for examples as stuff
gets adopted mainstream :) Keep up the good work Prisma team!

Question specific to this autogenerated client: does that mean I have to bump
client version numbers every time my backend schema changes? Does this help if
I'm building a backwards-compatible api, like Stripe's API [1]? Apologies if
this is already answered in your docs.

[1]: [https://stripe.com/blog/api-versioning](https://stripe.com/blog/api-
versioning)

~~~
jhalstead
> They also use bleeding edge patterns, so I always know where to go for
> examples as stuff gets adopted mainstream :)

Do you have specific examples of cutting edge patterns they use that you can
share? I'm always interested in seeing concrete examples of (often) abstract
patterns/concepts.

------
simplify
Prisma looks good and I hope it succeeds.

Another interesting and unique approach I'd love to see get more attention is
Mammoth[0]. Instead of abstracting the database away, you define columns using
its raw primitives (in this case, Postgres) and in return get a type-safe
client, along with auto-generated migrations.

I imagine this approach allows you to leverage the features of the database
much more easily. And Postgres has quite a lot of rich features to take
advantage of! :)

[0]: [https://github.com/Ff00ff/mammoth](https://github.com/Ff00ff/mammoth)

~~~
martijndeh
Right, instead of abstracting away the database I think it makes sense to
invest in making it attractive to use. Putting an abstraction layer (like ORM)
on top of it basically hides it's amazing features.

PS. maintainer of mammoth here. Thanks for the mention.

~~~
nikolasburk
I totally agree with this and this is actually very relevant for us at Prisma
as we're supporting various kinds of databases. Our goal isn't to have one
universal data access abstraction, but instead we want to ensure developers
still get all the benefits of the databases they're using underneath (as all
of them have different strengths and are great for different use cases)! We're
currently working on an improved version of our data modelling language that
will make it possible to model DB-specific properties (indices, special DB
types, ...) into your Prisma datamodel, you can find the RFC for it here:
[https://github.com/prisma/rfcs](https://github.com/prisma/rfcs)

PS. We've looked into mammoth a lot for inspiration and really liked it, great
work!

------
glutamate
How is this different from any other ORM library?

~~~
matthewmueller
You can think of Prisma as the next version of ORM technology. Prisma shares
the same goals of an ORM (make data access easy), but takes a completely
different approach than past ORMs.

Prisma uses introspection to generate a feature-rich, type-safe library around
your database's schema to reduce or eliminate most of the downsides you
traditionally associate with ORMs.

 _Type safety_

Today's ORMs rely on query builders (e.g. _await select( 'users').where('id',
10)_) or hand-written classes (e.g. _class Product < ApplicationRecord_) to
map an object to a row. Prisma looks to the database for the information about
types and relationships to generate type-safe code specific to your database
in every language (e.g. _prisma.Products.FindByName( "Sponge")_).

 _Bugs caught at compile-time_

Another downside of today's ORMs most of them break at runtime, rather than
compile time. By generating type-safe database clients, Prisma eliminates any
opportunity for breaking database changes to go unnoticed and end up in
production.

 _Better performance_

There are a couple advantages of Prisma has over traditional ORMs and raw SQL
queries:

• The core of Prisma is written in Rust to have predictably high-performance
and flexible caching.

• Prisma is written by database experts and administrators who have seen every
database schema under the sun.

 _Fewer Leaks_

Because Prisma has a holistic view of your database's structure, Prisma can
generate an API that is better tailored to your application than a traditional
ORM. There may be times when you still need to write raw database queries and
Prisma will support these escape hatches, but those times are rare and are
becoming less common every day.

------
tathougies
I will never understand the desire to add ever more layers to well understood
patterns and services. I fail to see the value add of prisma over any decent
database.

~~~
Aeolun
It’s not a database.

SQL isn’t typed. And writing migrations and client libraries is otherwise
painful. That’s basically the value add.

~~~
tathougies
Sql is not only typed, its very strongly typed. Please dont confuse the lack
of explicit annotations in typical sql for a lack of types. Sql is the
prototypical killer app for type inference. Its so good, most people think
it's untyped

~~~
Aeolun
Right. I think it was fairly clear what I meant, since Prisma cannot really
help to change postgres internals (and strict typing in mysql is a bit
hit&miss in the first place), but for the sake of everyone else reading this:

SQL results, coming without any translation layer, are untyped. Your result
could be anything from a string to an array with an infinite number of fields.

It doesn’t really get more structure than this big array either, regardless of
table representation.

Prisma helps with that.

~~~
jacques_chester
> _SQL results, coming without any translation layer, are untyped._

That would depend on the database's wire protocol, wouldn't it?

~~~
Aeolun
Do I really have to qualify this with ‘mainstream databases, with mainstream
client libraries, in nearly all major languages’?

~~~
tathougies
Mainstream databases like Postgres and SQL server (and MySQL too I think) all
return type information with their results. Having written wire protocol
clients for these, I flat out reject your claim that SQL isn't typed at the
results level. It's one of the few places in common usage that the types are
explicitly stated. Whether or not your client libraries reflect that is a
different issue (and if they don't, I encourage you to use something better).

------
turboturbo
I’ve tried Prisma over the last few months, but eventually decided against
adopting it in our product because it seems very inflexible when working with
many-to-many relationships. In particular, filtering on foreign keys doesn’t
seem possible and requires SQL table joins, which (in our case) has an
immensely negative performance impact. Also, the query chaining API doesn’t
lend itself well to filtering on multiple relationships. Apart from that, the
idea seems really cool and I’m sure the project has a great future ahead of
it!

~~~
Aeolun
Forgive me if I’m missing something here, but joins seem pretty much the only
way to do performant foreign key filtering to me.

Is this not what you were talking about?

~~~
kilburn
It wasn't my question, but I would assume the caveat they were complaining
about is that prisma forced them to perform the join when filtering the
original table by just the foreign key (think select * from books where
author_id = ? ... no join to aauthors needed here, but some ORMs do that join
anyways)

------
hokumguru
I've been using Prisma for most of the last year in personal projects and I
have to say it has been the absolute easiest database layer I've ever used. My
development experience has been immensely streamlined.

~~~
nikolasburk
I work at Prisma and it's really awesome to hear such feedback! Please let us
know if you have any further questions, we're happy to help :)

------
tdhz77
Unless you have specific requirements, Ive always found prisms to be bloated /
heavy. I prefer Hasura.

~~~
aclemmensen
Do you have examples of specific requirements for which Prisma would be a good
fit?

~~~
crucialfelix
Prisma is good for writing data models, running migrations. The new admin is
very usable already, although still beta. I've been very productive loading,
editing and querying data.

Hasura I think is good for preexisting db, no migrations? I haven't evaluated
it fully.

~~~
tango12
(I work at Hasura)

Yep! We’ve put in a lot of effort to ensure hasura Just Works on an existing
db.

Incidentally, to address your last point, Hasura has its own rails like
migrations system and an admin UI (that allows DDL and DML) and works well
with your existing migrations tooling too if you have it already. The hasura
admin UI can create the rails style migration files automatically on your disk
as you work on the UI.

[https://hasura.io/all-features](https://hasura.io/all-features)

~~~
lewisl9029
First time learning about Hasura. Looks really promising with the built-in
_live queries_ support, which Prisma has not yet implemented (they only have
subscriptions):
[https://github.com/prisma/prisma/issues/1205](https://github.com/prisma/prisma/issues/1205)

EDIT: Never mind, looking at the docs, it looks like they also only support
subscriptions... It's understandable to not have support for live queries yet,
as it's still a very under-explored territory, but it's still misleading
marketing on their part because they explicitly call out support for
subscripts _and_ live queries on their website.

Curious how Hasura tackles the N+1 problem for efficient querying in GraphQL?
Prisma uses a built-in dataloader implementation for this but I couldn't find
anything about query optimization in the Hasura docs.

Also, in the docs on pagination:
[https://docs.hasura.io/1.0/graphql/manual/queries/pagination...](https://docs.hasura.io/1.0/graphql/manual/queries/pagination.html)

I'm only seeing examples of offset-based pagination. Is cursor-based
pagination on the roadmap as well?

~~~
tango12
Answering a few points:

Hasura allows you to turn any "query" to a subscription, essentially live
queries.

Hasura's query optimization is actually one of the core features. Hasura is
structured as a transpiler that converts GraphQL, adds access control clauses
and then renders a single SQL for the database. Very different from a typical
ORM approach or the dataloader approach.

More details: [https://blog.hasura.io/architecture-of-a-high-performance-
gr...](https://blog.hasura.io/architecture-of-a-high-performance-graphql-to-
sql-server-58d9944b8a87)

------
mxstbr
We have been using Prisma for our newest project, and have really enjoyed it!
The development experience is unparalleled in the Node.js world, it lets us
move so quickly.

There are some rough edges, but the team is very responsive and they have
fixed most of my minor gripes over the past months.

Overall I am happy we chose it and I would choose it again.

~~~
nikolasburk
Thanks a lot for the feedback Max, we really appreciate it! We're currently
working on many improvements (e.g. a more powerful data modelling syntax, a
sophisticated migration system, opening up the database connector and client
generator APIs, ...) for Prisma that you can check out in our RFCs:
[https://github.com/prisma/rfcs](https://github.com/prisma/rfcs)

------
c036
I've been using Prisma in for some months now (even in production), and I'm a
big fan of the product. With TypeScript you have an easy full autocompletion &
type checking over your models, and coupled with a graphql-yoga server &
graphqlgen for the exposed GraphQL part it has been a pretty nice experience.

The downside is (because there is always some), as it's a new tech, problems
can pop up and more research have to be made compared to a more old and
popular framework.

In any case, I highly recommend you to try it on your own, I'm looking foward
to its futur improvements.

~~~
nikolasburk
Thanks so much for your positive feedback, we really appreciate it! We indeed
have many exciting improvements in the store, to get an overview of those feel
free to check out our RFCs:
[https://github.com/prisma/rfcs](https://github.com/prisma/rfcs) Also, if
you're building a GraphQL server you might want to check out GraphQL Nexus
which is an alternative to the SDL-first approach taken with `graphqlgen`:
[https://www.prisma.io/blog/using-graphql-nexus-with-a-
databa...](https://www.prisma.io/blog/using-graphql-nexus-with-a-database-
pmyl3660ncst)

------
Improvotter
To be fair. That Golang implementation looks overly verbose. I mean compare
the Typescript and Golang implementation. The Golang one isn't even readable.
I'd personally use something else instead.

~~~
mavilein
That is a fair point. The current Golang implementation is the first one we
did. Right now we are working on a new version of the Prisma Client. And the
Golang version will get a lot of love over the coming weeks.

------
viksit
Pardon the ignorance because the site isn’t super clear - but is this just an
ORM library for the JavaScript/Typescript ecosystem? How does it “replace” a
traditional ORM exactly?

~~~
chrisco255
It's a GraphQL ORM and it runs in it's own process on top of whatever db you
have, whether Mongo or Postgres. You can use it with any programming language
but I think their support is best for Node and Go.

~~~
viksit
Ah so this is similar to Hasura.

~~~
nikolasburk
I work at Prisma, we've recently written a blog post about exactly this
question where we also compare Prisma to other services like Hasura or AWS
AppSync: [https://www.prisma.io/blog/prisma-and-graphql-
mfl5y2r7t49c/](https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/)

~~~
joshstrange
Relevant parts:

> Comparing Prisma to AWS AppSync & Hasura

> With the new understanding of the role of Prisma's CRUD GraphQL API, it
> becomes clear that Prisma is not in the category of "GraphQL-as-a-Service"
> anymore.

> Tools like AWS AppSync and Hasura provision a generated GraphQL API for your
> database (or in the case of AppSync also other data sources). In contrast,
> Prisma enables simplified and type-safe database access in various
> languages.

------
hn_reddit_human
Hm... is this is like JOOQ[1] for non-Java languages? Or maybe more like a
typed version of massivejs[2]?

[1] [https://www.jooq.org/](https://www.jooq.org/) [2]
[https://massivejs.org/](https://massivejs.org/)

~~~
rishav_sharan
Sorry for being out of context, but why is your name in green? This is the
first time I have seen a green name in HN.

~~~
Illniyar
new accounts (below 14 days I think) are colored green.

------
beders
Looks like the traditional caveats for ORMs would apply here. Many painful
lessons have been learned in that field.

What would be interesting to see is the cost of change i.e. how de-coupled
things are to make changes simple.

Changes like: Adding a field To changing a relationship between entities and
such.

~~~
timsuchanek
That's a good question. As long as you have additive changes, Prisma can do
the change automatically for you. As soon as it's a change where anything will
be dropped (field, relationship etc), Prisma will prompt you and ask if you
want to perform that breaking change. The only command you need to know for
data model changes is `prisma deploy`. Disclaimer: I work at Prisma.

~~~
hokumguru
As someone who has been using Prisma religiously for the past year, I would
like to express that this is the largest pain point of working with the
platform. Not having the ability to custom define these transformations is
brutal.

~~~
derdude
That is great to hear! Because we're working on exactly fixing that! What is
the concrete limitation you're hitting with that?

------
coleifer
Is this a library? A server? Something else? It looks like a business, so
what's for sale?

~~~
nikolasburk
(I work at Prisma)

Prisma is open-source and you are typically running it in production by
running it on your own cloud infrastructure.

The commercial parts of Prisma are called Prisma Cloud and Prisma Enterprise.
Prisma Cloud aims to simplify various Prisma workflows such as server and data
management, monitoring, backups, migrations/rollbacks, ... We're also planning
a "Prisma Serverless" offering so you don't need to host the Prisma server
yourself.

------
shean_massey
When I first saw prisma I was blown away but after a couple months of trying
to get a production ready system online I was just fed up with the "schema
first" pattern. Wasted way too much time adapting the schema for custom types.
I was about take it behind the shed and feed it a bullet until nexus/nexus-
prisma came along. It was perfect timing in my case, I now love prisma again.

~~~
nikolasburk
Thanks a lot for this feedback and great to hear you like the code-first
approach of GraphQL Nexus for building your GraphQL server!

For anyone who is curious about Nexus, I recommend our blog article series
about code-first vs SDL/schema-first GraphQL server development:
[https://www.prisma.io/blog/the-problems-of-schema-first-
grap...](https://www.prisma.io/blog/the-problems-of-schema-first-graphql-
development-x1mn4cb0tyl3/)

Also, for a quick and ready-to-run example, you can check out this:
[https://github.com/prisma/prisma-
examples/tree/master/node/g...](https://github.com/prisma/prisma-
examples/tree/master/node/graphql)

------
tiuPapa
What is Prisma actually? Is it an ORM or a client for a db that exposes a
GraphQL API for the data stored?

~~~
timsuchanek
That's a good question.

The main focus of Prisma is the ORM part and not the GraphQL API anymore.
We're still using GraphQL to communicate between Query Engine and the backend
client in the languages we support like TypeScript or Go, but when
communicating with backend to database, GraphQL is not that relevant anymore
and rather a separate concern how you want to expose your API later.

When accessing the database from your backend, type-safety is becoming more
and more important. Instead of writing a GraphQL string in your code, with the
Prisma Client you get a type-safe programmatic API to access your data. You
can imagine it as your own SDK. The difference to many ORMs is, that we
generate a custom Client for you, which is way more powerful.

Disclaimer: I work at Prisma.

------
Illniyar
So If I understand it right, this is an ORM (with some graphql like
properties) with the addition of data model code generation?

~~~
shusson
it's more than just a traditional ORM layer. They run a server (prisma)
between the client and the database.

~~~
Illniyar
This is really not clear from the site. Even after I skimmed the tutorials and
docs. I would imagine it should be front and center like in Hasura and
Postgraphile . I would be tiffed if I found out after I started developing
with it using the cli that I need to setup another server and process in my
production environment.

~~~
nikolasburk
(I work at Prisma)

It is very important to understand that Prisma is NOT a GraphQL-as-a-Service
like Hasura or Postgraphile. It's really a suite of database tools that you
can use for any use case (building GraphQL, REST or gRPC APIs, or use it in
any other app where you need a database). We recently wrote a blog post about
this topic: [https://www.prisma.io/blog/prisma-and-graphql-
mfl5y2r7t49c/](https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/)

Also, the Prisma server (that proxies the database) is indeed currently a
mandatory component in the Prisma architecture. However, this requirement will
be lifted very soon (as we're currently rewriting the Prisma core in Rust) and
it will be possible to run Prisma as a library, just like any other ORM.

~~~
BenjieGillam
It feels a bit misleading to say PostGraphile is "GraphQL-as-a-Service".
Typically XaaS is used when there's an external service (normally hosted
elsewhere) that provides this functionality; whereas PostGraphile is 100%
self-hosted, we do not even have a hosted offering. Further, PostGraphile is
more of a framework for building a GraphQL API than a separate service you run
- since it's pure JS (well, TypeScript) a decent portion of our users mount
PostGraphile directly into their Express or Koa applications and deeply
integrate it, including customising and extending it via plugins. It's much
more of a library/framework than an "-as-a-service". (I'm the PostGraphile
maintainer.)

------
monteverdi
Massively simplifies working with data and databases cos they don't use ORM.

------
iddan
This is amazing! What about Python?

~~~
stefano
Don't the Django ORM and Django Admin do the same thing?

~~~
crucialfelix
Prisma admin is much better for editing relationships. Write graphql queries
with deep multilevel joins and then double click to edit any fields you see in
the results. Very different experience than django.

------
alexashka
Forgive me the obvious elephant in the room - where is Swift and Java/Kotlin
support?

~~~
nikolasburk
(I work at Prisma)

That's a great question! We started with a major focus on GraphQL which has
now become more generic as Prisma can really be used for any app that uses a
DB (REST, gRPC, ...). With that GraphQL history, we've put a lot of focus on
the Node/TypeScript ecosystem because that's where GraphQL tooling is most
mature. However, we're definitely planning to support more languages in the
future. In particular, we are opening the generator API for the Prisma client
which means it will be possible for anyone to implement the Prisma client in
their own preferred language: [https://github.com/prisma/rfcs/blob/client-
generators/text/0...](https://github.com/prisma/rfcs/blob/client-
generators/text/0000-client-generators.md)

