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

81–90 of 104 posts

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

#81

Post by branko_d »

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.

> It's better to have application-level processes in place to ensure data consistency.

Good luck doing that correctly and with good performance, especially in concurrent and multi-client system.

https://stackoverflow.com/questions/20842756/sql-indirect-fo...

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

#82

Post by DonnyV »

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

The problem is when people pick Mongodb thinking they can use it like a SQL database. I've been using Mongodb since v1.6. You have to use it differently then a SQL database. The way you design your schema and code needs to change also. Its just a different way of thinking about a database. When you use Mongodb you treat the db like a dumb black box. You design in data integrity into your code. One of the big reasons you use Mongodb is because you don't need an ORM. Your POCOs are the tables. People that say they lost data while using Mongodb. Were using Mongodb wrong.

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

#83

Post by ivanb »

fabian2k wrote: post #79
ivanb wrote: post #74

Earlier quoted context omitted.

Indeed. A query builder is only really useful for dynamic queries and in practice they are few. I would argue that for performance and complexity reasons dynamic queries in real-world applications should be avoided.

I'm always surprised when I see this opinion. I think I might be writing fundamentally different kinds of applications because I need dynamic queries all the time. I often need several different kinds of filters for an endpoint that can be combined arbitrarily. Any UI that allows users to filter stuff by various criteria needs some kind of dynamic query building in the end.

Yes. Maybe I took it too far. I was implying that the fewer choices you give to the user the better scalability you will be able to achieve.

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

#85

Post by dimgl »

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…

Whoa, no. I massively disagree. Entity Framework is, by far, the worst ORM I've ever used.

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

#86

Post by pleoxy »

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

> Seems all these shops starting out with MongoDB or the like always need to do a huge complicated migration

First thing to note, I couldn't find any reasoning for the change in the original post. This makes the speculating on it rather pointless, but clearly you are able to fill in the details quite easily somehow.

As a counter point. Last four businesses I've worked at all ran on MongoDB. More happenstance than something I've looked for.

They are all relatively small businesses and all ran fine, the biggest was ingesting 1-10GB/day of new data from their IOT fleet.

So this perspective that everything mongo is fundamentally broken and plain bad is pretty foreign to my real world experience.

These shops all liked what they were doing and there was zero talk of scaling issues or changing out the database.

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

#87

Post by dimgl »

This is a very strange comment section. I can't in good faith recommend Entity Framework to anyone who doesn't want to torpedo their project with ORM problems.

Additionally, this article is really poorly written.

> Last week, we completed a migration that switched our underlying database from MongoDB to Postgres.

Okay cool, but why? MongoDB is a very capable and fast database.

> It was a shock finding out that Prisma needs almost a “db” engine layer of its own. Read more about it here: https://www.prisma.io/docs/concepts/components/prisma-engine...

If you did any research on Prisma rather than diving in head-first, you'd realize this is a core part of why Prisma exists.

> we discovered that at a low level, Prisma was fetching data from both tables and then combining the result in its “Rust” engine. This was a path for an absolute trash performance.

Can you confirm this is actually the case? Can you show some benchmarks re: this claim? Or are you just assuming this is the case? We're using Prisma in production and it is blazing fast.

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

#88

Post by superwalker »

Tade0 wrote: post #51
mattacular wrote: post #48

Earlier quoted context omitted.

> The lack of rollbacks Could you elaborate on this part?

Here's a comment from their team about this: https://github.com/prisma/prisma/discussions/4617#discussion... Tl;dr it's a design decision, not everyone (including me) agrees.

[flagged]

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

#89

Post by mijoharas »

eightnoteight wrote: post #28
mijoharas wrote: post #13

> Weird pricing: PlanetScale prices you on row-reads and row-writes per month. What is weird is that row-reads is something that nobody controls. It is the SQL query planner which determines the query plan, which results in how many rows you’re reading internally. Remember that row-reads are not row returns. You can write a wrong query that returns 0 rows but can still do a full table scan of 1M rows and PlanetScale…

aurora serverless v2 now supports io optimized mode. which increases the pricing for instances by constant amount but makes the io pricing to 0 https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-au...

Oh, very cool!

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

#90

Post by superwalker »

Exuma wrote: post #33

Wow just one look at this issue was all I needed to see. https://github.com/prisma/prisma/discussions/12715 “Please open an issue if something really is unusable or breaks in any way so we have these concrete cases recorded. In our knowledge Prisma works just fine and returns the data that was requested, just using a different method.” Good lord

I substantially regret using Prisma in production for this and very many other reasons.

At least the underlying data is well modeled, just need to rip out the JS library and replace it… but with what?

Post reply on HN