Prisma Raises $12M Series A(prisma.io)
prisma.io
Prisma Raises $12M Series A
https://www.prisma.io/blog/prisma-raises-series-a-saks1zr7kip6
114 comments
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
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
[deleted]
Hello @joshring,
I'm with the product team at Prisma, currently focusing on migrations.
>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
We want Prisma to help developers get stuff out the door faster but our ultimate goal is to support developers throughout the entire application lifecycle.
We are working on improving Migrate and hope to deliver improvements over the next few months that hopefully can help you change your mind about our toolkit. :)
I'm with the product team at Prisma, currently focusing on migrations.
>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
We want Prisma to help developers get stuff out the door faster but our ultimate goal is to support developers throughout the entire application lifecycle.
We are working on improving Migrate and hope to deliver improvements over the next few months that hopefully can help you change your mind about our toolkit. :)
I have been using it for about 8months now and found that the migration portion of it isn't quite ready but is being heavily worked on.
For me, the type safety and ease of use with the api has been fantastic though. For now, I have been happy to use the client but not the migration tool. It has been built so that you don't need to do full buy in if you don't want to.
For me, the type safety and ease of use with the api has been fantastic though. For now, I have been happy to use the client but not the migration tool. It has been built so that you don't need to do full buy in if you don't want to.
Hello @jasonhero,
I'm with the Product team at Prisma, currently focusing on migrations.
We are currently working on improving Prisma Migrate to unblock some of the use cases you have suggested. While I am not sure our first production-ready version of Migrate will address all of the short comings you've listed, we think we'll able to solve the most important ones.
I encourage you to check out the new improvements I am sure we'll be releasing during the course of Q3.
If you have time, I'd love to do a call with you and dive deeper into these topics! You can find me on the community Slack for Prisma under the same username.
I'm with the Product team at Prisma, currently focusing on migrations.
We are currently working on improving Prisma Migrate to unblock some of the use cases you have suggested. While I am not sure our first production-ready version of Migrate will address all of the short comings you've listed, we think we'll able to solve the most important ones.
I encourage you to check out the new improvements I am sure we'll be releasing during the course of Q3.
If you have time, I'd love to do a call with you and dive deeper into these topics! You can find me on the community Slack for Prisma under the same username.
I think that declarative migrations don't make sense in the real world.
You're modifying existing state so it has to be incremental.
I'm curious to see how Prisma plans to handle these real-world use-cases.
You're modifying existing state so it has to be incremental.
I'm curious to see how Prisma plans to handle these real-world use-cases.
Hello @hn_reddit_human,
I'm with the product team at Prisma, currently focusing on migrations.
You are right about the fact that declarative migrations introduces some design challenges that can be hard to solve. In the current version of Prisma Migrate, changes to the declarative schema file are translated to auto-generate incremental migration files.
We have a few ideas for how we can improve our system to better deal with these challenges. Please feel free to follow along or check back in a few months if you are interested in how we solve (or not?) these problems! :)
I'm with the product team at Prisma, currently focusing on migrations.
You are right about the fact that declarative migrations introduces some design challenges that can be hard to solve. In the current version of Prisma Migrate, changes to the declarative schema file are translated to auto-generate incremental migration files.
We have a few ideas for how we can improve our system to better deal with these challenges. Please feel free to follow along or check back in a few months if you are interested in how we solve (or not?) these problems! :)
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.
That's totally fair! The first version of Prisma 2.0 includes Prisma Client [1] and introspection [2].
Prisma Migrate [3] is indeed still in the works, but we've shifted our focus a lot towards it now and you can expect major progress there over the next few weeks!
We definitely see folks using Prisma Client with production happily in production already, but I agree once Migrate joins the production-ready club, the Prisma package will be fully complete :D
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/in...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Prisma Migrate [3] is indeed still in the works, but we've shifted our focus a lot towards it now and you can expect major progress there over the next few weeks!
We definitely see folks using Prisma Client with production happily in production already, but I agree once Migrate joins the production-ready club, the Prisma package will be fully complete :D
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/in...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
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
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.
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.
It was but at the time the state-of-the-art for migrations was to hire a DBA and have them do it. That's much less common now with migrations and database operations being owned by development teams much more, so the need for migration tooling is much higher now, especially in what I expect Prisma's target market is.
There are also several important features, like literally setting a default value for JSON fields or updating the String to be longer than VARCHAR(99) or using LONGTEXT in MySQL that are still open issues.
I think the VC announcement forced them to prematurely launch 2.0.0.
I think the VC announcement forced them to prematurely launch 2.0.0.
Hello @zookatron,
I'm with the product team at Prisma, currently focusing on migrations.
Your point is valid, hence delivering a production-ready solution for migrations is one of our top priorities.
However, as my colleague @nikolasburk shared above, you can use a third-party migration system (knex, node-pg-migrate, e al) with Prisma and still get all the benefits of Prisma Client.
Prisma is designed to be more powerful if you are using the entire toolkit, but we also want to make it easy to use just specific tools within the kit, if that is what works well for your project.
Feel free to follow along or check us out again in a few months and hopefully by then our migration system will no longer be any kind of friction point. :)
I'm with the product team at Prisma, currently focusing on migrations.
Your point is valid, hence delivering a production-ready solution for migrations is one of our top priorities.
However, as my colleague @nikolasburk shared above, you can use a third-party migration system (knex, node-pg-migrate, e al) with Prisma and still get all the benefits of Prisma Client.
Prisma is designed to be more powerful if you are using the entire toolkit, but we also want to make it easy to use just specific tools within the kit, if that is what works well for your project.
Feel free to follow along or check us out again in a few months and hopefully by then our migration system will no longer be any kind of friction point. :)
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
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
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
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
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
Are there any tools out there that provide generated GQL APIs with auth provided via middleware? This looks nice, but I'm hesitant to use anything this config-file driven
That almost describes Super Graph. It's not exactly config file driven it can be used as a library within your own GO code and it's configured via a config object. In fact if you look at the example here we're passing null (nil) for the config since unless you want to do something more complex out of the box it just works config is not needed. https://supergraph.dev/docs/home#using-it-in-your-own-code
The config file is for when you use Super Graph as a standalone service that you can just deploy to Cloud Run, App Engine, Digital Ocean or whatever. The standalone service is the same core compiler library with a lot more valuable add-ons like auth middlewares, compression, etc.
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.
Some of the ideas we've built into Prisma are certainly inspired by tools in other languages and we've looked a lot at LINQ and the C# ecosystem in general as we designed Prisma!
However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se!
For example, we're already working on Prisma Client for Golang which is already available in alpha!
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://github.com/prisma/prisma-client-go
However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_ [1] (implemented in Rust) that takes care of query planning and execution on top of which we can add lightweight, language-specific layers to bring Prisma Client to more programming languages. But you're definitely right that a generated database client is not a novel idea per se!
For example, we're already working on Prisma Client for Golang which is already available in alpha!
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://github.com/prisma/prisma-client-go
What exactly does your "query engine"/planner actually do? I understand the role that, for example, the Postgres query planner does.
Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?
Is the idea that Prisma might be backing on to multiple databases and therefore needs another planning layer? If so, wouldn't this need to be very specific to the database and schema – knowing that particular fields in one database refer to entities in another? Does Prisma tackle this? How?
Assuming something in the same vein as fizx with the addition that it's probably very similar to what Join Monster tries to solve: https://github.com/join-monster/join-monster
I'm assuming that it's basically a port of GraphQL+DataLoader, so basically using recursive descent to manage hash joins.
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.
Same thing happened with Python for data science in 2023-2015. ie reinvent SQL using Python DSL.
Have you tried jupyter notebook + pandas dataframes? You just import a csv and you can explore, clean, manipulate data and make any sort of calculation using a real programming language. On top of that you can use something like seaborn and create visualizations. Then you click print pdf and you're ready. It almost feels like cheating.
You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.
You can say all you want about how fast,optimized and superior SQL is, but the python experience is way better for almost any time you need to make sense of some data.
I have a significant amount of experience with both of them. For pandas, it is fine for initial exploratory analysis (input, plot, reshape and export, etc). However, it's API has inconsistencies and subtle "features" around silent data coercion that make it hard to use in production. Seaborn is much nicer to work with than matplotlib and Jupyter is useful for making interactive presentations. So I believe Pandas/Jupyter have a place, but then there was a tendency to create a Pandas-like wrapper for all data retrieval such as:
https://github.com/ibis-project/ibis https://github.com/blaze/blaze
https://github.com/ibis-project/ibis https://github.com/blaze/blaze
Not the OP, but I have.
I've spent years doing the work that you specify above, and pandas & notebooks are probably one of the least good tools for it. SQL is super fast and useful (and everyone understands it, at least in the data world), while dplyr and ggplot2 are basically a DSL for this work, while pandas is an irritatingly bad clone of base-R which manages to keep the bad parts of both Python and R, while having the good parts of neither.
I really feel like you should try Rmd with R if you like the notebook flow, as it's similar but much much better.
If you really want to stick with Python, then org-mode is a much better notebook than anything else.
I've spent years doing the work that you specify above, and pandas & notebooks are probably one of the least good tools for it. SQL is super fast and useful (and everyone understands it, at least in the data world), while dplyr and ggplot2 are basically a DSL for this work, while pandas is an irritatingly bad clone of base-R which manages to keep the bad parts of both Python and R, while having the good parts of neither.
I really feel like you should try Rmd with R if you like the notebook flow, as it's similar but much much better.
If you really want to stick with Python, then org-mode is a much better notebook than anything else.
And perhaps detriment. Nodejs apps are notoriously more difficult to keep secure because of how many npm dependencies are needed for a project and how often vulnerabilities are discovered in those dependencies.
This is why we are focusing on the Node and Go ecosystems first :-)
If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.
If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.
[deleted]
Is this a bad thing? Are we only interested in funding brand new ideas?
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.
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?
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?
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
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
Yeah when I got there I went from curious to put off. That was the place to put an example showing something impressive rather than an iffy summary of web dev trends.
I clicked around a bit. I heard a lot about motivations but couldn't figure out a specific situation where I would be really happy to be using Prisma.
I clicked around a bit. I heard a lot about motivations but couldn't figure out a specific situation where I would be really happy to be using Prisma.
This is exactly it. I know prisma developers are here, and if I could express one concern to them, it’s that the content I saw was pretty fluffy and I left without a clear idea of why it’s worth adding into my tool chain.
I don't think the table indicates "irrelevant or even a bad choice" at all - it just puts "old" and "new" next to each other.
No reason not to use the older things if they work for you. But if they don't, never choices might help.
No reason not to use the older things if they work for you. But if they don't, never choices might help.
Me too! They also don’t make much sense. The innovation in data storage was from “self-hosted” to “managed”. That’s quite a broad generalization over what’s happened in data storage over the last several decades.
"Relational algebra only runs on PowerPC!!!"
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
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
This time I can answer that some aggregations are in the current milestone: 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 (search for `transactionApi`) in a specific form behind a feature flag (batch transactions, not long running transactions).
Transactions were actually included in the last release 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).
Before I could consider Prisma, it would need to support full transactions: https://github.com/prisma/prisma/issues/1844
How could I write any serious ecommerce/financial product with Prisma without transactions? Thats is crazy. Sticking with Postgres and plain ol' SQL!
Prisma supports transactions through the `prisma.transaction` API. This allow you to perform multiple DB actions in a single request and gives you an all-or-nothing semantic.
Thanks!
IIUC, a "batch" request is run in a transaction.But if I need to run business logic in the middle of requests that's not supported?
IIUC, a "batch" request is run in a transaction.But if I need to run business logic in the middle of requests that's not supported?
Not yet indeed. Prisma doesn't support long running transactions and advocates for alternative ways. We're preparing a post on the topic soon, and will improve the means for those alternatives.
a similar open source project is Postgraphile: https://www.graphile.org/postgraphile/
I've used it on 3 non-trivial projects with great success
I've used it on 3 non-trivial projects with great success
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.
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.
Second this. I've used both Postgraphile and Prisma on production projects (they can work well together too). Both are cool, but Postgraphile is way more mature.
The end goal is goal is different:
- Prisma is supposed to use as an ORM and not to be publicly exposed (although you can if you want)
- Postgraphile is a way to create an API using only your DB schema as reference. There are some tricks here and there, but you would need to do dig quite deep in SQL.
I tried postraphile and is quite cool for quick prototypes. Once you need something more custom, it gets tricky and weird (it is doable though). I haven’t tried Prisma in prod because, at the end, I am pretty happy with sqlc in Golang (code generator based on SQL queries).
- Prisma is supposed to use as an ORM and not to be publicly exposed (although you can if you want)
- Postgraphile is a way to create an API using only your DB schema as reference. There are some tricks here and there, but you would need to do dig quite deep in SQL.
I tried postraphile and is quite cool for quick prototypes. Once you need something more custom, it gets tricky and weird (it is doable though). I haven’t tried Prisma in prod because, at the end, I am pretty happy with sqlc in Golang (code generator based on SQL queries).
Also Hasura.
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 :-)
I have been working with integrating Prisma with Vitess and it is a very nice platform. Of all the ORM's I have been working with testing I think it gets what I want out of an ORM better then almost every other ORM. I am excited to see how it matures and I think the combo of Rust for the engine and Typescript for the userspace is really a killer feature.
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.
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.
Thank you, I noticed this soon after I wrote my comment. It took a while to understand that from the blog posts.
Proposal: Please do E2E framework where i can write the same code on client and on server side.
For client side is very important to have Models for further rendering.
This is a really interesting area with lots of development.
Have you tried https://redwoodjs.com/ or https://blitzjs.com/ ?
They both build on Prisma core data abstractions and provide a more full-featured experience. There will be talks later today at prisma.io/day
Have you tried https://redwoodjs.com/ or https://blitzjs.com/ ?
They both build on Prisma core data abstractions and provide a more full-featured experience. There will be talks later today at prisma.io/day
Why fundraise against the Prisma open source project instead of creating a new brand for the premium / enterprise product? Like how Confluent is separate from Kafka.
As a developer, I prefer the Confluent/Kafka model because it’s crystal clear where the separation is between premium and open source.
As a developer, I prefer the Confluent/Kafka model because it’s crystal clear where the separation is between premium and open source.
How do you make money?
Hey, i have a great backend automation tools team, super senior crew, one of our projects fell through so if you need a solid team to build automation build systems etc. Happy to talk.
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.
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.
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.
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!
> 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!
Oh, it’s mentioned in the very last paragraph!
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.
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.
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.
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?
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.
Why do we need another generation of DB tools, what is wrong with what we have?
The way I think about this is that the old generation of DB tools make it possible for application developers to use databases. With Prisma we want to make it a delight.
There are an order of magnitude more application developers today than just 10 years ago. This enable us to invest much more in the tools we all use, resulting in higher quality and a much better experience.
So to turn it around - why _not_ build new and better tools?
There are an order of magnitude more application developers today than just 10 years ago. This enable us to invest much more in the tools we all use, resulting in higher quality and a much better experience.
So to turn it around - why _not_ build new and better tools?
Because someone will build tools off yours and then someone will build tools off theirs. Abstractions on abstractions on abstractions.
> Because someone will build tools off yours and then someone will build tools off theirs.
Is that supposed to be a reason against? Enabling further progress sounds more like a reason for, not a reason against.
Is that supposed to be a reason against? Enabling further progress sounds more like a reason for, not a reason against.
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/
[2] https://www.prisma.io/docs/understand-prisma/why-prisma
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/
[2] https://www.prisma.io/docs/understand-prisma/why-prisma
> 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.
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.
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.
There is absolutely room for improved tooling. I have no idea whether Prisma is it.
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.
"A proper type-system that doesn't just describe memory layout" is one kind of better tool, whether built into the database or separate.
I used MongoDB + Mongoose in TypeScript and the experience was ok. Just declare a Schema and it works, you get typings and everything. I think the problem was not the DB itself (MongoDB) but the tooling around it.
[deleted]
The query language here looks eerily similar to what we use for our ORM in Node.js. It's called Sequelize (https://sequelize.org/) -- how does this project compare / what are the main differences?
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.
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.
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! :)
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! :)
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?
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?
> 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.
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.
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.
Prisma 2.0 is Awesome! Just watched their's webinar.
For everyone reading this, our Prisma Day conference is currently happening online!
Join live here: https://prisma.io/day
Join live here: https://prisma.io/day
You can also join the dedicated Slack to ask questions for the live Q&A: https://slack.prisma.io
What is their business model?
I've been pretty ecstatic with the combination of TypeORM and TypeGraphQL if anyone is looking for an alternative.
How does Prisma compare to Objection?
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...)
We explain this in more details here: https://www.prisma.io/docs/understand-prisma/why-prisma#orms... or there: https://dataguide.prisma.io/types/relational/comparing-sql-q...
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.
These types of tools are effectively another way to parameterize your SQL that _feels_ more like writing in your scripting language (nodejs in this case)
This approach is notorious for generating inefficient sql queries, but it can improve jr fronted dev productivity b/c a tool like this is easier to learn than SQL.
This approach is notorious for generating inefficient sql queries, but it can improve jr fronted dev productivity b/c a tool like this is easier to learn than SQL.
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.
Maybe it would be popular for new engineers that don't feel like learning SQL. Same reason why MongoDB got popular.
> 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.
> 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.
My first thought when I read “feel” in your comment was, “I don’t really care what they feel; if it’s in the job spec, they learn it or get a new job.”
That may be a bit harsh, but I’d rather them learn something they can use forever rather than the flavor of the week. Additionally, by learning SQL, they’d be able to apply that domain knowledge to building out queries in the flavor of the week since you know some limitations of the underlying.
That may be a bit harsh, but I’d rather them learn something they can use forever rather than the flavor of the week. Additionally, by learning SQL, they’d be able to apply that domain knowledge to building out queries in the flavor of the week since you know some limitations of the underlying.
> My first instinct was to say type safety, but you don't really get that with JS either way.
You get type safety if using it with TypeScript though: this is where Prisma adds a lot of value. Compile-time warnings, ease of refactoring...
You get type safety if using it with TypeScript though: this is where Prisma adds a lot of value. Compile-time warnings, ease of refactoring...
I'd suggest you watch the Prisma Day talks when they are published or give it a try.
If you are a grumpy HN troll, then Prisma might not be for you, and that's okay. SQL is great for many cases, and you might not need to expand your horizon.
If you do choose to look into Prisma and have serious thoughts on how we could improve, then I would love to get on a call to talk about it (contact info in bio).
If you are a grumpy HN troll, then Prisma might not be for you, and that's okay. SQL is great for many cases, and you might not need to expand your horizon.
If you do choose to look into Prisma and have serious thoughts on how we could improve, then I would love to get on a call to talk about it (contact info in bio).
I just cannot wrap my head around the co-founder reacting this way in a thread about his company.
I too don't understand what I would use this product for. That doesn't mean it's a bad product, I just don't have a personal need for it.
I don't really like eating grapefruit. If you're a grapefruit farmer, it doesn't mean you farm a bad fruit. Lots of people like grapefruit. I just don't like it personally.
Calling someone like me an "HN troll" because they're critical of your product is a pretty bad look.
I too don't understand what I would use this product for. That doesn't mean it's a bad product, I just don't have a personal need for it.
I don't really like eating grapefruit. If you're a grapefruit farmer, it doesn't mean you farm a bad fruit. Lots of people like grapefruit. I just don't like it personally.
Calling someone like me an "HN troll" because they're critical of your product is a pretty bad look.
Kevas is asking why he would use Prisma instead of raw SQL. There are numerous user testaments on this very page from developers explaining why they prefer Prisma over raw SQL. But it is much more fun to just call us "gobbledegook" instead of engaging with the people who are right here.
If you scroll down the page, you will see a different thread where Kevas compare Prisma to left-pad.
Kevas is a grumpy HN troll, and I have no patience for that.
As you will see from all other interactions on this page, on twitter and on our 30.000 developer strong Slack community, we engage happily and constructively with anyone who comes with curiosity and an open mind. But if you come with negativity we will ask you to find another community to hang out in.
If you scroll down the page, you will see a different thread where Kevas compare Prisma to left-pad.
Kevas is a grumpy HN troll, and I have no patience for that.
As you will see from all other interactions on this page, on twitter and on our 30.000 developer strong Slack community, we engage happily and constructively with anyone who comes with curiosity and an open mind. But if you come with negativity we will ask you to find another community to hang out in.
>> If you are a grumpy HN troll
I guess I am, since I expect a new company with a confusing value proposition to show me why they're better than 50+ years of proven RDBMS technology vs. an "OK Boomer" watch a video and "serious questions only".
And you WORK for this company? Better develop a thicker skin...
I guess I am, since I expect a new company with a confusing value proposition to show me why they're better than 50+ years of proven RDBMS technology vs. an "OK Boomer" watch a video and "serious questions only".
And you WORK for this company? Better develop a thicker skin...
> And you WORK for this company? Better develop a thicker skin...
Not only does he work for this company. He co-founded it. Unbelievable response from a co-founder.
I've had my reservations about Prisma (I don't think it solves a problem for me), but this pretty much discourages me from using it entirely.
Not only does he work for this company. He co-founded it. Unbelievable response from a co-founder.
I've had my reservations about Prisma (I don't think it solves a problem for me), but this pretty much discourages me from using it entirely.
To be fair, you're not going to get a fair and balanced viewpoint about a product from a founder.
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.