Message-ID: <gh-pgjdbc-pgjdbc-3693-c3028381299@github.com>
From: "Sanne (@Sanne)" <noreply+Sanne@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Wed, 02 Jul 2025 15:50:49 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #3693: Overhead of uncontended use of ResourceLock
In-Reply-To: <gh-pgjdbc-pgjdbc-3693@github.com>
References: <gh-pgjdbc-pgjdbc-3693@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: Sanne
X-GitHub-Comment-Id: 3028381299
X-GitHub-Comment-Type: issue_comment
X-GitHub-Edited-At: 2025-07-02T15:51:55Z
X-GitHub-Issue: 3693
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/3693#issuecomment-3028381299
Content-Type: text/plain; charset=utf-8

hi @davecramer , sure among other JVM based platforms there's Vert.x (fully reactive, so can't use JDBC) and the Quarkus + Hibernate Reactive stack (also by my team, based on the same Vert.x driver).
 -  https://vertx.io/docs/vertx-pg-client/java/

It's performing extremely well. Our figures with Hibernate Reactive aren't great at the moment because of a design issue in the connection pool: there are novel challenges to solve over a "traditional" pool, but we'll fix them.

Personally I'm involved in both the "traditional" stack (blocking) based on JDBC and the alternative models, exploring things. I primarily want the various comparisons to be fair and want both to improve. 

There are also some extreme contenders on Techempower who have re-implemented everything from scratch. I wouldn't call those "production ready" personally, but by doing so they are setting a very interesting high bar in terms of performance results. I'd love us to be able to match such figures while still offering a reasonable programming model, maintainable and robust.