Live data from Hacker News

Migrating to Postgres

engineering.usemotion.com

41–50 of 278 posts

Re: Migrating to Postgres

#41
post #30
post #20

Earlier quoted context omitted.

> It's true that Prisma currently doesn't do JOINs for relational queries. Instead, it sends individual queries and joins the data on the application level. ..........I'm sorry, what? That seems........absurd. edit: Might as well throw in: I can't stand ORMs, I don't get why people use it, please just write the SQL.

> I can't stand ORMs, I don't get why people use it, please just write the SQL. I used to agree until I started using a good ORM. Entity Framework on .NET is amazing.

> Entity Framework on .NET is amazing.

I disagree. It is probably one of the less terrible ORMs, but it is far from amazing. The object-relational impedance mismatch will always dominate for anything that isn't trivial business. EF works great until you need different views of the model. It does support some kind of view mapping technique, but it's so much boilerplate I fail to see the point.

Dapper + SqlConnection is goldilocks once you get into the nasty edges. Being able to query a result set that always exactly matches your view models is pretty amazing. The idea of the program automagically upgrading and migrating the schemas is something that was interesting to me until I saw what you could accomplish with Visual Studio's SQL Compare tool & RedGate's equivalent. I feel a lot more comfortable running manual schema migrations when working with hosted SQL providers.

Re: Migrating to Postgres

#42
post #20

Earlier quoted context omitted.

> It's true that Prisma currently doesn't do JOINs for relational queries. Instead, it sends individual queries and joins the data on the application level. ..........I'm sorry, what? That seems........absurd. edit: Might as well throw in: I can't stand ORMs, I don't get why people use it, please just write the SQL.

It is. But wait... it doesn't join the data on the application level of your application. You have to deploy their proxy service which joins the data on the application level.

It's pretty obvious when somebody has only heard of Prisma, but never used it.

- Using `JOIN`s (with correlated subqueries and JSON) has been around for a while now via a `relationLoadStrategy` setting.

- Prisma has a Rust service that does query execution & result aggregation, but this is automatically managed behind the scenes. All you do is run `npx prisma generate` and then run your application.

- They are in the process of removing the Rust layer.

The JOIN setting and the removing of the middleware service are going to be defaults soon, they're just in preview.

Re: Migrating to Postgres

#43

Feels like postgres is always the answer. I mean like there's gotta be some edge case somewhere where postgres just can't begin to compete with other more specialized database but I'd think that going from postgres to something else is much easier than the other way around.

Depends.

If you want to fully embrace the vibe tables are difficult.

Even before LLMs, I was at a certain company that preferred MongoDB so we didn’t need migrations.

Sometimes you don’t care about data structure and you just want to toss something up there and worry about it later.

Postgres is the best answer if you have a solid team and you know what you’re doing.

If you want to ride solo and get something done fast, Firebase and its NoSQL cousins might be easier .

Re: Migrating to Postgres

#44
post #31

Earlier quoted context omitted.

Prisma is so bad... can you believe it's by far the most downloaded ORM in NPM?

Every ORM is bad. Especially the "any DB" ORMs. Because they trick you into thinking about your data patterns in terms of writing application code, instead of writing code for the database. And most of the time their features and APIs are abstracted in a way that basically means you can only use the least-common-denominator of all the database backends that they can support. I've sworn off ORMs entirely. My applicati…

I use PG with Entity Framework in .NET and at least 90% of my queries don't need any PG-specific features.

When I need something PG specific I have options like writing raw SQL queries.

Having most of my data layer in C# is fantastic for productivity and in most cases the performance compared to SQL is negligible.

Re: Migrating to Postgres

#45
post #41
post #30

Earlier quoted context omitted.

> I can't stand ORMs, I don't get why people use it, please just write the SQL. I used to agree until I started using a good ORM. Entity Framework on .NET is amazing.

> Entity Framework on .NET is amazing. I disagree. It is probably one of the less terrible ORMs, but it is far from amazing. The object-relational impedance mismatch will always dominate for anything that isn't trivial business. EF works great until you need different views of the model. It does support some kind of view mapping technique, but it's so much boilerplate I fail to see the point. Dapper + SqlConnection i…

> EF works great until you need different views of the model

You can easily project or use views with SQL then projected onto objects. It's very convenient with `.FromSql`:

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

Re: Migrating to Postgres

#46
post #41
post #30

Earlier quoted context omitted.

> I can't stand ORMs, I don't get why people use it, please just write the SQL. I used to agree until I started using a good ORM. Entity Framework on .NET is amazing.

> Entity Framework on .NET is amazing. I disagree. It is probably one of the less terrible ORMs, but it is far from amazing. The object-relational impedance mismatch will always dominate for anything that isn't trivial business. EF works great until you need different views of the model. It does support some kind of view mapping technique, but it's so much boilerplate I fail to see the point. Dapper + SqlConnection i…

> It does support some kind of view mapping technique

Can you call .Select(entity => SomeSmallerModel() { Name = entity.Name }) or something like that to select what you need? If I am understanding your issue correctly.

I also agree that its one of the least worst but there are still things that annoy me.

Re: Migrating to Postgres

#48
post #34
post #30

Earlier quoted context omitted.

> I can't stand ORMs, I don't get why people use it, please just write the SQL. I used to agree until I started using a good ORM. Entity Framework on .NET is amazing.

Doesn’t entity framework have a huge memory footprint too?

Do you have any links that note memory usage issues with any of the semi-recent EF Core versions?

Re: Migrating to Postgres

#49

Earlier quoted context omitted.

It is. But wait... it doesn't join the data on the application level of your application. You have to deploy their proxy service which joins the data on the application level.

It's pretty obvious when somebody has only heard of Prisma, but never used it. - Using `JOIN`s (with correlated subqueries and JSON) has been around for a while now via a `relationLoadStrategy` setting. - Prisma has a Rust service that does query execution & result aggregation, but this is automatically managed behind the scenes. All you do is run `npx prisma generate` and then run your application. - They are in the…

They've been saying that for 3 years. We actually had a discount for being an early adopter. But hey its obvious Ive never used it and only heard of it.

Re: Migrating to Postgres

#50
post #47
post #40

I've lost count of how many "Migrating from X to Postgres" articles I've seen. I don't think I've once seen a migrating away from Postgres article.

Here you go https://www.uber.com/en-CA/blog/postgres-to-mysql-migration/

Yeah so there's basically just that one ;)
Post reply on HN