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 > > > > > > > > > > > > > > > > > > > > >
