Using Objection for more than a year in a medium sized ERP project. Not bad, but for sure on the next project I will use directly knex as querybuilder (with no ORM part). The ORM part that Objection add to knex don't bring much value and add a layer of complexity. The only functionality that I would miss would be the graph operations (withGraphFetched, upsertGraph, ecc.) but writing them in SQL (using KNEX) would not be a great problem.
We're using knex at $dayjob, and we're not even using it for half our queries. Knex is pretty nice for simple CRUD operation, but for more complex queries we've found it much nicer to drop down to raw SQL (with knex.raw providing escaping).
What we have found helpful is to stick common queries into a helper function so that we can get a consistently shaped object back.
Have you considered a tagged template literal sql builder, such as https://github.com/blakeembrey/sql-template-tag ?
Keeps the SQL syntax so less to learn, but still offers parametrized queries.
Considered it, but I think that there are advantage in programmatically construct the query (see for example knex modify). Directly write down SQL or use template with sql make it harder. The only problem with knex is that it mutate at every operation instead of returning a new instance. I'm experimenting in wrapping it in a lazy monad that return a Fluture (https://github.com/FbN/iodio)
We use both in our code base. Sometimes knex makes sense, sometimes Objection makes sense. That's actually one of the nice things about it wrapping knex.
