Работал ли ты напрямую с PostgreSQL

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

Слово «напрямую» здесь ключевое: писали ли вы SQL руками и понимаете ли, что делает драйвер, или знаете базу только через генератор запросов. Для Go это обычный режим работы, тяжёлые ORM тут не прижились.

Как отвечать

Скажите, чем ходите в базу и что настраиваете.

• Драйвер и пул: pgx напрямую или через database/sql, размер пула, время жизни соединения, таймауты. Если между приложением и базой стоит пулер в режиме транзакций, подготовленные запросы ломаются и режим протокола приходится менять.
• Запросы: только плейсхолдеры, никакой склейки строк. QueryRow для одной строки, для выборки обязательны defer rows.Close() и проверка rows.Err().
• Контекст: у каждого запроса свой таймаут, иначе один тяжёлый отчёт съедает весь пул.
• Транзакции: явные границы, defer tx.Rollback(), осознанный уровень изоляции, повтор при конфликте сериализации.
• Рутина: sqlc или sqlx, чтобы не писать Scan руками, миграции отдельным инструментом, COPY для массовой заливки.

Про оптимизацию говорите предметно: EXPLAIN (ANALYZE, BUFFERS), индекс под конкретный запрос, замена цикла запросов на один с = any($1).

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

Собирают запрос конкатенацией строк с подстановкой значений. Это инъекция, и заодно каждый такой запрос уникален для планировщика.

Забывают закрыть rows или не смотрят rows.Err(). Соединения не возвращаются в пул, приложение встаёт на ожидании, а ошибка в середине выборки выглядит как просто короткий результат.

Ходят в базу без контекста и таймаута, а на вопрос про ускорение отвечают процентами вместо плана запроса. Первое кладёт сервис при первой же долгой блокировке, второе показывает, что замеров не было.