vertx драйвер, если ещё не посоветовали

vertx самостоятельный, а minity это аналог reactor :)

Можно и два через балансер. Но да, тут вопрос где делать распределение - на уровне сервиса в драйвере или на уровне сетевой инфраструктуры

Тут стоит понимать, что самый быстрый он из-за структуры бенчмарка. А бенчмарк там неочень.

Переехал на vertx, работает. В проекте: ktor + vertx-pg-client + vertx-lang-kotlin-coroutines. Из плюс есть сразу биндинги к корутинам, без всяких реакторов и т.д.
(Единственно надо еще подключать, com.ongres.scram:client, иначе не дает подключиться к postgres)

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

Ну, у techempower хорошая задумка: сделать похожий на end-to-end сценарий. При этом, в правилах запрещено программировать в красной зоне -- только нормально-выглядящий production код.

Конечно, не все авторы "реализаций" читают эти правила, и зачастую пытаются выбить побольше попугаев, уходя в красную зону :)


А потом оказывается, что в тесте "batch updates" (или как он там) предлагается в базе создать 1000 записей, и предлагается, что N потоков будут обновлять случайные  записи. Как так? Там же 100% либо блокировка либо дедлок. Задумка норм была, но бенчмарк кривой.
Надеюсь, этот тест не отражает суть ни одной продакш системы :)

Суть в том, что как только в бенчмарке начинают сравнивать не порядки, а проценты, всегда вылезает специфика постановки задачи самого бенчмарка и всегда будут те, кто обходят правила. Не говоря о том, что в микро-задачах многие качества не проявляются. Конкретно techempower нормален пока мы считаем разницей разницу в разы, а не на проценты

Касательно r2dbc vs jdbc -- в бенчмарке явно написано, что query pipelining приветствуется, и сама структура теста это приветствует.

Поэтому в результатах r2dbc нужно смотреть на код (там, кстати, полезно посмотреть как пишут на той или иной технологии) и на постановку задачи.

Я когда-то хотел подкрутить pgjdbc, но бенчмарк, который измеряет "скорость блокировок в базе" меня убил наповал.

К слову, в jdbc есть недостаток, что prepared statement batch не поддерживается для разнородных запросов. Только для запросов с одним sql. Конечно, вопрос насколько приложение готово собрать все свои запросы в одну batch кучку, но, в каком-нибудь Hibernate это можно было бы и сделать

А какое там обновление? Может у них там оптимистичная блокировка и ретрай, например?

"других бенчмарков у меня для вас нет"

Hibernate это кстати делает, у него даже есть хитрый способ упорядочить запросы, чтобы в батчи их сложить

Только techempower не микробенчмарк по определению.

Это от определения зависит, но хорошо, милли. Он все равно тестит одно маленькое поведение

Он тестит не одно поведение.

который все может сломать)

Именно

Там несколько сценариев. Как бенчмарк вполне себе бенчмарк.

Я говорю про батчевание:
* insert, update, и delete. Да, рано или поздно в pg завезут merge
* батчевание запросов к разным таблицам

Ни то ни другое в Hibernate невозможно из-за ограничений jdbc

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