Hi Yufei, That's right, the admin tool allows users to request a particular schema version for bootstrap.
However, my question (from an earlier email) was: Do we have use cases for deploying old schema versions from the latest Polaris release? In other words, do you know when users actually utilize that option?.. or whether they utilize it at all? My point is that if users need to bootstrap an old schema version, they can and should use the old admin tool release that corresponds to that schema version. Cheers, Dmitri. On Tue, Jun 16, 2026 at 5:39 PM Yufei Gu <[email protected]> wrote: > Hi Dmitri, > > The bootstrap tool allows users to specify the schema version. It's > debatable whether we should allow that or not in the future, but that's a > separate discussion. > > -v, --schema-version=<schema version> # The version of the schema to > load in [1, 2, 3, LATEST]. > > > https://polaris.apache.org/releases/1.5.0/admin-tool/#bootstrapping-realms-and-principal-credentials > > Yufei > > > On Fri, Jun 12, 2026 at 11:53 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > I'm not sure I understand what you mean, sorry. > > > > For example, a user installed Polaris 1.3.0-incubating (latest schema > v3), > > then upgraded to 1.4.0 (latest schema v4). Why would the user run schema > > DDL for v3 using the 1.4.0 release binaries? > > > > Thanks, > > Dmitri. > > > > On Fri, Jun 12, 2026 at 2:34 PM Yufei Gu <[email protected]> wrote: > > > > > > Do we have use cases for deploying old schema versions from the > latest > > > Polaris release? > > > > > > Yes, this happens every time a user upgrades their Polaris version. > > > Backward compatibility is critical in that case. > > > > > > Yufei > > > > > > > > > On Fri, Jun 12, 2026 at 10:33 AM Dmitri Bourlatchkov <[email protected] > > > > > wrote: > > > > > > > Hi Alex, > > > > > > > > Maintaining only the latest schema for H2 makes sense to me. > > > > > > > > I wonder why we should not do the same for PostgreSQL too. > > > > > > > > End users can always deploy older schemas using corresponding (old) > > > Polaris > > > > releases if they need to. > > > > > > > > Do we have use cases for deploying old schema versions from the > latest > > > > Polaris release? > > > > > > > > That is not to say we should not support old schema versions in java > > > code - > > > > that is still relevant in upgrade cases. I wonder only about > > boostrapping > > > > with older DDL. > > > > > > > > Cheers, > > > > Dmitri. > > > > > > > > On Fri, Jun 12, 2026 at 1:02 PM Alexandre Dutra <[email protected]> > > > wrote: > > > > > > > > > Sorry I forgot to mention this: I am not sure why we maintain > > > > > versioned schemas for H2? The rare use cases where H2 makes sense > in > > > > > production (embedded db, ephemeral data, etc.) do not apply to > > > > > Polaris. How about we consider H2 as a testing-only backend, and > > > > > reduce the supported schemas to just the latest version? > > > > > > > > > > Thanks, > > > > > Alex > > > > > > > > > > On Fri, Jun 12, 2026 at 6:38 PM Alexandre Dutra <[email protected] > > > > > > wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Thanks Dmitri, I was about to chime in here :-) > > > > > > > > > > > > Yes, I would actually support the opposite: make JDBC+H2 the > > default > > > > > > for getting-started guides (thus shipping H2 by default). > > > > > > > > > > > > As I explained in the other thread, JDBC+H2 is a superior setup, > > much > > > > > > closer to a real production one, compared to the test-grade > > > > > > TreeMapMetaStore-based persistence that we use as the default > > today. > > > > > > > > > > > > Granted, we'd have to maintain schemas for H2. But on the bright > > > side, > > > > > > we don't need to care about schema migration, so I am not too > > worried > > > > > > about the overhead. > > > > > > > > > > > > Thanks, > > > > > > Alex > > > > > > > > > > > > On Fri, Jun 12, 2026 at 6:03 PM Dmitri Bourlatchkov < > > > [email protected]> > > > > > wrote: > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > To refresh this thread, I think Alex has a nice proposal [1] to > > > > > actually > > > > > > > use H2 instead of in-memory persistence by default in > > > getting-started > > > > > > > scenarios. > > > > > > > > > > > > > > [1] > > > https://lists.apache.org/thread/nzoljc1ohnsq4f5o28dh4opqkqw3p09h > > > > > > > > > > > > > > Cheers, > > > > > > > Dmitri. > > > > > > > > > > > > > > On Fri, Feb 6, 2026 at 2: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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
