I think Romain has a good point. We may reconsider whether an abstraction(e.g. Hibernate) is needed if we are doing non trivial rewriting at the JDBC layer for different dialects. I'm open to using Hibernate or an equivalent solution if it can genuinely avoid database specific SQL rewrites and reduce long term maintenance costs. One of the previous blockers for us was the Hibernate license, which historically was not compatible with the Apache License. That constraint was a key reason we ruled it out earlier. If the licensing situation has changed, or if a viable Apache compatible alternative offers comparable dialect abstraction without introducing heavy runtime coupling, I think it is worth revisiting this direction.
One open question is whether frameworks like Hibernate actually provide enough concrete benefit for Polaris’s persistence model, given that our access patterns are relatively simple and often still require explicit SQL. In addition, we should consider whether it is desirable to maintain many backend implementations in the main repository at all. Keeping the main repo focused on a small set of well supported options may keep the project simpler and ultimately benefit the community more. Yufei On Sat, Feb 7, 2026 at 1:43 PM Romain Manni-Bucau <[email protected]> wrote: > Le sam. 7 févr. 2026 à 22:27, Jean-Baptiste Onofré <[email protected]> a > écrit : > > > Hi > > > > JPA was used initially (with EclipseLink) but it was not super convenient > > and had limitations in some of our use cases. That’s why we switched to > > JDBC with PostgreSQL as first candidate. > > Just for context. > > > > Hmm, proposal was to use hibernate more than jpa since you do use quarkus, > from my window: > > 1. it does abstract databases (its main pro even if it should be something > else, ack) > 2. it enables to issue plain JDBC if needed (but not really IMHO) > 3. it has stateless session so perf should be a no brainer if properly used > compared to current usage > > Ultimately the dialect part can be reused (or even redone as we did in > batchee years ago), but sticking to postgres is very limiting community > wide IMHO, was my main feedback. > > Hope it makes more sense this way. > > > > > > Regards > > JB > > > > Le sam. 7 févr. 2026 à 09:34, Romain Manni-Bucau <[email protected]> > a > > écrit : > > > > > Hmm, my point is that an extension point is ok for 3rd parties or > vendor$ > > > but not end users in general so there it means postgres will be part of > > the > > > stack so an end user requirement. > > > > > > If the issue is just about wiring the code or reusing the > > > dialect/dictionary please let me know. > > > > > > Using jdbc rewrite driver is a pain to maintain and main current option > > to > > > not have to patch the whole product due to quarkus bundling which > doesn't > > > ensable much extensibility compared to a real CDI container - specific > > > discovery and deployment bundles. > > > > > > This is why i think jpa stateless mode would be worth it and solves > perf > > > and abstraction issues. > > > > > > > > > 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 sam. 7 févr. 2026, 08:42, Jean-Baptiste Onofré <[email protected]> a > > > écrit : > > > > > > > Hi Romain > > > > > > > > I agree, and it's what we do with both JDBC and the NoSQL efforts. > > > > > > > > I think there are two aspects: > > > > - supporting some store backend/RDBMS by default, using > > > quarkus/quarkiverse > > > > extension. Here, we go with PostgreSQL by default. It's a bit > > opinionated > > > > on this part. > > > > - allow the users to support their own backend (like MSSQL), and yes, > > > > that's clearly the intent. But there's also some "adaptations" to do > > > > depending of the capabilities (remember the adapter we had to do in > > > > ActiveMQ to efficiently support the different RDBMs). > > > > > > > > So, my suggestion is to remove H2 "standard" support, but users can > > > > still use it if they want (and contributing the "adapters"). > > > > > > > > Regards > > > > JB > > > > > > > > On Fri, Feb 6, 2026 at 10:08 PM Romain Manni-Bucau < > > > [email protected]> > > > > wrote: > > > > > > > > > Hi all > > > > > > > > > > are stateless sessions of hibernate that slow compared to JDBC - it > > > > > shouldn't if well configured/used, in particular with the pattern > > used > > > > > right now which still does object projection? > > > > > idea behind is that enabling more database sounds the way to go to > > get > > > > more > > > > > audience - I'd love to use MSSQL cause it is what we have there and > > > know > > > > > how to run instead of adding postgres just for polaris for ex. > > > > > if stateless mode is ok then H2 & friends are no brainer to keep. > > > > > > > > > > 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. 6 févr. 2026 à 21:47, Russell Spitzer < > > > [email protected] > > > > > > > > > > a > > > > > écrit : > > > > > > > > > > > +1 Remove H2, Postgres setup in docker is only slightly more > > annoying > > > > > > > > > > > > On Fri, Feb 6, 2026 at 1:23 PM Jean-Baptiste Onofré < > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > I guess the purpose is mostly for test/local "demo" purposes > > > without > > > > > the > > > > > > > need of RDBMS service. > > > > > > > That said, with Docker, it's not very painful to have > PostgreSQL > > > > > > including > > > > > > > for local test/demo use cases. > > > > > > > > > > > > > > I agree to remove H2. > > > > > > > > > > > > > > Regards > > > > > > > JB > > > > > > > > > > > > > > On Fri, Feb 6, 2026 at 7:08 PM Dmitri Bourlatchkov < > > > [email protected] > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > I'm just wondering whether people find value in maintaining > H2 > > > > > schemas. > > > > > > > > > > > > > > > > I doubt H2 has production use cases. Polaris builds include > it > > > only > > > > > in > > > > > > > test > > > > > > > > configurations, it seems. > > > > > > > > > > > > > > > > Would it be reasonable to drop H2 to concentrate on > PostgreSQL? > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Dmitri. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
