That will make you lose a lot of productivity boosts SQL can give you.

Obviously, if you anticipate to have very high traffic and applicable usage patterns, do use that advice, but if your apps anticipated usage pattern is in fact not "very high rps per buck made", then I recommend the opposite.

I've went the whole way from very-well-abstracted-away services/repositories to an almost complete lack of abstraction.

Direct SQL or ORM in your functions, operating on many models at once, with a real postgres database available to all your unit tests, treating the SQL code as part of your application logic. Transaction per test so that unit tests are fast to run.

I've been very happy since. SQL is very powerful if you use it as SQL and not as a glorified KV store.