[RamiAwar]

I've always said that the best ORM is one that allows for type safe query building.

This kind of generates the type safe queries for you, which is the end goal. But then why don't developers use the query builder instead? Why have an unnecessary generation step?

I feel like a good query builder ORM is more than enough and more straightforward than this. What am I missing?

[bccdee]

A query builder ORM is an abstraction I don't want and don't need. I know which SQL queries I want to run on my DB; please don't make me learn a whole DSL in order to run them. All I get in exchange for that is the extra work of translating my SQL into your DSL, plus the headache of circumventing the inevitable leaks in your abstraction.

I just want type-safe SQL templates that return native data structures. Sqlc provides that, and I've quite enjoyed working with it.

[paperplatter]

I prefer just using SQL without the query builder. If I'm ever concerned about type safety, I could wrap it in a function. Guess this tool does it for you, but separating your queries into .sql files seems like more effort.

[stanleydrew]

One of the design principles of sqlc is that SQL queries should be static in application code so that you know exactly what SQL is running on your database. It turns out you can get pretty far operating under this constraint, although there are some annoyances.

[dlisboa]

The query builder is yet another mini language that you have to learn and they change for each ORM so learning one is mostly wasted time.

Many times I’ve been stuck in a place where I knew exactly how to write the SQL for it but had to spend several minutes studying the ORM docs to learn how to express it.

SQLc also has the advantage of static checking your queries.

It has some other disadvantages so it’s not all rosy.

[paperplatter]

Last time I used a query builder, I accidentally used its orderBy in some invalid way that it didn't complain about. Just silently didn't ORDER BY the cols I wanted.