Hacker News Reader

Comment by jasonhero | Hacker News Reader

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.

View on HN

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

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.

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 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.

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! :)

Reply on news.ycombinator.com