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