
Prisma Raises $12M Series A - pimeys
https://www.prisma.io/blog/prisma-raises-series-a-saks1zr7kip6
======
jasonhero
I've been using prisma for a couple months now at my employer. The longer I
use it, the more frustrated I find myself with the tool.

Here's a list of a few things out of many that you can't do with this tool
(Prisma Migrate):

* Renaming columns/tables

* Migrating data from one column/table to another column/table.

* Write anything that isn't a table definition, such as procedures, functions, events, transactions, etc.

I think people are attracted to prisma at first because a single state
definition of your database seems nice, but then once you wisen up you realize
you're sacrificing a lot for it. There's just no way to effectively track
changes like the name changing of a column between states with this sort of
system.

Writing your migrations in SQL with tools like Flyway is a much more flexible
and sustainable approach, in my opinion.

~~~
joshring
I agree, all of the "do it all" database tools have always hurt in the long
term in every system I've worked on that uses them (TypeOrm, Prisma, etc..)

From what I can tell it is always better to just learn and understand the
database you are using and create it by hand. You may spend a tiny bit longer
with basic crud boiler plate, but it will benefit you greatly in the long term
to just have solid native migrations setup. And a framework that simply works
with your database schema, rather than having an opinion forced on your
database.

In Prisma, Typeorm, etc you are a slave to what the ORM wants the database to
look like. Tools like Objection, jOOQ, etc are all much easier to work with in
the long term and allow you to tune your database by hand and without random
framework constraints.

Prisma is great if you plan on never maintaining past your MVP, so I guess it
makes sense that startups use it and get stuff out the door quickly, but I
don't find it as a long term solution or for it to ever be able to handle
complicated situations that _will happen_ to your database in the future.

Edited: Spelling

------
zookatron
I find it odd that they say "Prisma is ready for production", but "Prisma
Migrate is currently in an experimental state and should not be used in
production environments". Having a robust migration management system is one
of the _primary_ things I look for in an ORM/database management tool in
general. The only constant is change when it comes to business requirements,
and having the ability to easily and safely change the data model of your
application is invaluable. Not having the migration tooling complete makes it
difficult for me to seriously justify trying out the Prisma 2 ecosystem in
general.

~~~
airstrike
As a counter example, Django was "ready for production" for ages before a
third-party migration app (South) came along, let alone built-in support

~~~
steve_adams_86
Right. Best practices are all well and good, but the reality is that tons of
people are running in production with no migration strategy.

I'm not saying it's not important or that Prism is fine without it. I wouldn't
choose software without a tried, tested migration strategy available. Just...
To a lot of people I've worked with, migrations are a nice-to-have that will
probably never happen.

------
gsvclass
Looking for something similar but not VC backed checkout Super Graph. It's
very similar and in GO. Also it's not VC funded or even a startup just a good
old open source project with a fast growing community.

Super Graph can learn your DB schema and relationships and automatically
compile GraphQL to a single efficient SQL query. Use it as a standalone
service or a library in your own code. It also works with Rails auth, JWT,
Firebase auth, supports OpenCensus tracking and tracing, designed to be high-
performance and startup in few milliseconds fro scale to zero environments. It
works with all kinds of DB relationships including polymorphic associations,
JSON and Array columns, and much more.

