[tmjdev]

It looks like as an ORM gets more expressive it looks more like regular SQL. What is a reasonable argument for using an ORM over writing SQL?

I always feel like I'm missing something because it looks like you have to learn a specific library instead of a general purpose language.

[AspireOne]

Depends on the environment - in rust for example, you can get by with raw sql using sqlx and it'll have typed queries and outputs. In typescript, that's just not possible, so an ORM as a thin layer above the SQL is a great middleground - you'll get type safe everything, including some basic raw sql queries. I'm using Kysely for a production app (which for example exposes a "sql" macro which can be used to write simple raw typesafe queries), and it's miraculous how far they have pushed the typescript engine. I have no complains at all.

[reducesuffering]

I'm using Prisma ORM over Drizzle (didn't exist when I started).

When I need to add new data to a table I have, I just put the "new_column Type" in my prisma.schema for table X. and run "npx prisma migrate dev." Then everywhere else in my code, I already have the updated type for my object X.new_column and can access it with the guardrails of not betraying what type it is.

I'd rather do that than ALTER TABLE to create and update my read queries, while making sure I don't make a mistake in the raw SQL.

[tmjdev]

Guardrails seems to be a common argument. It feels heavy handed though to use an entire library/ecosystem to ensure you don't have typos, your tests should catch them anyhow.

And migrations are a separate feature that a number of ORMs have, you can have clean migrations with pure SQL using a tool like gomigrate.

I think the real utility is that the ORM is doing the marshalling for you.

[monssoen]

This library tries to get as close to sql as possible. Basically write sql through function calls. Your IDE will autocomplete which method to call. What you gain is type safety. Change the name or type of a column and it propagates through your codebase.