Использовали ли вы ORM с Go и PostgreSQL

Что проверяют

Интересует не название библиотеки, а понимание компромисса: что ORM даёт в Go и где мешает. Сообщество Go к ORM относится сдержанно, и интервьюер часто проверяет, знаете ли вы альтернативы. Следом спрашивают, как вы боролись с N+1 или почему выбрали именно этот инструмент.

Как отвечать

Начните с фактов своего проекта: что использовали, почему, что бы поменяли. Карта инструментов поможет показать кругозор:

• GORM: самая популярная полноценная ORM, на рефлексии. Быстрый CRUD, связи, хуки, мягкое удаление;
• ent: схема описывается кодом на Go, по ней генерируется типобезопасный клиент. Удобен для сложных графов сущностей;
• bun: легче GORM, ближе к SQL, хорошо работает с PostgreSQL;
• sqlc: не ORM. Пишете SQL, а он генерирует типизированные Go-функции. Ошибка в запросе видна на этапе генерации;
• sqlx и pgx: sqlx добавляет к database/sql сканирование в структуры, pgx это драйвер с нативным протоколом Postgres, пулом pgxpool, COPY и LISTEN/NOTIFY.

Для схемы берут версионные миграции: goose, golang-migrate или Atlas. AutoMigrate из GORM годится для прототипа, но колонки не удаляет и истории версий не ведёт.

Хороший ответ звучит так: «использовал GORM на CRUD-сервисе, горячие отчётные запросы переписали на сырой SQL через pgx, потому что...». Нужны ваши примеры и ваши цифры. Если ORM не использовали, так и скажите и объясните, чем работали вместо неё: связка sqlc и pgx в Go считается нормальным осознанным выбором.

Где спотыкаются

Не знают, что Updates в GORM со структурой пропускает нулевые значения: false, 0 и пустая строка в базу не попадут. Нужна мапа или явный Select.

Получают N+1: связи подгружаются в цикле по одному запросу. В GORM это лечится Preload или Joins, а сгенерированный SQL стоит смотреть через Debug().

Считают, что ORM сама защищает от SQL-инъекций. Параметры в Where("name = ?", name) безопасны, а строка, склеенная через fmt.Sprintf или переданная из запроса в Order, уязвима так же, как голый SQL.