А как принято? Кубер кажется избыточным, но вроде как могут  быть какие то неожиданные эффекты из-за того что окружения разные

Понял, гляну, спасибо

Нету принятого способа. Если есть возможность локально поднять максимально приближенно к проду, то лучше так. Но это не всегда возможно. Иногда проще некоторые сервисы отключить вообще (авторизация например) или подключиться к бд в инфре.

Но кажется вообще желательно избегать поднятия всего окружения. Писать тесты, в тестах поднимать контейнеры.

А почему не выделить логику, которая лазит в базу в один из хэндлеров, а другие оставить с другим функциями?(валидацию, сбор необходимых данных для похода в базу) и тд

С этого места поподробнее, плз) Просто кто во что горазд: одни мапят в контроллере, другие в сервисе, и интересно, откуда ветер дует (есть книга/статья где это описано?)

Например здесь
https://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
есть такое

Let's now look at a service level operation – which will obviously work with the Entity (not the DTO):

все очень просто, дто на самом деле может применяться на любое архитектурном слое приложения, это не противоречит паттерну никак

тем более дто это не только классы с таким суффиксом, ну и любой дата-класс

теперь что касается дто и сервисного слоя, тут тоже все очень просто

сервисный слой есть слой бизнес-логики, который определяет границу транзакции

по этой причине JPA-сущность не может никак присутствовать в веб-слое - она не может нормально функционировать без хаков в слое контроллеров

одним из таких хаков является open-in-view, который сразу должен отключен перед выкаткой в прод

из всего выше сказанного следует, что мы должны забрать данные из JPA-сущности в конце транзакции и передать дальше контроллерам - для этого и нужен DTO + mapper.

Если вы отдадите JPA-сущность в слой контроллеров после завершения транзакции, вы получите на дефолтных настройках LazyInitializateException

сервер будет 500-ками плеваться

если же не отключать open session in view, то у вас транзакция будет открытая на протяжении всей жизни запроса, что приведет потом к перегрузке пула и отказу приложения

Как по мне DTO больше к передаче инфы по сети относится. Внутри же основной логики работа идёт с доменной моделью. Хотелось бы ещё почитать именно какой-то  источник, где 1) описаны эти архитектурные паттерны в общем, 2) описаны в контексте спринга.
Просто никто особо не мешает маппить в контроллере: сервис принимает/возвращает модель в рамках транзакционного метода, контроллер мапит модель. Присутствие managed jpa сущности в контроллере не обязательно при этом.

Свой пул на получение коннекта, кажется. Твой код будет выполняться в твоём пуле. Разве нет?

Ну и в любом случае самому этот пул контролировать лучше.