Как устроена работа с PostgreSQL в проекте

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

Работали ли вы с базой осознанно и знаете ли специфику именно PostgreSQL.

Как отвечать

Разложите по слоям.

Подключение. Драйвер плюс пул соединений, обычно HikariCP. Важная деталь: размер пула не должен быть большим. Соединений больше, чем ядер у базы, не ускоряют, а создают конкуренцию, и типичное рабочее значение это десяток, а не сотня.

Доступ к данным. Spring Data JPA с Hibernate для основной логики, а для сложных запросов и пакетных операций прямой SQL через шаблон запросов или jOOQ. Смысл смешивать в том, что ORM удобен для графа объектов и бесполезен для аналитического запроса с оконными функциями.

Миграции. Liquibase или Flyway, файлы в репозитории, применение отдельным шагом выкладки, а не при старте приложения.

Транзакции. Декларативные границы, короткие транзакции, никаких сетевых вызовов внутри. Уровень изоляции по умолчанию это чтение подтверждённого, повышают осознанно.

Что даёт именно PostgreSQL и что стоит назвать:

• jsonb с индексами, закрывающий большую часть документных сценариев;
• вставка с обработкой конфликта для операций «создать или обновить»;
• общие табличные выражения и оконные функции для аналитики без выгрузки данных в приложение;
• частичные и покрывающие индексы, индексы по выражению;
• секционирование больших таблиц по дате;
• полнотекстовый поиск и расширения, включая векторный поиск.

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

Тестирование. Настоящая база в контейнере, а не заменитель в памяти: только так проверяются ограничения, типы и поведение транзакций.

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

Ставят огромный пул соединений.

Не смотрят план выполнения и добавляют индексы наугад.

Применяют миграции из приложения при старте.

Тестируют репозитории на базе в памяти и считают это проверкой.