Hi all, I don't think this thread has established consensus to replace Quarkus-managed data-sources.
The original POC appeared to address two things: * loading optional JDBC drivers at runtime and * creating data-sources dynamically as a possible building block for future per-realm routing. After the initial feedback, the proposed contract was narrowed to keeping Quarkus/Agroal as the default and providing a JVM-only escape hatch for drivers and data-sources that cannot use that model. A complete replacement was later raised as an option for avoiding two pool implementations. The subsequent Hikari-versus-Agroal discussion considers how Polaris-managed data-sources could be implemented, but I do not think it answers whether replacing the Quarkus-managed path is desirable in the first place. I have not supported removing the Quarkus-managed data-source path. The concrete ask I see is a viable path for optional drivers that Polaris cannot distribute in ASF releases. MySQL and MariaDB are relevant examples. Future per-realm data-source routing is a separate design and should not implicitly broaden this change. 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. I think we first need to decide between these options: 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. A project-wide Hikari-versus-Agroal choice only follows from option 3. Option 2 needs an implementation choice only for the escape-hatch path. If option 3 is proposed, it needs an independent rationale for moving supported deployments away from Quarkus-managed data-sources. My current preference is to preserve the Quarkus-managed path for supported drivers and address the optional-driver ask as narrowly as possible (option 1). Cheers, Robert On Thu, Jul 23, 2026 at 8:40 AM Romain Manni-Bucau <[email protected]> wrote: > Do you have a list of criteria for the choice? I assume none of us would > pick it cause it is one vendor or the name is cool and from what I read I > assume part of the features are better known on one side than the other so > maybe clarifying it before voting can be worth it? > > side note: some criteria can not be technical like "consistent with quarkus > ecosystem" or the one I mentionned "more than one dev". > > 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. 23 juil. 2026 à 05:28, Yufei Gu <[email protected]> a écrit : > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
