I'm a little confused about where we're landing with [4812]. The thread opened with the goal of letting users switch database providers at runtime without rebuilding Polaris (e.g. PostgreSQL → MySQL). But as far as I can tell, we can't ship MySQL Connector/J in an official Apache release anyway (it's GPLv2 Category X). The same applies to MariaDB's driver (LGPL). So for MySQL users, we're still back to: build your own distribution with the driver included. Runtime datasource selection doesn't change that.
What [4812] actually delivers for official releases, as I understand it, is a single binary that can select between H2 and PostgreSQL at deploy time. Alex clarified on this thread that it doesn't change the persistence design and that separate pools for metrics/events is future work (#3960). That H2/Postgres split seems useful for dev/demo (docker run without Postgres), and I can see the release-engineering benefit of one artifact. But I'm not sure it helps operators who need a different JDBC backend: they still have to rebuild (or run a custom image) to get a driver we can't ship. The "pick your driver at runtime without rebuilding" story also seems odd if the intended workflow is "declare every driver you might ever use at build time, then activate one at runtime." That's pre-committing to drivers you may never use. On that point: we've raised concerns on other PRs about shipping code users won't run at runtime because of CVE exposure. Romain noted on this thread that H2 has recently had CVEs. If we're Postgres-only in prod, are we comfortable bundling H2 in the server image for everyone? So I'm trying to reconcile: The stated goal (switch providers without rebuild) vs. what ASF licensing actually allows us to ship Whether the H2+Postgres convenience is worth the config breaking change and extra driver in the image Whether we should frame this as infrastructure for future multi-pool work (#3890) rather than "multiple datasources" for users Happy to be corrected if I'm missing something but from where I sit, [4812] looks like a useful Quarkus refactor and dev-mode enabler, not a solution for multi-JDBC-driver deployments. On Thu, Jun 25, 2026 at 3:50 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi All, > > The way I see it is that Alex's PR [4812] is an incremental improvement at > the technical level in our Quarkus server. > > It does not impose or require any redesign right now. Yet, it enables more > options for future consideration. > > I think it is worth merging "as is" for now. Then we can resume the > discussions about realm and database association. > > [4812] https://github.com/apache/polaris/pull/4812 > > Cheers, > Dmitri. > > On Thu, Jun 25, 2026 at 12:01 PM Alexandre Dutra <[email protected]> > wrote: > > > Hi Yufei, > > > > > > > if Polaris managed the connection pools itself using HikariCP [...] > > would that also solve both the "no rebuild" requirement? > > > > Yes, that would work. > > > > However, we need to consider some significant tradeoffs: > > > > - Manual lifecycle management becomes necessary (handling shutdown > > hooks, pool eviction during catalog drops, etc.). > > > > - Native image support is lost. While Polaris official images don't > > use them yet, this would block that path for future development. Also, > > integrators may be building Polaris in native mode today. > > > > - Loss of @DataSource CDI injection. > > > > - Loss of integrated health checks and metrics. > > > > - Loss of Dev Services (though this is less critical as we don't > > currently use them). > > > > > Am I missing something? If not, this seems worth prototyping. > > > > To me, sacrificing the above benefits just to allow runtime selection > > of a single (!) datasource feels overkill. My PR [4812] achieves the > > same objective without these drawbacks. What makes the HikariCP > > approach preferable in your view? > > > > If the goal is to revisit the datasource-per-realm discussion, we > > should prioritize a design document over a POC. Such a change would > > fundamentally reshape Polaris internals. We still haven't settled on > > the core architecture: should it be database-per-realm, per-catalog, > > per-store-type (as seen in [3960]), or a combination of these? > > > > Thanks, > > Alex > > > > On Thu, Jun 25, 2026 at 2:30 AM Yufei Gu <[email protected]> wrote: > > > > > > Thanks for the clear explanation, Alex. I think the use cases for > > avoiding > > > rebuilds make sense. > > > > > > One question: if Polaris managed the connection pools itself using > > HikariCP > > > (or Agroal/DBCP directly), instead of relying on Quarkus' datasource > > > extension, would that also solve both the "no rebuild" requirement and > > the > > > dynamic datasource problem? > > > > > > My understanding is that, in JVM mode, users could simply provide the > > > appropriate JDBC driver JAR on the classpath or Polaris can ship them > if > > > possible and configure the driver class and JDBC URL at runtime, > without > > > rebuilding Polaris. If that's correct, this seems to address the > primary > > > goal while also avoiding Quarkus' build time datasource limitation. > > > > > > For example, switching databases would simply become: > > > polaris.persistence.jdbc.driver=com.mysql.cj.jdbc.Driver > > > polaris.persistence.jdbc.url=jdbc:mysql://... > > > > > > HikariCP can load the driver at runtime, as long as the MySQL driver > JAR > > is > > > available on the classpath. > > > > > > Am I missing something? If not, this seems worth prototyping. I'd be > > happy > > > to help build a small POC to validate the approach. > > > > > > Yufei > > > > > > > > > On Wed, Jun 24, 2026 at 6:50 AM Alexandre Dutra <[email protected]> > > wrote: > > > > > > > Hi Yufei, > > > > > > > > The primary goal is straightforward: we want to eliminate the need > for > > > > users to rebuild Polaris simply to switch their database provider > > > > (e.g., moving from PostgreSQL to MySQL). > > > > > > > > Let's take the MySQL PR [4281] as an example: as it is designed > today, > > > > users are forced to rebuild Polaris using the includeMysqlDriver > build > > > > property. This constraint prevents them from using official Polaris > > > > images and forces the maintenance of custom images. > > > > > > > > With the proposed changes in [4812], users would instead simply use > > > > the official image and apply a runtime configuration: > > > > polaris.persistence.relational.jdbc.datasource=mysql. This > effectively > > > > removes the burden of custom builds and image management. > > > > > > > > To clarify, [4812] does not change ANYTHING in the current datasource > > > > design. It's still one single datasource for all data. > > > > > > > > I briefly mentioned multi-datasource to demonstrate that my changes > > > > wouldn't block [3960] if we decide to pursue it later. As a reminder, > > > > [3960] was introducing the ability to use a separate datasource for > > > > metrics and events. > > > > > > > > If you'd like to revisit the datasource-per-store-type design from > > > > [3960], or revive the datasource-per-realm design [1], I'm happy to > > > > discuss those further. But [4812] is really only about runtime > > > > selection of fixed datasources. > > > > > > > > Thanks, > > > > Alex > > > > > > > > [3960]: https://github.com/apache/polaris/pull/3960 > > > > [4281]: https://github.com/apache/polaris/pull/4281 > > > > [4812]: https://github.com/apache/polaris/pull/4812 > > > > > > > > [1]: > https://lists.apache.org/thread/kvt3gd29hyxlhnwxr9b674s555jlvjjs > > > > > > > > On Wed, Jun 24, 2026 at 3:24 AM Yufei Gu <[email protected]> > wrote: > > > > > > > > > > Hi Alex, > > > > > > > > > > I'm still trying to understand the intended use cases behind PR > 4812. > > > > > > > > > > The examples discussed so far focus on runtime selection between > H2, > > > > > PostgreSQL, MySQL, etc. In those cases, it seems the requirement is > > to > > > > > choose one datasource implementation at runtime, while the actual > > > > > datasource definitions remain known at build time. > > > > > > > > > > The use case I'm more familiar with is multi realm support, here is > > an > > > > > example[1]. In that model, each realm could potentially have its > own > > > > > database configuration, which implies dynamic datasource creation > and > > > > > lifecycle management at runtime. The number of datasources is not > > known > > > > > ahead of time and can change as realms are added or removed. If > > Polaris > > > > > needs to support that model in the future, The Quarkus datasource > > > > extension > > > > > may not be the right abstraction, since it is fundamentally > centered > > > > around > > > > > datasources defined at build time. PR 4812 works around this > > limitation > > > > by > > > > > predeclaring datasource definitions and activating them > selectively, > > but > > > > > that approach does not seem to generalize well to truly dynamic > > > > datasource > > > > > provisioning. > > > > > > > > > > For dynamic realm backed datasources, the cleaner design may be a > > Polaris > > > > > managed pool registry using DBCP, HikariCP, or Agroal directly, > > rather > > > > than > > > > > relying on Quarkus datasource configuration. That would allow > > datasource > > > > > pools to be created, updated, and removed dynamically as realms are > > > > managed. > > > > > > > > > > Could you elaborate a bit more on the concrete use cases you have > in > > mind > > > > > for PR 4812? I'm trying to understand whether the primary goal is > > runtime > > > > > selection among a fixed set of datasources, or whether it is > > intended as > > > > a > > > > > stepping stone toward more dynamic datasource management. > > > > > > > > > > 1. https://github.com/apache/polaris/discussions/4761 > > > > > > > > > > Thanks, > > > > > Yufei > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2026 at 12:47 PM Romain Manni-Bucau < > > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Guess it depends if you do use native-image or not, didn't check > in > > > > latest > > > > > > version except the github sources of some datasource but the > trick > > was > > > > > > working well in java mode (guess the recommended mode for > polaris) > > so > > > > I'm > > > > > > not sure why it wouldn't work - and in native mode the entrypoint > > is > > > > not > > > > > > even a java command so not a real concern, isnt it? > > > > > > > > > > > > > > > > > > From what I do see in h2, db2 etc modules there is nothing crazy > > > > requiring > > > > > > build time wiring (for java mode once again) so I think it will > > work. > > > > > > Worse case you can easily do a quarkus-jdbc-generic since at the > > end > > > > it is > > > > > > mainly hints for native-image and a few auto loading (driver for > > ex) > > > > but > > > > > > using any pool programmatically - as polaris does handle the > > datasource > > > > > > programmatically for ex - will does it. > > > > > > > > > > > > So overall think it works but happy to look if it doesn't work. > > > > > > > > > > > > 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. 19 juin 2026 à 18:51, Alexandre Dutra <[email protected] > > > > a > > > > écrit > > > > > > : > > > > > > > > > > > > > Hi Romain, > > > > > > > > > > > > > > I don't think your trick would work with Quarkus, would it? As > > the > > > > > > > driver has to be present at build time. > > > > > > > > > > > > > > Also, I think we want to achieve an "it just works" kind of > user > > > > > > > experience. That's the main reason for including h2 as we want > a > > > > > > > simple "docker run apache/polaris" to "just work". > > > > > > > > > > > > > > Thanks, > > > > > > > Alex > > > > > > > > > > > > > > On Fri, Jun 19, 2026 at 6:46 PM Romain Manni-Bucau > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > Why providing h2 in the image? I know a common trick I do use > > is > > > > to set > > > > > > > the > > > > > > > > classpath in my entry point to something like > > > > > > > > "myjar1.jar:myjar2.jar:.....:/opt/app/extensions/custom/*" - > > with > > > > jib I > > > > > > > > do > > <extraClasspath>/opt/app/extensions/custom/*</extraClasspath>. > > > > > > > > This enables to mount the JDBC driver in this custom folder > and > > > > get it > > > > > > > > working OOTB, with helm it is just a matter of mounting > either > > an > > > > OCI > > > > > > > image > > > > > > > > with just the driver in this folder or using an init > container > > to > > > > copy > > > > > > it > > > > > > > > using an empty dir/ephemeral volume as pivot folder. > > > > > > > > The good thing about that is: no default driver required but > > open > > > > to > > > > > > any > > > > > > > > so no related CVE (h2 got several by the past which would be > a > > > > negative > > > > > > > > aspect for prod when using pg for ex). > > > > > > > > > > > > > > > > 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. 19 juin 2026 à 17:18, Dmitri Bourlatchkov < > > > > [email protected]> a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > Focusing on the technical capabilities of PR [4812], I > think > > it > > > > > > > provides a > > > > > > > > > valuable enhancement and we should merge it. > > > > > > > > > > > > > > > > > > I do not see any adverse effects of this PR on existing > > > > > > functionality, > > > > > > > but > > > > > > > > > it certainly opens new use cases like H2 inside pre-built > > docker > > > > > > > images and > > > > > > > > > MySQL (potentially). > > > > > > > > > > > > > > > > > > [4812] https://github.com/apache/polaris/pull/4812 > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > On Fri, Jun 19, 2026 at 4:59 AM Alexandre Dutra < > > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > Although the conversation has shifted toward > > multi-datasource > > > > > > > support, > > > > > > > > > > the primary focus in this thread remains [4812]: the > > ability to > > > > > > > > > > activate a datasource at runtime, even in single-source > > > > scenarios. > > > > > > > > > > > > > > > > > > > > I want to emphasize that this functionality is essential > > > > > > > independently > > > > > > > > > > of the multi-datasource debate. For example, it is > > required to > > > > > > > provide > > > > > > > > > > out-of-the-box support for JDBC + H2 within Polaris > > images, and > > > > > > also > > > > > > > > > > to provide support for more databases (e.g. MySQL). > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > [4812]: https://github.com/apache/polaris/pull/4812 > > > > > > > > > > > > > > > > > > > > On Thu, Jun 18, 2026 at 9:28 PM Dmitri Bourlatchkov < > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Romain, > > > > > > > > > > > > > > > > > > > > > > Thanks for the info! > > > > > > > > > > > > > > > > > > > > > > Metrics requests generally read from the MetaStore but > > write > > > > only > > > > > > > in > > > > > > > > > the > > > > > > > > > > > Metrics datasource. > > > > > > > > > > > > > > > > > > > > > > The latest thinking about Events is to isolate them > from > > the > > > > > > > initial > > > > > > > > > > > request via the Quarkus Event Bus (async delivery), > IIRC. > > > > > > > > > > > > > > > > > > > > > > The new Idempotency feature [3] might be the first case > > > > where we > > > > > > > > > (could) > > > > > > > > > > do > > > > > > > > > > > writes into multiple datasources. However, the way it > is > > > > designed > > > > > > > does > > > > > > > > > > not > > > > > > > > > > > assume or require coordination of changes / commits > > between > > > > the > > > > > > > > > MetaStore > > > > > > > > > > > and the Idempotency data store, AFAIK. > > > > > > > > > > > > > > > > > > > > > > In general, this is a very interesting topic. It has > > > > implications > > > > > > > for > > > > > > > > > our > > > > > > > > > > > (MetaStore) Persistence interface contracts too. IIRC, > > > > previous > > > > > > [1] > > > > > > > > > > > discussions generally settled on the idea that each > > > > Persistence > > > > > > API > > > > > > > > > call > > > > > > > > > > > forms one atomic (and durable) change. Yet, I do not > > think we > > > > > > have > > > > > > > > > > > completely ironed out all wrinkles [2] there. The > tricky > > > > aspect > > > > > > is > > > > > > > that > > > > > > > > > > > Persistence may be backed by a non-transactional > > database. > > > > > > > Currently we > > > > > > > > > > > have JDBC and MongoDB, which could be said to be > > > > transactional, > > > > > > > still > > > > > > > > > the > > > > > > > > > > > NoSQL Persistence in Polaris is built without assuming > Tx > > > > > > > capabilities, > > > > > > > > > > so > > > > > > > > > > > it will also work on non-transactional databases. > > > > > > > > > > > > > > > > > > > > > > This is just for context :) > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > https://lists.apache.org/thread/fh6t3mgzdb5ft0dt5q7qxm1pj1x5po75 > > > > > > > > > > > > > > > > > > > > > > [2] > > > > > > > > https://lists.apache.org/thread/rf5orxs815zs4h64p4rwp03q3pbgxb5r > > > > > > > > > > > > > > > > > > > > > > [3] > > > > > > > > https://lists.apache.org/thread/ksf5b5y3jt8dmft5kgblbwms8dhs4fn9 > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 18, 2026 at 3:03 PM Romain Manni-Bucau < > > > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Dmitri, > > > > > > > > > > > > > > > > > > > > > > > > Assuming you put metadata and metrics/events (maybe > > > > metrics but > > > > > > > these > > > > > > > > > > ones > > > > > > > > > > > > where not under my radar) in different databases to > > > > leverage > > > > > > > > > different > > > > > > > > > > > > tuning and aggregation level but still have exactly > > once > > > > > > > guarantee. > > > > > > > > > > > > I assume at some point there are or will be some > > writes in > > > > the > > > > > > > same > > > > > > > > > > request > > > > > > > > > > > > (stat updates, meta refresh/audit etc). > > > > > > > > > > > > > > > > > > > > > > > > While a single request/background task is guaranteed > > to be > > > > > > single > > > > > > > > > > > > datasource backed there is no real topic if it is > what > > you > > > > have > > > > > > > in > > > > > > > > > > mind. > > > > > > > > > > > > > > > > > > > > > > > > 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. 18 juin 2026 à 19:58, Dmitri Bourlatchkov < > > > > > > > [email protected]> > > > > > > > > > a > > > > > > > > > > > > écrit : > > > > > > > > > > > > > > > > > > > > > > > > > Hi Romain, > > > > > > > > > > > > > > > > > > > > > > > > > > In what cases / API calls do you envision XA to be > > used > > > > in > > > > > > > Polaris? > > > > > > > > > > > > > > > > > > > > > > > > > > I'm asking just for my education, as I do not see > > how / > > > > where > > > > > > > it > > > > > > > > > > could be > > > > > > > > > > > > > relevant ATM. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 18, 2026 at 1:11 PM Romain Manni-Bucau > < > > > > > > > > > > > > [email protected]> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Ok, good it was already thought. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Think worse case an user can set the 3 same or > > enable > > > > XA > > > > > > > using > > > > > > > > > > agroal > > > > > > > > > > > > > > capabilities ([1]) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://quarkus.io/guides/datasource#quarkus-agroal_quarkus-datasource-jdbc-transactions > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. 18 juin 2026 à 18:17, Alexandre Dutra < > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > a > > > > > > > > > > > > > écrit > > > > > > > > > > > > > > : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Romain, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > You raise good points. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Datasource multitenancy in Quarkus would have > > helped > > > > a > > > > > > lot > > > > > > > > > during > > > > > > > > > > > > this > > > > > > > > > > > > > > > old discussion: [1] where we eventually decided > > to go > > > > > > with > > > > > > > one > > > > > > > > > > > > > > > datasource for N realms, out of better choices > by > > > > then. > > > > > > But > > > > > > > > > that > > > > > > > > > > ship > > > > > > > > > > > > > > > has sailed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > And good question about XA: the proposal in > > [3960] > > > > does > > > > > > > not > > > > > > > > > > include > > > > > > > > > > > > > > > any transactional coordination between > > datasources, > > > > > > > afaict, and > > > > > > > > > > the > > > > > > > > > > > > > > > outbox pattern doesn't fit anymore in the > design > > we > > > > > > picked > > > > > > > for > > > > > > > > > > events > > > > > > > > > > > > > > > (and probably for metrics). This pattern was > > > > considered > > > > > > > > > initially > > > > > > > > > > > > > > > iirc, as it would have allowed exactly-once > > > > semantics for > > > > > > > > > > events; but > > > > > > > > > > > > > > > in the end, we went with separate tables > updated > > > > > > > independently > > > > > > > > > > (~= > > > > > > > > > > > > > > > at-most-once semantics). > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread/kvt3gd29hyxlhnwxr9b674s555jlvjjs > > > > > > > > > > > > > > > [3960]: > > https://github.com/apache/polaris/pull/3960 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 18, 2026 at 8:38 AM Romain > > Manni-Bucau > > > > > > > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Alexandre, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Can be worth shiming in the quarkus thread > > about > > > > it: > > > > > > > > > > > > > > > > > > https://github.com/quarkusio/quarkus/issues/11861 > > > > > > before > > > > > > > > > > merging a > > > > > > > > > > > > > new > > > > > > > > > > > > > > > way > > > > > > > > > > > > > > > > to do it (even if it delays from a few weeks > > the > > > > > > > feature) I > > > > > > > > > > think. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Technically one thing the 1 database -> N > > databases > > > > > > (not > > > > > > > > > > speaking > > > > > > > > > > > > > about > > > > > > > > > > > > > > > > tenants where there is no challenge but > > > > > > > meta+metrics+events) > > > > > > > > > > brings > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > transactional challenge, do you go XA with > this > > > > shift > > > > > > or > > > > > > > do > > > > > > > > > you > > > > > > > > > > > > plan > > > > > > > > > > > > > > some > > > > > > > > > > > > > > > > recovery (kind of outbox pattern with some > > > > challenges)? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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. 17 juin 2026 à 21:37, Alexandre > Dutra < > > > > > > > > > > [email protected]> > > > > > > > > > > > > a > > > > > > > > > > > > > > > écrit : > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'd like to elaborate on the "pluggable > > > > persistence" > > > > > > > > > concept > > > > > > > > > > > > > defined > > > > > > > > > > > > > > > > > my previous message, and how it might > evolve > > in > > > > the > > > > > > > future: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The proposal from PR [3960] originally > > suggested > > > > > > three > > > > > > > > > > distinct > > > > > > > > > > > > > > "store > > > > > > > > > > > > > > > > > types": metastore, metrics, and events. > > Although > > > > that > > > > > > > PR > > > > > > > > > was > > > > > > > > > > > > closed > > > > > > > > > > > > > > > > > because of inactivity, the concept remains > > > > relevant. > > > > > > > If we > > > > > > > > > > decide > > > > > > > > > > > > > to > > > > > > > > > > > > > > > > > support multiple datasources for each store > > > > type, I > > > > > > > > > envision > > > > > > > > > > the > > > > > > > > > > > > > > > > > following approach: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Polaris would provide datasource > definitions > > for > > > > > > every > > > > > > > > > > > > combination > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > store type and JDBC driver (such as > > > > > > > "postgresql-metastore" > > > > > > > > > or > > > > > > > > > > > > > > > > > "h2-metrics"). The current "enabler > property" > > > > would > > > > > > be > > > > > > > > > > replaced > > > > > > > > > > > > by > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > map of properties keyed by the store type. > > For > > > > > > > instance: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.metastore.datasource=postgresql-metastore > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.metrics.datasource=postgresql-metrics > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > polaris.persistence.relational.jdbc.events.datasource=postgresql-events > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this configuration, three separate > > PostgreSQL > > > > > > > > > datasources > > > > > > > > > > > > would > > > > > > > > > > > > > be > > > > > > > > > > > > > > > > > enabled, each managing its own connection > > pool > > > > and > > > > > > > > > settings. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alternatively, if a user wants to use a > > single > > > > > > > datasource > > > > > > > > > > for all > > > > > > > > > > > > > > > > > data, they could simply map every store > type > > to > > > > the > > > > > > > same > > > > > > > > > name > > > > > > > > > > > > > (e.g., > > > > > > > > > > > > > > > > > "postgresql-metastore"). This would result > in > > > > only > > > > > > one > > > > > > > > > active > > > > > > > > > > > > > > > > > datasource and a single connection pool for > > the > > > > > > > metastore, > > > > > > > > > > > > metrics, > > > > > > > > > > > > > > > > > and events. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It is still open for debate whether the > > default > > > > setup > > > > > > > > > should > > > > > > > > > > > > > > > > > prioritize a single shared datasource or > > separate > > > > > > ones > > > > > > > for > > > > > > > > > > each > > > > > > > > > > > > > store > > > > > > > > > > > > > > > > > type. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While this is primarily speculative at this > > > > point, > > > > > > > since > > > > > > > > > the > > > > > > > > > > > > > feature > > > > > > > > > > > > > > > > > hasn't been finalized, it demonstrates that > > we > > > > have a > > > > > > > > > viable > > > > > > > > > > path > > > > > > > > > > > > > > > > > forward should we choose to implement this > > > > > > > architecture. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [3960]: > > > > https://github.com/apache/polaris/pull/3960 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 17, 2026 at 9:26 PM Alexandre > > Dutra < > > > > > > > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have recently submitted a PR [4812] > that > > > > > > introduces > > > > > > > > > > support > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > multiple datasources with possibility of > > > > runtime > > > > > > > > > > activation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to open a discussion > > regarding the > > > > > > > intent > > > > > > > > > > behind > > > > > > > > > > > > > this > > > > > > > > > > > > > > > > > > proposal and the advantages it offers. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While Quarkus is a powerful platform, it > > > > presents > > > > > > > certain > > > > > > > > > > > > > > challenges, > > > > > > > > > > > > > > > > > > particularly with JDBC datasources. > > Currently, > > > > the > > > > > > > > > > datasource > > > > > > > > > > > > > type > > > > > > > > > > > > > > > > > > must be defined at build time using the > > > > "db-kind" > > > > > > > > > property. > > > > > > > > > > > > This > > > > > > > > > > > > > > > makes > > > > > > > > > > > > > > > > > > managing multiple datasources difficult, > > > > especially > > > > > > > for > > > > > > > > > > > > Polaris, > > > > > > > > > > > > > > > where > > > > > > > > > > > > > > > > > > users should ideally be able to select > the > > > > > > > appropriate > > > > > > > > > > > > datasource > > > > > > > > > > > > > > > (and > > > > > > > > > > > > > > > > > > driver) based on their specific > > requirements. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The core of this proposal relies on a key > > fact: > > > > > > while > > > > > > > > > > "db-kind" > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > fixed at build time, the "active" > property > > can > > > > be > > > > > > > toggled > > > > > > > > > > at > > > > > > > > > > > > > > runtime. > > > > > > > > > > > > > > > > > > Combined with named datasources, this > > property > > > > > > > becomes > > > > > > > > > the > > > > > > > > > > > > > missing > > > > > > > > > > > > > > > > > > lever to achieve runtime datasource > > activation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Under this change, Polaris must include > > > > predefined > > > > > > > named > > > > > > > > > > > > > > datasources > > > > > > > > > > > > > > > > > > for every supported driver. Users simply > > choose > > > > > > which > > > > > > > > > ones > > > > > > > > > > to > > > > > > > > > > > > > > > activate > > > > > > > > > > > > > > > > > > at runtime using an enabler property: > > > > > > > > > > > > > > > > > > > > > > "polaris.persistence.relational.jdbc.datasource", > > > > > > > which > > > > > > > > > > > > > identifies > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > > > > named datasource for activation. (Worth > > > > noting: an > > > > > > > > > inactive > > > > > > > > > > > > > > > datasource > > > > > > > > > > > > > > > > > > does not consume any resources at > runtime.) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > As a result, the server will now include > > the H2 > > > > > > > driver by > > > > > > > > > > > > > default, > > > > > > > > > > > > > > as > > > > > > > > > > > > > > > > > > it is a prerequisite for selecting an H2 > > > > datasource > > > > > > > at > > > > > > > > > > runtime. > > > > > > > > > > > > > We > > > > > > > > > > > > > > > > > > will need to follow a similar approach > for > > any > > > > > > other > > > > > > > JDBC > > > > > > > > > > > > drivers > > > > > > > > > > > > > > we > > > > > > > > > > > > > > > > > > intend to support in the future. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This architectural shift is necessary for > > > > several > > > > > > > > > reasons: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. Flexible defaults: It allows us to use > > JDBC > > > > + H2 > > > > > > > as > > > > > > > > > the > > > > > > > > > > > > > default > > > > > > > > > > > > > > > for > > > > > > > > > > > > > > > > > > server images (see these related > > discussions > > > > for > > > > > > > details: > > > > > > > > > > [1] > > > > > > > > > > > > > [2]) > > > > > > > > > > > > > > > > > > while enabling users to switch to > > PostgreSQL or > > > > > > other > > > > > > > > > > drivers > > > > > > > > > > > > > *via > > > > > > > > > > > > > > > > > > configuration alone*, thus eliminating > the > > > > need to > > > > > > > > > rebuild > > > > > > > > > > > > > Polaris > > > > > > > > > > > > > > > > > > entirely. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2. Pluggable persistence: It enables the > > > > > > persistence > > > > > > > > > layer > > > > > > > > > > to > > > > > > > > > > > > > > connect > > > > > > > > > > > > > > > > > > to multiple datasources simultaneously. > For > > > > > > > instance, one > > > > > > > > > > could > > > > > > > > > > > > > > use a > > > > > > > > > > > > > > > > > > specific datasource for main persistence > > and > > > > > > another > > > > > > > for > > > > > > > > > > > > metrics > > > > > > > > > > > > > – > > > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > > concept previously discussed in [3960] > that > > > > lacked > > > > > > an > > > > > > > > > easy > > > > > > > > > > > > > > > > > > implementation path in my opinion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I look forward to hearing your thoughts > on > > this > > > > > > > proposal. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [4812]: > > > > > > https://github.com/apache/polaris/pull/4812 > > > > > > > > > > > > > > > > > > [3960]: > > > > > > https://github.com/apache/polaris/pull/3960 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1]: > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread/yw8l026g2smdk7gdg7k61tdcvdwcncqw > > > > > > > > > > > > > > > > > > [2]: > > > > > > > > > > > > > > > > > > > > > > > > > > https://lists.apache.org/thread/nzoljc1ohnsq4f5o28dh4opqkqw3p09h > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
