Любители асинхрона уповают обычно на ужасные расходы, связанные с тредами.

Кому это интересно?

но при любом запросе к БД они все будут ждать пока вот база по одному запросу на коннекшен не обработает

вы, случаем, не про это https://www.reactivemanifesto.org/ ?

А если треды не экономить - то зачем вам вообще какой-то асинхрон?

Асинхрон обычно нужен чтобы быстрее "вернуть" результат, чаще всего - для снижения времени отклика.

Если в ответе константа, то это должно помочь, да. А если ответ нужно ещё откуда-то получить?

обычно отказ от ORM огорчает тех, кто вложил свое время в его изучение и набивание шишек, в ущерб SQL))

мучения одни только с такими разрабами.

если чел не знает SQL, какой толк от него вообще на бэке

да. тут важно вовремя остановить юнца, а то с этими ORM можно дико упороться

Вам нужно в целом обеспечить согласованность. Это можно сделать разными способами. Нужны конкретные кейсы.

Суть в том, что можно вернуть результат до того, как база отдуплит. Иными словами, быстрыми/асинхронными могут быть не все компоненты. Важно привести систему к согласованию в конечном итоге.

Да ну нахер)) Мы несколько раз проводили такой эксперимент.

Исп паттерн DAO, чтобы в случае необходимости уйти от ORM на чистый JDBC. И почти всегда ORM и генерируемый им SQL при правильном дизайне не был бутылочным горлышком.

я видел два адекватных варианта. Либо используется ORM, либо DBA делают хранимки и дергаются хранимки. Вариант с "разрабы руками пишут SQL" практически всегда приводит к проблемам.

В одном решении мы работали на пределе базы по вставке. Практически вся обработка была асинхронной. А результаты просто сбрасывались балками из очереди (Kafka).

Тут всё зависит от компетенций как разработчиков БД, так и разработчиков бэка. В идеале же БД должна быть тупым хранилищем, где минимум логики. А это приводит к тому, что разработчики бэка должны хорошо разбираться как в SQL, так и в других языках других БД, при этом понимая, как добиться простыми запросами согласованности

Всё не так просто. Кто-то должен ручками прописывать DDL, структуру таблиц, индексы и пр.

Поэтому, из моей практики, часто нужно иметь всего пару человек в команде, кто хорошо знает конкретную базу и пишет скрипты. Именно "их" код ложится в liquibase/flyway. Остальные спокойно могут использовать ORM.

классно придумали. беру на вооружение)

Опыт у всех разный.  Все широко использующие зашитую в БД логику (хранимки и т.п.) проекты, в которых я лично участвовал, или которые наблюдал с близкого расстояния, невозможно вспоминать без содрогания.  Разработчики же, знакомые мне, не испытывают никаких затруднений с написанием в случае необходимости (рекурсивные выборки и т.п.) SQL запросов руками и проанализировать результаты explain тоже вполне в состоянии.

Э, SQL + JDBС Templates или что-то похожее. Это и проще и быстрее и удобнее.