[https://github.com/dosco/super-graph](https://github.com/dosco/super-graph)

~~~
gsvclass
FYI Super Graph has a built-in migrations framework and you can write seed
scripts in javascript with built-in fake data functions.
[https://supergraph.dev/docs/seed](https://supergraph.dev/docs/seed)

~~~
gsvclass
Also we currently expose a `GraphQL` function that can be used within your own
GO apps as a way to replace ORMs and managing SQL. Just write the GraphQL and
Super Graph will figure out the join, etc and build the most efficient single
SQL query to do the job. We're expanding on this to expose the entire Super
Graph service as an API.

GO is a great language for web development (especially API backends) and Super
Graph is a natural fit. Using it as a library gives you unlimited flexibility.
The link below shows you a GraphQL example fetching posts, comments, threads,
votes, etc all related imagine the code you don't have to write and maintain.
when you use Super Graph.

[https://imgur.com/a/RNnoqXg](https://imgur.com/a/RNnoqXg)

------
jordanab
While the implementation certainly seems very nice, the ideas behind Prism 2
aren't particularly new, or unique for that matter. For example the .NET
ecosystem already has (for a long time) most of the stuff that is presented as
being uniquely offered by Prism: generated database clients (LINQ-to-SQL,
Entity Framework), generated data models (EF POCO's), type-safe queries (LINQ)
etc.

~~~
abraxas
Everything is being reinvented from scratch in the JS world. The insistence on
unifying into one language means that a lot of tried tested and true has been
tossed aside and it's all being rebuilt sometimes with dubious benefit.

~~~
RedShift1
And at the end of the day all we do is select, insert, update and delete in
some database.

~~~
kevas
True true

------
bovermyer
The graphic under "Database tools are stuck with legacy paradigms" made me
chuckle. Just because the tech under the "Legacy" column isn't the new hotness
doesn't mean they're suddenly irrelevant or even a bad choice.

~~~
nogabebop23
They graph control vs. productivity and then throw their solution way up near
the top-right in the success quadrant, with a bunch of questionable "benefits"
and very little justification.

It's not like I need to choose between an ORM, query builder and plain SQL
either... Why can't I use any of them as the problem dictates?

~~~
steve_adams_86
Yeah, that graph is not something I can take seriously. It feels like they’re
trying to convince me with pictures when they should be letting the product
speak for itself.

In my experience, not much software is an outlier in performance like they’re
claiming here. There are some standout projects that I really love and depend
on (Postgres, rust, typescript, react), but even those aren’t ‘top right
quadrant’ solutions. They also don’t claim to be, as far as I know

------
hn_reddit_human
I mentioned this the last time, but I find it surprising that the Prisma ORM
doesn't support transactions or aggregations?

Any thoughts from the Prisma team? It kind of seems like table stakes. I
commented on this previously as well:
[https://news.ycombinator.com/item?id=23467427](https://news.ycombinator.com/item?id=23467427)

~~~
Sujan
This time I can answer that some aggregations are in the current milestone:
[https://github.com/prisma/prisma/issues/2838](https://github.com/prisma/prisma/issues/2838)
That could mean they will be available very soon. (If you are missing any
other ones, please comment on that issue or create a new one!)

Transactions were actually included in the last release
[https://github.com/prisma/prisma/releases/tag/2.1.0](https://github.com/prisma/prisma/releases/tag/2.1.0)
(search for `transactionApi`) in a specific form behind a feature flag (batch
transactions, not long running transactions).

~~~
lukeholder
Before I could consider Prisma, it would need to support full transactions:
[https://github.com/prisma/prisma/issues/1844](https://github.com/prisma/prisma/issues/1844)

------
markhalonen
a similar open source project is Postgraphile:
[https://www.graphile.org/postgraphile/](https://www.graphile.org/postgraphile/)

I've used it on 3 non-trivial projects with great success

~~~
rgbrgb
Played around with postgraphile a bit and love how easy it is to stand up a
graphql endpoint with a ton of features. Liked it a lot more than hasura
because you could use it as a library to expose a graphql endpoint on a
next.js api endpoint rather than running as a separate service.

I do wonder how a project built with a lot of logic in the DB ends up evolving
over time. With a Rails project (my recent professional experience) if we're
tweaking a feature, I can refer a new engineer to my_feature.rb where they'll
find all the logic around that feature. With triggers and functions in the DB,
it seems like there's not a common notion of organizing the source code.
Anyone dealt with that in the past?

The thing that's attractive to me about Prisma is that the mental model seems
a lot closer to ActiveRecord and I just understand that way of working and
scaling a productive team using it.

------
sorenbs
Prisma co-founder here. I’m really excited to put this to good use and roll
out many new futures in the coming months. Happy to answer any questions :-)

~~~
XCSme
Is this meant for the average developer or for highly-scalable enterprises
only? What is the problem with the current vast number of databases? I
personally still use MySQL and MongoDB and don't have many complaints in
regards to usability or performance.

~~~
sorenbs
Prisma is not a database. It is a modern way for application developers to
work with all the databases they already use. The main benefit is improved
developer experience due to automatic generation of types, which gives you
full code-cpmpletion for your database queries in JavaScript and TypeScript.

~~~
XCSme
Thank you, I noticed this soon after I wrote my comment. It took a while to
understand that from the blog posts.

------
heymartinadams
I’m so happy for the entire team at Prisma. Been following Prisma since early
2017 and they deserve every bit of this success. Their entire focus has been
on how to better serve their customers (developers). And, yes, their tech is
10x better than anything out there.

------
hypewatch
Does Prisma have a business model or premium version I’m not aware of? I don’t
see anything on their site around premium options. Not sure why Amplify
Partners would invest in Prisma unless they were planning on dedicating
substantial resources to a premium / enterprise version.

From what I understand, prisma is an open source query builder for node/ts.
Like sqlalchemy-core in python, which has been around for a long time.

> While almost any other part of the development stack has been modernized,
> database tools have been stuck with the same paradigms for the last decades.

This is simply not true. Perhaps that’s been the case in the node.js world but
it has certainly not been the case in other server-side languages.

~~~
nikolasburk
We've alluded to this in the blog post as well:

> We are commited to building world-class open-source tools to solve common
> database problems of application developers. To be able to sustain our open-
> source work, we're planning to build commercial services that will enable
> development teams and organizations to collaborate better in projects that
> are using Prisma.

So, your hunch is correct that later down the road we'll invest into building
commercial cloud services for teams and enterprises that are using Prisma's
open source tool!

~~~
hypewatch
Oh, it’s mentioned in the very last paragraph!

------
jaeming
I'm very excited about the work Prisma is doing. I didn't get it at first but
after trying it out, it was the best ORM experience I've had in Javascript.

It introspects your DB and generates a client that provides typescript
definitions for your queries. When I try to select a non-existent field or
relation, I get warned via ts.

Right now it's mainly their client that is production ready but they are
making great progress on their migrations tooling. For now I still write my
migrations in raw SQL, but I'll probably swicth to prisma-based migrations
once it's a bit more mature.

~~~
jasonhero
I do find the typed query builder interesting, I don't think it's fully
"there" yet in terms of functionality. I think they need to ditch the whole
'definitive single state' database model and just lean hard into the typed
query builder. I'd seriously consider it if they were to implement similar
functionality as the Java JOOQ library.

------
XCSme
I had a look over the quick start guide and the syntax looks almost indentical
to Mongoose. Why is it "next generation" compared to Mongoose?

~~~
XCSme
Wait, I started reading through all the fluff on their description and it
seems that Prisma is not a database but an interface/connector to more
database solutions. So it's like Mongoose, but not only for MongoDB.

------
cragsify
Why do we need another generation of DB tools, what is wrong with what we
have?

~~~
nikolasburk
I feel like current database tools don't really cut it! From my own
experience, working with databases in Node.js and TypeScript has always been a
painful experience – sometimes more, sometimes less, but it was never smooth
or enjoyable!

With Prisma, we're setting out to build database tools that make developers
more _confident_ and _productive_ [1] in their database workflows!

We're focusing on type-safety, intuitive data modeling, easy working with
relations and overall simpler ways for achieving common tasks with your
database.

We also wrote at length about what we believe the shortcomings are with
databases tools in our documentation [2], would love to hear your feedback
about our thoughts here!

[1] [https://www.prisma.io/blog/announcing-
prisma-2-n0v98rzc8br1/](https://www.prisma.io/blog/announcing-
prisma-2-n0v98rzc8br1/)

[2] [https://www.prisma.io/docs/understand-prisma/why-
prisma](https://www.prisma.io/docs/understand-prisma/why-prisma)

~~~
pphysch
> working with databases in Node.js and TypeScript has always been a painful
> experience

Even after reading your (three) paragraphs from the article on why raw SQL and
drivers are bad, I'm far from sold.

1\. Establish connection 2\. Execute SQL 3\. Manipulate results 4\. More
SQL/Commit/close

IME a lot of the struggle comes from not understanding how 1. or 2. work and
trying to do all the heavy lifting in 3. The amount of times I've refactored
dozens of lines of code into <10, with huge performance and readability gains
by simply using SQL's potential...

Best of luck with the sales.

~~~
dllthomas
On the other hand, working at a large company I saw a many-line SQL query that
had been run monthly for a long while, looked at and edited by quite a few
people, which down in the middle of it was comparing (for equality) a city id
and a probability.

There is absolutely room for improved tooling. I have no idea whether Prisma
is it.

~~~
infinite8s
Well better tools wouldn't have helped that, since most of the them just
expose the underlying low-level DB types. Until databases support a proper
type-system that doesn't just describe memory layout that kind of bug will
always be an issue.

~~~
dllthomas
"A proper type-system that doesn't just describe memory layout" is one kind of
better tool, whether built into the database or separate.

------
darsoli
The query language here looks eerily similar to what we use for our ORM in
Node.js. It's called Sequelize
([https://sequelize.org/](https://sequelize.org/)) -- how does this project
compare / what are the main differences?

------
desmap
Related and FWIW: I checked all solutions in this space and I stuck with type-
graphql which is not only an amazing lib but offers a clean architecture:

Decorated Typescript types as classes dictate the GraphQL schema and the DB
model (either through further decorator libs or custom solutions). So, you end
up with only one source of truth + stay DRY + very low level of abstractions.
There is some debate around the right approach but I much prefer this approach
over the others such as DB-model-first (Hasura) or Prisma 2 which I remember
has its own DSL for modeling data.

~~~
nikolasburk
TypeGraphQL and Prisma are not really comparable though. Prisma is an open-
source _database toolkit_ (much like an ORM), TypeGraphQL is a _GraphQL schema
construction library_ (like `graphql-js` or `@nexus/schema`), they solve very
different problems!

You can even combine Prisma with TypeGraphQL if you're building a GraphQL
server that needs to access a databases. In that case, you'd use Prisma Client
inside your TypeGraphQL resolvers to send database queries.

In fact, we are collaborating with the maintainer of TypeGraphQL to build an
integration between Prisma and TypeGraphQL that will allow you to leverage
information from your Prisma models when building your GraphQL schema! :)

~~~
desmap
They can be compared in terms of who dictates the model/is the leading source
of truth.

I saw that you integrate with type-graqhql but the integration hasn't
convinced me yet, somehow type-graqhql loses its elegance with the resulting
architecture.

Besides, did you sponsor type-graqhql's maintainer to collaborate with Prisma
2?

~~~
hervelabas
> They can be compared in terms of who dictates the model/is the leading
> source of truth.

You can also use introspection to keep the database as the source of truth for
the model, and lean on the Prisma schema for type safety if you prefer.

------
GrumpyNl
All those tools while the real problem is that a lot of people working with
relational db's dont know the basics. Ask them to do a proper join and see
what you get.

------
poluyanov
Prisma 2.0 is Awesome! Just watched their's webinar.

~~~
nikolasburk
For everyone reading this, our Prisma Day conference is currently happening
online!

Join live here: [https://prisma.io/day](https://prisma.io/day)

~~~
sorenbs
You can also join the dedicated Slack to ask questions for the live Q&A:
[https://slack.prisma.io](https://slack.prisma.io)

------
opqpo
What is their business model?

------
realtalk_sp
I've been pretty ecstatic with the combination of TypeORM and TypeGraphQL if
anyone is looking for an alternative.

------
addandsubtract
How does Prisma compare to Objection?

~~~
hervelabas
Prisma is a Query Builder, not an ORM (like Objection). We chose this approach
since ORM suffer from the object-relational impedance mismatch problem
(described here: [https://en.wikipedia.org/wiki/Object-
relational_impedance_mi...](https://en.wikipedia.org/wiki/Object-
relational_impedance_mismatch)) We explain this in more details here:
[https://www.prisma.io/docs/understand-prisma/why-
prisma#orms...](https://www.prisma.io/docs/understand-prisma/why-prisma#orms-
less-control-better-productivity) or there:
[https://dataguide.prisma.io/types/relational/comparing-
sql-q...](https://dataguide.prisma.io/types/relational/comparing-sql-query-
builders-and-orms)

------
kevas
I’m not seeing why I’d use this over sql. Can someone please enlighten me as I
find this to be much more gobbledegook than sql.

~~~
lordofgibbons
My first instinct was to say type safety, but you don't really get that with
JS either way.

Maybe it would be popular for new engineers that don't feel like learning SQL.
Same reason why MongoDB got popular.

~~~
derdude
> My first instinct was to say type safety, but you don't really get that with
> JS either way. Correct, but the main experience we are supporting is
> TypeScript, which has a beautifully designed type system.

> Maybe it would be popular for new engineers that don't feel like learning
> SQL. Same reason why MongoDB got popular.

We have more and more senior engineers who want to use Prisma, as they just
realized that writing SQL by hand is a waste of time.

Let's be honest - learning SQL is still a great skill. Data analytics etc -
there are great use-cases.

But if you want to get stuff done and scale your team when building an
_application_ - you should have a data layer.

That's what Facebook, Lyft, Airbnb etc did - they have a dedicated data layer
and a team working on that. Do you think an application engineer at Facebook
writes SQL? No. Of course not, it would be a total waste of time to let them
touch such a low level. It would not allow facebook to scale to where they
are, if everyone would write direct SQL.

Now the thing is, most small teams don't have the capacity to write a really
performant awesome data layer with caching, deduping etc.

That's where Prisma comes into play - Prisma gives the weekend producthunt
warriors, but also the enterprise teams (like Tryg) a way to abstract away the
database.

But it's just a library you say? That's true. So in that sense, Prisma is not
really a "layer", a different component in your architecture that you can
horizontally scale.

For that - stay tuned. The "client" part can already easily be separated from
the "query engine" part (which btw is written in Rust) because they speak
http. But step by step. For most people, being able to install an npm
dependency is the most important part here. But one thing you can already get
used to - Prisma will stick around and _not_ just be a thing that new
engineers who don't feel like SQL use.

