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.
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.
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. :)
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.
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.
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 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! :)
Prisma Migrate  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
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 think the VC announcement forced them to prematurely launch 2.0.0.
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. :)
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.
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.
However, I believe that one thing that sets Prisma apart is the architecture with a _query engine_  (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!
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?
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'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.
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?
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
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.
No reason not to use the older things if they work for you. But if they don't, never choices might help.
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
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).
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?
I've used it on 3 non-trivial projects with great success
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.
- 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).
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
As a developer, I prefer the Confluent/Kafka model because it’s crystal clear where the separation is between premium and open source.
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 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!
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.
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?
Is that supposed to be a reason against? Enabling further progress sounds more like a reason for, not a reason against.
With Prisma, we're setting out to build database tools that make developers more _confident_ and _productive_  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 , would love to hear your feedback about our thoughts here!
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.
There is absolutely room for improved tooling. I have no idea whether Prisma is it.
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.
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! :)
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?
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.
Join live here: https://prisma.io/day
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.
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.
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.
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.
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...
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 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.
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.
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...
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.