Dumb question: why hikari? it has some issues like not respecting its conf intentionally (max size in particular is the one which hurts since you overconsume for a moment your database connections == prevent some services to connect when scaled and tuned at max count), there is no silver bullet but something like dbcp2 can be neat to start _there_ if agroal is not used as a base no - that said I dont see why switching at all, agroal can be used without build time integration and stay consistent with it if a day it comes back?
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le mer. 15 juil. 2026 à 19:13, Alexandre Dutra <[email protected]> a écrit : > Hi all, > > > If jdbc-url is set, Polaris creates and owns the Hikari datasource. If > it is not set, we keep using the existing Quarkus datasource path. > > I have strong reservations regarding this design. > > Alternating between a Hikari pool and an Agroal pool depending on the > configuration introduces unnecessary complexity and potential > confusion. A major drawback is that bugs, performance characteristics, > and configuration issues will vary across deployments purely based on > the underlying connection pool in use. > > If our goal is to transition entirely to a "runtime-driven" > architecture, we should commit to it completely by fully removing the > io.quarkus:quarkus-datasource dependency and switching to Hikari > unconditionally. > > Thanks, > Alex > > On Tue, Jul 7, 2026 at 7:10 PM Yufei Gu <[email protected]> wrote: > > > > Hi Robert, JB, Dmitri, > > > > Thanks, this feedback makes sense. > > > > There are really two motivations here: runtime loading of JDBC drivers, > and > > dynamic datasource creation. The former is useful for ASF binaries where > a > > driver is supplied after Polaris is built. The latter is a building block > > for future per realm datasources. > > > > I'm OK that Quarkus/Agroal remains the default for supported backends. > > That's already part of the POC. > > > > The gap I'm trying to address is where those assumptions no longer hold. > > Quarkus can select from predefined datasources, but they still need to be > > configured ahead of time. It doesn't currently provide Polaris with a > clean > > way to create new datasources dynamically. > > > > So my intent is for the contract to be: > > > > - Quarkus/Agroal remains the default. > > - Polaris managed JDBC is a JVM only escape hatch for runtime provided > > drivers and dynamically created datasources. > > - Polaris owns the pool and driver lifecycle on that path. > > - Per realm datasource routing should be a separate design discussion. > > It's out of scope for this POC. > > > > JB, I agree we should continue using Quarkus JDBC drivers for the > backends > > we support directly. This path is mainly for the cases outside that > model. > > > > Yufei > > > > > > On Tue, Jul 7, 2026 at 8:03 AM Jean-Baptiste Onofré <[email protected]> > wrote: > > > > > Hi > > > > > > Regarding JDBC drivers in the Quarkus ecosystem (in quarkus-extensions > or > > > quarkiverse), I think we can just leverage the quarkus JDBC drivers. > > > Using another loading mechanism could be problematic for future > features > > > (imagine with we want to try native app buld). > > > > > > What is the problem with using the Quarkus JDBC drivers? > > > I remember that we agreed to be opinionated about the JDBC backends we > want > > > to support, so we can be opinionated about the JDBC drivers :) > > > > > > I'm not against it, but I would like to understand better the > rationale. > > > > > > Regards > > > JB > > > > > > On Tue, Jul 7, 2026 at 3:03 PM Robert Stupp <[email protected]> wrote: > > > > > > > Thanks for pushing this forward. > > > > > > > > I agree that runtime-provided JDBC drivers are a real problem to > solve. > > > > For ASF-distributed binaries, there are valid cases where Polaris > should > > > > not bundle a driver, but operators still need a way to provide one. > > > > > > > > My concern is that this PR does more than load runtime driver jars. > > > > It also introduces a second datasource stack: Quarkus/Agroal via > > > > `quarkus.datasource.*` on one side, and Polaris-owned Hikari pools > via > > > > `polaris.persistence.relational.jdbc.*` on the other. > > > > > > > > Those two paths look similar to operators, but they do not have the > same > > > > contract. > > > > The Quarkus path brings Quarkus/Agroal lifecycle, health, metrics, > > > > credentials/secret-manager integrations, and the broader datasource > > > config > > > > surface; those are all important for operators. > > > > The Polaris-managed path means Polaris owns pool lifecycle, driver > > > loading, > > > > classloader behavior, and a separate config/support surface. > > > > > > > > So I do not think this is ready to move forward as just “another JDBC > > > > configuration option.” > > > > > > > > Before I would consider this mergeable, I think we need explicit > > > agreement > > > > on the contract: > > > > > > > > 1. Is Polaris-managed JDBC only a narrow escape hatch for > > > runtime-provided > > > > driver jars, or a peer supported datasource path? > > > > 2. Which Quarkus/Agroal integrations are intentionally not available > on > > > > that path? > > > > 3. What lifecycle does Polaris own for pools, loaded drivers, > shutdown, > > > and > > > > driver upgrades? > > > > 4. Is this meant to be part of future per-realm datasource routing? > If > > > so, > > > > I think that needs a separate design discussion. > > > > > > > > Until that contract is agreed, I do not think we should present this > as a > > > > second supported JDBC path or treat the PR as mergeable with > > > documentation > > > > updates alone. > > > > > > > > On Tue, Jul 7, 2026 at 3:48 AM Dmitri Bourlatchkov <[email protected] > > > > > > wrote: > > > > > > > > > Hi Yufei, > > > > > > > > > > Thanks for the update. That approach to loading the driver can > work, I > > > > > think. > > > > > > > > > > However, I'm not sure whether it is preferable to a proper Quarkus > > > > > downstream build. > > > > > > > > > > Adding jars to Polaris still requires some form of downstream > build, > > > > > whether it is tar-based or docker-based. > > > > > > > > > > Performing a full Quarkus build downstream offers some advantages, > > > > though: > > > > > > > > > > * Integration tests can be executed with the specific driver. > > > > > > > > > > * Dependencies are resolved / validated at build time. > > > > > > > > > > * Quarkus manages the DataSource lifecycle. > > > > > > > > > > I wonder what other people think too. > > > > > > > > > > Cheers, > > > > > Dmitri. > > > > > > > > > > On Mon, Jul 6, 2026 at 9:22 PM Yufei Gu <[email protected]> > wrote: > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > Good catch. The initial POC only proved the driver works if it’s > > > > already > > > > > > visible to the runtime classloader. > > > > > > > > > > > > I updated the approach so the Polaris-managed JDBC datasource can > > > load > > > > > > driver jars explicitly before creating Hikari. In the binary > > > > > distribution, > > > > > > users can drop jars into: > > > > > > > > > > > > server/jdbc-drivers/ > > > > > > > > > > > > For admin-tool bootstrap/purge, the same applies under: > > > > > > > > > > > > admin/jdbc-drivers/ > > > > > > > > > > > > They can also override the location with: > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.driver-directory=/path/to/jdbc-drivers > > > > > > > > > > > > So this does not depend on adding jars to lib/main or rebuilding > the > > > > > > Quarkus fast-jar metadata. The jar just needs to be present > before > > > > > Polaris > > > > > > creates the datasource. > > > > > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > On Mon, Jul 6, 2026 at 3:25 PM Dmitri Bourlatchkov < > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi Yufei, > > > > > > > > > > > > > > Could you provide some more details about how exactly a 3rd > party > > > > JDBC > > > > > > > driver is incorporated into Polaris? I might have missed that > in > > > the > > > > > PR, > > > > > > > but it was not apparent to me at first reading. > > > > > > > > > > > > > > Thanks, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Mon, Jul 6, 2026 at 6:22 PM Yufei Gu <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I put together a small POC( > > > > > https://github.com/apache/polaris/pull/4984 > > > > > > ) > > > > > > > > for > > > > > > > > the relational JDBC backend so Polaris can create its own > JDBC > > > > > > datasource > > > > > > > > from config, instead of always relying on the Quarkus > datasource. > > > > > > > > > > > > > > > > The config looks like this: > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.jdbc-url=jdbc:postgresql://... > > > > > > > > > polaris.persistence.relational.jdbc.driver=org.postgresql.Driver > > > > > > > > polaris.persistence.relational.jdbc.username=... > > > > > > > > polaris.persistence.relational.jdbc.password=... > > > > > > > > > > > > > > > > If jdbc-url is set, Polaris creates and owns the Hikari > > > datasource. > > > > > If > > > > > > it > > > > > > > > is not set, we keep using the existing Quarkus datasource > path. > > > > > > > > > > > > > > > > I also added tests showing that: > > > > > > > > > > > > > > > > - We can create datasources dynamically from config > > > > > > > > - Different configurations can create independent > datasources, > > > > > which > > > > > > > > could help future per-realm datasource support > > > > > > > > - A JDBC driver can be supplied at runtime from a jar > instead > > > of > > > > > > being > > > > > > > > on the build-time classpath. This is very helpful for > > > > proprietary > > > > > > and > > > > > > > > Apache license-incompatible drivers, like MySQL. > > > > > > > > > > > > > > > > This POC does not yet implement full per-realm datasource > > > routing. > > > > It > > > > > > > only > > > > > > > > demonstrates the lower-level building blocks: Polaris can > create > > > > > > managed > > > > > > > > JDBC pools from config, multiple pools can be created > > > > independently, > > > > > > and > > > > > > > > the JDBC driver can be supplied at runtime. > > > > > > > > > > > > > > > > Feedback is welcome before I turn this into a formal PR. > > > > > > > > Thanks, > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
