А зачем? Вы уверены, что десяток потоков в отдельном пуле

- это проблема для вас?

Да, это уже проблема несущная. Вариант с отдельными тредами это ок, но хотелось бы чтобы драйвер сам это умел

Зачем вам это в драйвере. Берите doobie - там все готово. В Slick тоже (но он умер).

Тут ещё нужно понимать, что соединения всё равно будут выполнять запросы синхронно.

а что-то типа такого асинхронного у скалы совсем нет для mysql или postgresql ? https://habr.com/ru/post/270709/

а у питона есть для mysql и pgsql?

На всякий случай примерно объясню, что имели в виду предыдущие ораторы В скале вместо async\await преимущественно используются библиотеки вроде cats-effect, zio for синтаксис используется вместо await. Возвращаемое значение типа ZIO[, , Foo], IO[Foo], или F[Foo] используется вместо async def ...(...): Foo СУБД, у которых исходный протокол асинхронный, т.е. поддерживает большое количество запросов, отправляемых через одно подключение, где результат может приходить не обязательно в том же порядке, в котором отправляется запрос, обычно имеют разной степени качества асинхронные драйвера. У SQL из-за исторической любви к последовательным протоколам потребность в асинхронности гораздо ниже, да и обычно предлагаемые драйвера - это подключаемые через jdbc интерфейс, т.е. совсем синхронные. Таким образом, вся асинхронность, что вам могут предложить - это пайплайн и автоматическое управление пулом. Решения навроде r2dbc ещё не достигли такой стабильности, чтобы поверх них что-т писали, есть один нативный драйвер для postgres, но потребность в таких всё ещё остаётся под вопросом. Однако все популярные scala библиотеки по-умолчанию асинхронные, возвращают что-то типа ZIO, ZStream, IO, F, Future или fs2.Stream

ООО, спасибо огромное за ценный комментарий. Ещё из потребностей у нас чтобы bulk запись была. Когда за раз 10k записей надо вставить....полка не увидела в quill. И ещё читаю их описание... If you like to “live dangerously” and want to try a socket-level async library, try quill-jasync-postgres or quill-jasync-mysql. Что они подразумевают под dangerous? 😅

Собрать все грабли первопроходцев. Можете стать первыми, кто найдет ошибки и единственными, кто будет заинтересован в их исправлении.

https://github.com/tpolecat/skunk

Как уже сказал Олег выше, если база в принципе не имеет поддержки асинхронности в протоколе (на уровне соединений), то ничего с этим не сделаешь. Я только указал на то, что все либы, которые для постгри делали якобы асиехронно, имеют в виду асинхронность максимум для потоков, а не для соединений

а какие у серверов ограничения на соединения. про потоки широко известно что типа 10к уже обычно начинает задыхаться тачка. особо продвинтое железо мол может 100к. а с соединениями что? или там на соединение всеравно поток нужен и одно сводится к другому?

потоки это треды? 10к тредов это _очень_ много

в линупсах в ядре много сделали, чтобы много коннекшнов можно было держать (в основном для субд), есть гайды как на 10М мегасервера настроить

Концептуально там нет никаких ограничений особо. Бд - это же тоже просто бэкенд. Только сложный. Но так получается, что у большинства классических sql баз исторически сложилось, что соединение - дорогой ресурс

Лолдог Расскажет что конкретно