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