Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We migrated to SQL. Our biggest learning? Don't use Prisma

codedamn.com

Post reply on HN
Print view View original

41–50 of 104 posts

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#41

Post by Tade0 »

I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those engines) is either available in the documentation or visible upon install/build - you can actually make it point to specific executables instead of downloading each time using environment variables but again - it's in the docs.

I picked Prisma because I'm not actually a backend developer and the tradeoffs were okay for my use case.

I wish performance was better, but a few indexes here and there went a long way.

The only surprising bit for me was peak memory usage - it comes in bursts and can get to hundreds of MB when doing even a simple query.

The queries themselves are also kind of out there in terms of complexity but so far I haven't found a reason to rewrite them in raw SQL, since that isn't where our performance bottlenecks are at the moment.

The lack of rollbacks is one legitimate pain point and I wish they addressed it.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#42

Post by danjac »

From the article there is no detail of what problem they were solving, just "we used tech stack A, we ran into issues, so we went with tech stack B". So I have no idea whether MongoDB was a good choice to begin with, or not, or whether the problem needed a relational database or not. Or for that matter GraphQL or AWS Lambda.

I do get the feeling they went YOLO and built their solution on an over-engineered approach with a stack they were unfamiliar with, and when they hit problems, they YOLO'd into another solution without properly evaluating why, which feels like a team of junior developers run amok.

They also seemed to not really understand relational databases, and why foreign keys are kind of important when you are choosing a relation database implementation (yes you can do without them, but it's best to understand them first).

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#43

Post by estebarb »

spion wrote: post #14

I would modify this to "Don't use Prisma if you're using serverless" With actual servers and prisma running close to the underlying database, it should be much better. Regarding using joins, that's not necessarily the best choice either. When using simple flat joins naively, you get a lot of repetition for the more toplevel nodes of the join tree, which eventually adds up to a lot of network traffic and allocation. (…

The joins should be done inside the DB, not in an external server. Any SQL DB should be able to do that.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#44

Post by l5870uoo9y »

One thing that keeps coming up is that SQL equals low productivity. I don't think this is true. I think the culprit is that most developers are using to heavily abstracting SQL using ORMs like Prisma that hides the database and SQL logic.

Since building a SQL generator (https://aihelperbot.com) as a side project, I have become much more proficient in SQL and even though I am also locked into Prisma, I use the `queryRaw` all the time to execute raw SQL queries. You can understand the code without knowing Prisma API. It is more performant. For more complex SQL queries, I use the SQL generator for initial suggestions and adapt if needed.

For the next projects I build I want to use the minimal Postgres client (https://github.com/brianc/node-postgres) combined with a lightweight migration library.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#45

Post by CharlieDigital »

porbelm wrote: post #27

People needing to query huge amounts of data discovering technology that's been developed over the past 45 years for querying huge amounts of data efficiently; news at 11. Seems all these shops starting out with MongoDB or the like always need to do a huge, complicated migration to a /proper/ optimized data store, when they could have started with a sane design in the first place...

    > People needing to query huge amounts of data discovering technology that's been developed over the past 45 years for querying huge amounts of data efficiently; news at 11
I think a lot of folks are quick to discount just how scalable a database like Postgres or SQL Server can be (not to mention battle tested). Maybe its because of a lack of DBMS experience as we've move more and more from owning database servers to consuming *-as-a-service. Maybe it's because everyone thinks that they'll have Facebook scale traffic and concerns so they immediately gravitate to technologies designed to solve problems at a different order of magnitude.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#46

Post by paulryanrogers »

mijoharas wrote: post #19
francislavoie wrote: post #3

IMO foreign key constraints are bad; they make migrations and maintenance a nightmare. It's better to have application-level processes in place to ensure data consistency. I don't agree that "no foreign key support" is a good reason to not use a particular solution. Pricing concerns are valid though.

How do you find fkey constraints making maintenance or migrations a nightmare? I've always found them reasonably pleasant to use on postgres.

As tables scale you may need to partition them. FKs also introduce a performance it on writes and DDL. In some DDL cases a table rewrite may be required, such as if FKs cascade.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#47

Post by Exuma »

danjac wrote: post #42

From the article there is no detail of what problem they were solving, just "we used tech stack A, we ran into issues, so we went with tech stack B". So I have no idea whether MongoDB was a good choice to begin with, or not, or whether the problem needed a relational database or not. Or for that matter GraphQL or AWS Lambda. I do get the feeling they went YOLO and built their solution on an over-engineered approach w…

The article is cringe yolo for sure

With that said I was planning to use prisma and went and looked at issues on GitHub. They’re egregious … and I will not be using prisma

The library also looks like it was written in a yolo way as well.

My guess is the graphql background has permanently stunted it, as the project manager keeps wanting examples for performance issues instead of realizing the entire fact joins are missing to begin with is idiotic and absurd.

So my guess is they’re piecemeal fixing one off issues instead of fixing the problem at its root, probably because prisma code is not designed with that in mind from the beginning

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#48

Post by mattacular »

Tade0 wrote: post #41

I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those engines) is either available in the documentation or visible upon install/build - you can actually make it point to specific executables instead of downloading each time using environment variables but again - it's in the docs. I picked Prisma because I'm not…

> The lack of rollbacks

Could you elaborate on this part?

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#49

Post by jeswin »

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language.

EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. This is what makes it relatively more usable.

To illustrate, if JS/TS were to approach the problem in a similar way, you'd do this:

1. Allow queries to be written like this:

  const bangaloreanStudents = await db.users.filter(x => x.city === "Bangalore" && x.age
2. Use acorn/espree to parse this into an AST

3. Convert the AST into SQL, hand over to runtime helpers.

Doing so will allow queries to be written in the most natural way possible.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#50

Post by city41 »

jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

Knex is probably the closest thing js has to this. It's not an orm though, just a query builder.
Post reply on HN