# vertx-sql-client: one reactive core, five database drivers > The Eclipse Vert.x reactive SQL client splits a shared non-blocking core from per-database driver modules, publishes release artifacts to Maven Central and development snapshots, and leans on a single TechEmpower round for its reputation. **eclipse-vertx/vertx-sql-client** — High performance reactive SQL client written in Java - Repository: https://github.com/eclipse-vertx/vertx-sql-client - Website: https://vertx.io/docs/vertx-pg-client/java/ - Stars: 913 · Forks: 217 - Language: Java - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/eclipse-vertx-vertx-sql-client ## A shared core with one directory per database The repository root is where the design shows itself. vertx-sql-client/ is the shared module, and five sibling directories carry the drivers: vertx-pg-client/, vertx-mysql-client/, vertx-mssql-client/, vertx-db2-client/ and vertx-oracle-client/. Two more modules sit alongside them, vertx-sql-client-codec/ for the encoding layer and vertx-sql-client-templates/ for query templates, with a single pom.xml at the root tying the build together. The README links to a separate documentation page for each of the five drivers, and the project homepage points at the PostgreSQL client documentation only, so the remaining drivers are documented elsewhere in the Vert.x site rather than here. For a team choosing a database client that structure is the point: the reactive plumbing is shared, the database specific parts are isolated in their own artifacts, and adding a second database later means depending on a second driver module rather than on a second copy of the client. ## What the TechEmpower ranking actually covers The README states that the project ranked number one in the TechEmpower Benchmark Round 15 single query benchmark, and the link it carries encodes the round, the hardware identifier and the test name. A ranking inside a named round is a narrow claim rather than a general promise. It describes one round, one query shape and one hardware configuration, and the README does not list the scores of the projects around it, the connection count, the JVM build, or the driver versions used for the run. It also does not date the round. The benchmark measures single query throughput, which puts a prepared statement, a network round trip and a result decode under load, and it says little about transaction heavy work, long running queries, or a production schema. A reader should treat the ranking as a reason to measure their own workload, not as a substitute for one. ## One thread and many connections is the stated design goal Both headline points in the README point the same way: a small API with low overhead, and non-blocking operation that can handle many database connections with a single thread. That is the constraint the rest of the project is arranged around, and it is also where the operational questions live. If one thread can carry a large number of open connections, then connection limits, downstream write pressure, transaction duration and idle connection handling all become matters for whoever writes the queries rather than for a connection pool in the traditional thread per connection shape. What this repository does not give you is any tuning reference. There is no documented pool size setting, no connection timeout value, no backpressure limit and no retry policy in the README, so the practical settings for a large connection count have to be looked up in the driver documentation that the README links to. ## The root directory carries build tooling and agent instructions Beyond the Java modules, the root holds .editorconfig, .github/, .gitignore, LICENSE.txt, CONTRIBUTING.md, AGENTS.md, CLAUDE.md and a directory named .agents/. The last three are unusual for a database client and suggest that the repository is now maintained with coding agents in the loop as well as by hand. The .github/ directory holds the workflow definitions, and the two build badges at the top of the README point at ci-5.x.yml and ci-4.x.yml, so two version lines are built and tested on every change. Two active lines matter when you pick a version: the 5.x line tracks the current Vert.x generation and the 4.x line stays available for applications that have not moved yet. The README does not say which Vert.x release each client branch corresponds to, so that mapping has to be confirmed in the pom.xml files inside the modules rather than assumed. ## Obtaining a release or development snapshot Released artifacts are available on Maven Central under the io.vertx group, including vertx-sql-client and database-specific driver modules. Choose the driver for your database and a release compatible with your Vert.x version. The project README also links to a Sonatype snapshot repository for development builds: ```text https://s01.oss.sonatype.org/content/repositories/snapshots/io/vertx/vertx-sql-client/ ``` Consult the linked driver documentation for configuration and verify the artifact version before adding it to your build. ## The lineage back to the original reactive-pg-client The README describes this project as the natural evolution of the original Reactive PostgreSQL Client and says it will be part of the Vert.x 3.8 stack release. The earlier project lives in a separate repository, github.com/vietj/reactive-pg-client, and the README states that it will only handle bug fixes. That split defines the upgrade path for anyone arriving from Vert.x 3.x: the 3.x line stays on the old repository with fixes only, while new work belongs in this one. The README also frames the shared core as the natural place for a driver that was originally PostgreSQL only, which explains why five drivers sit next to each other now. What the README does not offer is a migration note, a table of API differences between the 3.x client and this one, or a compatibility statement for the 3.8 stack, so an upgrade from the older code has to be planned against the driver documentation rather than from this page. ## Licence, maintenance and the gaps worth checking The licence file at the root is the Apache License, Version 2.0, and the README states the same thing, so there is no copyleft obligation to reason about when the client ships inside a commercial service. The repository is not archived and the last push was on 2026-10-15, which places current work on the five driver modules and the shared core. Maven Central publishes versioned release artifacts, while snapshots can change and require more care for reproducible builds. Review the relevant Vert.x release notes and driver documentation before upgrading. Before adopting, check three things against your own setup: the Vert.x generation your application runs, which of the 4.x or 5.x branch matches it, and whether the driver documentation page named in the README covers the connection settings you need. Those three checks, and not the benchmark ranking, decide whether this client is the right fit. ## Conclusion Adopt vertx-sql-client when your team already runs Vert.x, needs a non-blocking driver for PostgreSQL, MySQL, MSSQL, DB2 or Oracle, and chooses a compatible released driver. It is less suitable if you need a single artifact that covers every database or require tuning guidance beyond the linked driver documentation. Before writing code, verify the release coordinate you plan to depend on, check that the 4.x or 5.x branch matches your Vert.x version, and read the PostgreSQL client documentation linked from the project homepage, since the root README carries no configuration reference. ## FAQ ### Which databases does vertx-sql-client support? The repository ships five driver modules: vertx-pg-client, vertx-mysql-client, vertx-mssql-client, vertx-db2-client and vertx-oracle-client, all sitting on the shared vertx-sql-client module. ### How do I get the vertx-sql-client artifact? Released artifacts, including io.vertx:vertx-sql-client, are available on Maven Central. Select the database-specific driver and a version compatible with your Vert.x application; development snapshots are also published separately. ### Is vertx-sql-client actively maintained? The repository is not archived and the last push was on 2026-10-15, with continuous integration running for both the 4.x and 5.x lines. ### What is the difference between vertx-sql-client and the older reactive-pg-client? The README calls vertx-sql-client the natural evolution of the original Reactive PostgreSQL Client, which lives at github.com/vietj/reactive-pg-client and will only receive bug fixes for the Vert.x 3.x line. ## Sources - [eclipse-vertx/vertx-sql-client on GitHub](https://github.com/eclipse-vertx/vertx-sql-client) - [Issues](https://github.com/eclipse-vertx/vertx-sql-client/issues) - [License: Apache-2.0](https://github.com/eclipse-vertx/vertx-sql-client/blob/master/LICENSE) - [Project website](https://vertx.io/docs/vertx-pg-client/java/) - [README](https://github.com/eclipse-vertx/vertx-sql-client/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-vertx-vertx-sql-client