I tend to either use just plain SQL [1] or sqlc [2] [3]. With sqlc, you write plain SQL and it generates the (in my case, Go) boilerplate bindings for you. I don't find these approaches to be a mess, but both linked projects are admittedly small. I've used a similar approach on (non-OSS) codebases with thousands of DB functions/SQL statements though.

I don't disagree with you, ORMs can be a great time-saver for your average CRUD app, where the SQL queries tend to be straightforward SELECT/UPDATE/DELETEs on primary keys, assuming you don't mind the overhead of learning the DSL. But as your querying requirements get more complicated, you either have to:

- Keep the DB queries simple and do the complicated stuff (joining, aggregating, etc) in the business logic, or

- Learn how to express your complicated SQL in the ORM's DSL, or

- Drop into the ORM's "raw" mode and write plain SQL

The first option might be fine for non-performance-sensitive stuff, but otherwise isn't making good use of the database, and the latter two options reveal the SQL behind the curtains, at which point the abstraction of the ORM is more or less totally broken.

[1] Raw SQL: https://github.com/bcspragu/stronk/blob/main/db/sqldb/sqldb....

[2] sqlc: https://github.com/bcspragu/logseq-sync/blob/main/db/sqlite/...

[3] https://sqlc.dev/