If down stream users need to build anything instead of mount the driver then polaris becomes a lib and not a server, think very few consumer see it this way nor would like it so I would favor runtime support.
The side note is that it is always better to not compète with its own stack so maybe two push back to quarkus natively before acting there. 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 ven. 24 juil. 2026, 17:50, Robert Stupp <[email protected]> a écrit : > Hi Yufei, > > Option 1 would not provide either capability at runtime in the upstream > Polaris distribution. > Optional drivers would be added through a downstream build or assembly, and > datasource creation would remain Quarkus-managed. > > That is intentional rather than a missing part of option 1. > I mentioned runtime driver loading and per-realm routing because they are > the two use cases stated for the POC, not because I think the project has > already agreed that Polaris itself must support both. > > The concrete current ask I see is a viable path for optional drivers that > Polaris cannot distribute in ASF releases. > Runtime loading is one possible answer to that ask. > A downstream build or assembly is another. > > Dynamic per-realm datasource creation is a separate future design. > I do not think it should become an implicit requirement for the > optional-driver decision before its isolation, lifecycle, resource, and > operational contract has been discussed. > > So before evaluating option 1 against option 2's capabilities, I think we > need to decide whether runtime driver loading and Polaris-owned dynamic > datasource creation are project requirements. > If both are requirements, option 1 is naturally excluded. > If they are not, the POC's additional capabilities should not by themselves > become acceptance criteria for every alternative. > > My preference remains to preserve the Quarkus-managed path and address the > optional-driver ask as narrowly as possible. > > Cheers, > Robert > > On Thu, Jul 23, 2026 at 8:59 PM Yufei Gu <[email protected]> wrote: > > > > > > > That ask does not by itself justify moving all supported deployments > away > > > from Quarkus datasource management. > > > Doing so would make Polaris responsible for configuration > compatibility, > > > lifecycle, health, metrics, tracing, credentials-provider integration, > > > shutdown, upgrades, and the support matrix currently covered by > Quarkus. > > > > > > > 1. Keep Quarkus-managed data-sources and document the downstream > > > build/assembly path for optional drivers. > > > 2. Keep Quarkus-managed data-sources as the default and add a > > deliberately > > > limited JVM-only runtime-driver escape hatch. > > > 3. Replace Quarkus-managed data-sources completely. > > > > > > My current preference is ... (option1). > > > > > > Robert, one thing I'm still unclear about is how option 1 would support > the > > following use cases that you mentioned: > > > > - Loading optional JDBC drivers at runtime. > > - Creating datasources dynamically as a building block for future per > > realm routing. > > > > My PR proposes option 2 because it addresses these use cases while > keeping > > the existing Quarkus managed deployment path unchanged. > > > > Yufei > > > > > > On Thu, Jul 23, 2026 at 8:59 AM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > > > Hi Yufei, > > > > > > I wonder why you chose Hikari initially in your PR 4984. Understanding > > that > > > rationale could be helpful for this discussion. > > > > > > Thanks, > > > Dmitri. > > > > > > On Wed, Jul 22, 2026 at 11:28 PM Yufei Gu <[email protected]> > wrote: > > > > > > > Looks like we have two options at this point: Hikari (Alex, me) and > > > Agroal > > > > (Dmitri, JB, Romain). > > > > > > > > Is there any further investigation we should do before making a > > decision? > > > > Or are we ready to start a vote? > > > > > > > > Yufei > > > > > > > > > > > > On Thu, Jul 16, 2026 at 10:15 PM Romain Manni-Bucau < > > > [email protected] > > > > > > > > > wrote: > > > > > > > > > Maybe add "is there more than one committer" on the project as a > > > > criteria. > > > > > Agroal is far to be my preferred pool but it is as easy as others > in > > > > terms > > > > > of config starting from properties ([1]) and using its listeners. > > > > > Also note that I assume all properties will not be exposed but > > > abstracted > > > > > by polaris configuration (potentially enabling a switch later or a > > > > > multipool support like in Apache TomEE) so maybe it is the first > > thing > > > to > > > > > define, the needed properties and callbacks? > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > https://github.com/agroal/agroal/blob/517fd36ab0cf1faebaae7d57a55c788d499a4c88/agroal-api/src/main/java/io/agroal/api/configuration/supplier/AgroalPropertiesReader.java#L56 > > > > > > > > > > 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 jeu. 16 juil. 2026 à 22:18, Alexandre Dutra <[email protected]> > a > > > > > écrit : > > > > > > > > > > > Hi all, > > > > > > > > > > > > I don't think the actual pool implementation matters much, but I > > > would > > > > > > weigh in some important criteria before choosing: > > > > > > > > > > > > - Is it easily configurable? > > > > > > - Is it easily instrumentable? > > > > > > - Is it well documented & maintained? > > > > > > > > > > > > While Agroal is the de facto choice for Quarkus (it's a JBoss > > lib), I > > > > > > am not sure it outperforms Hikari for all the criteria above. > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > On Thu, Jul 16, 2026 at 6:22 PM Yufei Gu <[email protected]> > > > wrote: > > > > > > > > > > > > > > Thanks everyone for chiming in. Agroal is a good option as > well. > > It > > > > > looks > > > > > > > like we're reaching consensus on direct datasource management > at > > > > > runtime. > > > > > > > I'll start working on the implementation soon. > > > > > > > > > > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 4:16 AM Jean-Baptiste Onofré < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > I agree that direct datasource management at runtime is a > > better > > > > > > > > approach than relying on quarkus-datasource, which currently > > > > requires > > > > > > > > build-time dependencies. > > > > > > > > > > > > > > > > However, we can stay within the Quarkus ecosystem and avoid > > > > > > > > introducing new dependencies by using Agroal, which is > already > > > > > > > > included in our dependencies. This also keeps the door open > to > > > > > > > > combining it with Panache in the future, should we decide to > do > > > so. > > > > > > > > > > > > > > > > Regards, > > > > > > > > JB > > > > > > > > > > > > > > > > On Thu, Jul 16, 2026 at 1:28 AM Yufei Gu < > [email protected] > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
