> 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.
Good point, Alex! I'm open to that. If the community agrees, I can make that change. Romain, I chose Hikari because it is lean, fast, simple. I'm open to alternatives like dbcp2 if its evaluation proves better. As you said, both have pros and cons. Yufei On Wed, Jul 15, 2026 at 11:03 AM Romain Manni-Bucau <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
