Идея упростить или абстрагировать код с помощью ORM, возможно, имеет очень ограниченный контекст применимости. По сути ORM хорош для приложений уровня простого CRUD, а дальше начинает только мешать. А CRUD-приложений в реальной жизни очень мало.  В итоге, кстати, некоторые производители ORM даже пытаются прикрутить свой собственный абстрактный недоSQL на объектах бизнес логики, например, как в DOCTRINE: или Hibernate: В итоге непонятно, для чего козе боян, ведь обычный SQL — это и так абстракция над бизнес-сущностями и их взаимосвязями, и обвешивать это ещё одним слоем с птичьим языком (или тем более с птичьим SQL-языком), игнорируя все проблемы перформанса — это просто странно. А под капотом ORM делает иногда такое, что волосы дыбом. Есть ещё такое мнение, что ORM — это слой, абстрагирующий от способа хранения. Мол, сегодня ты пишешь на MySQL, завтра на Postgres, после завтра вообще в файлах хранишь — и тебе пофиг, код остаётся тем же. Чистая архитектура. Ну это вообще обычно ерунда, конечно. Уродовать код и замедлять разработку, чтобы с вероятностью 0.01% захотеть переехать на другую базу — ну такое. Про чистоту архитектуры тоже можно вставить 5 копеек, чтобы два раза не вставать. Очень часто слои пересекаются. Как ни крути, но делать абсолютно 100% независимый слой бизнес-логики (юзкейсы, сервисы) иногда бывает очень дорого. Например, если тебе надо построить хитрый отчёт, ты будешь использовать SQL с группировками, оконными функциями, фильтрами и джойнами, выжимая из базы данных всё, что можно, включая грязные хаки. Там будет не до абстракций. Да просто сделать group by и посчитать количество тех, у кого count больше одного — это ведь уже бизнес-логика, вшитая в SQL.  С другой стороны, писать совсем простейшие запросы вручную задалбывает, конечно, поэтому какой-то гибридный подход, наверно, может и подойти в некоторых ситуациях. Но даже в простых вещах нужно быть осторожным: на практике встречал удивление а-ля "а почему у нас при формировании этой страницы к базе уходит 254 запроса, мы ж только табличку вывели?" На данный момент в Go хоть и существуют ORM (например, gorm.io/gorm), но большинство команд ими не пользуется. Просто потому, что в языке Go на любую магию традиционно смотрят с подозрением. По задумке авторов Go простой как дрова. При этом проблемы сырых запросов решаются точечно. Где-то просто пишется SQL, но, например, если нужно запрос составлять из частей по определённым условиям (например, фильтры, прилетающие из формы), можно использовать squirrel (query builder): Это безопаснее и проще, чем конкатенировать из частей. Тем не менее это именно queryBuilder, а не ORM, т.е. нет отображения сущностей на реляции, нет магических неявных джойнов под капотом. Если же надо получать из запроса структуру данных, не перечисляя каждый раз поля, то можно это сделать с помощью sqlx: Здесь есть немного магии, так как библиотека используется reflection, но это чисто технический, не особо принципиальный момент. Тема БД всегда очень сложна и холиварна. В проектах Каруны есть разные языки и разные команды, и подходы к работе с БД тоже сильно отличаются. На Руби ORM используется в основном очень плотно, на Go его почти нет, и т.д. Поэтому выражу только своё персональное мнение: в реальных (не CRUD) проектах абстрагироваться от данных в базе бывает слишком дорого (читабельность и производительность), а ценности такое абстрагирование даёт очень мало, ведь SQL сам является абстракцией над бизнес сущностями.  Самое забавное, что использовать или нет — это скорее вопрос традиций в конкретном стеке. Кстати, часто слышал, что в C# какой-то особенный подход к ORM, и там всё супер. Буду рад, если поделитесь реальными впечатлениями в комментариях. К сожалению, мало что знаю про этот язык. Статья является компиляцией идей из канала Cross Join  Go-тимлид, веду канал https://t.me/crossjoin