/cc @FroMage (context-propagation), @Ladicek (arc,smallrye), @barreiro (jdbc), @geoand (devservices,kotlin), @jmartisk (smallrye), @manovotn (arc,context-propagation), @mkouba (arc), @phillip-kruger (smallrye), @radcortez (smallrye), @stuartwdouglas (devservices), @yrodiere (jdbc)

Perhaps this is only done when we detect that Hibernate runs, which is only done when we have at least one @Entity?

Try injecting the javax.sql.DataSource somewhere in your code - there is a chance that will enable it

The dev services are provided only when quarkus-agroal is in the classpath, because that's the extension that provides a concept of (JDBC) datasources, which dev services can then insert themselves in.
So just running this will solve your problem:

quarkus ext add agroal

Now, why do you even need to run this? Well, weirdly, quarkus-jdbc-postgresql depends on quarkus-agroal only optionally:

So goes for at least some (probably all) other drivers -- I checked h2. I am unsure if there is a reason for that -- do we want to provide a way for people to use JDBC drivers without defining datasources? Does that even make sense?

I would personally be in favor of adding a mandatory dependency to Agroal in all our JDBC driver extensions, because I am not aware of any documented use case for using JDBC drivers without Agroal.

If, on the other hand, we leave things as they are, I think we should update the documentation (https://quarkus.io/guides/datasource, https://quarkus.io/guides/databases-dev-services) to mention that most of those guides assume that you use Agroal when you use JDBC drivers. Good luck explaining that concisely and in such a way that nobody will miss it :/

Yeah, I stumbled upon this recently too and found the behavior surprising. I wanted to discuss it with you and then forgot.

I think the initial intent was that you might want to use the JDBC drivers with other connection pooling solutions (HikariCP comes to mind).

I'm not really sure how practical it would be for someone to come up with an extension for another pooling solution in the Quarkiverse. If we are already too tied to Agroal for it to happen, we could probably go one step further.

FWIW a quick search through the Quarkiverse org didn't reveal any DB connection pool.

Anyway, I'm pretty sure the dependency to Agroal is all over the place; the Hibernate ORM extension for example has hard dependencies on Agroal.

So, unless someone objects, +1 to depend on Agroal from JDBC driver extensions.

Nice catch guys ;) thank you

For more context information : I'm using quarkus + DuckDB. Duck does not require a postgres JDBC driver, it uses libpq C driver.

However, Duck can attach to postgres, which is my use case. as in https://duckdb.org/2024/01/26/multi-database-support-in-duckdb.html. pooling is in, its pooling is handheld in https://github.com/duckdb/postgres_scanner/blob/main/src/storage/postgres_connection_pool.cpp

I was expecting a postgres dev service to boot up simply to avoid booting one up using a dedicated docker-compose yaml under dev or test.

Sadly HikariCP has no quarkiverse extension obv. because Quarkus is tied to Agroal, plus people switching from other fwks (where either Hikari or legacy C3PO were used), well, migrate the pooling to Agroal.