A new JDBC driver for PostgreSQL called pg-java has been written from scratch by Sehrope Sarkini (with assistance from Claude). Currently in pre-release, it takes a PostgreSQL-native approach rather than designing around JDBC's lowest-common-denominator abstractions. The JDBC compliance layer sits on top of the native API rather than dictating its shape. Leveraging Java 21 virtual threads, it uses ordinary blocking-style code with ReentrantLock instead of synchronized around I/O, enabling thousands of connections without an event loop or callback API. The core query primitive is a pull cursor that reads only enough data to produce the next row, avoiding full result set buffering.
Table of contents
PostgreSQL-first.JDBC as a layer, not a foundation.Virtual threads for I/O.Streaming by default.Questions this post answers
How does the new pg-java PostgreSQL JDBC driver handle concurrency without an async API?
pg-java uses Java 21 virtual threads with ordinary blocking-style code, carefully avoiding carrier thread pinning by using ReentrantLock instead of synchronized around I/O. This allows thousands of connections to run concurrently without an event loop or callback API, making the code significantly easier to reason about compared to traditional async or reactive drivers. Java developers choosing between async and virtual-thread approaches for PostgreSQL connections track developments like pg-java on daily.dev.
What is the core query execution model in pg-java?
The core query primitive in pg-java is a pull cursor that reads exactly enough data off the wire to produce the next row, never buffering a whole result set. Higher-level operations like forEach, map, and collect are adapters built on top of this cursor, not a separate read path. Developers optimizing PostgreSQL query performance in Java can follow pg-java's progress and related database driver news on daily.dev.
68.4K Impressions1 Comment