Hi Yufei, Updating this based on the discussion in the Community Sync on Feb 19.
As discussed, [3395] complements the NoSQL Persistence implementation that is already in `main` and allows Polaris Users to try out the NoSQL persistence as a complete solution (even while it is flagged as "beta") in the upcoming 1.4.0 release (main MetaStore, plus database maintenance tasks required for controlling storage size). Polaris as a project has historically been open to admitting experimental features and allowing the to mature over a few subsequent releases. The community is open to discussing / evolving the Admin Tool in general after 1.4.0. I believe you mentioned that end users could utilize nightly tool builds for the NoSQL maintenance command. I'm not sure it is a viable solution, as ASF policies [1] emphasise: "Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages." All reviewers apparently support having [3395] in the Admin Tool at this time. You seem to be the only person with open concerns. The community values your opinion. Please give a recap (from your POV) of what might be a disadvantage to merging [3395] today or tomorrow. [1] https://www.apache.org/legal/release-policy.html#publication [3395] https://github.com/apache/polaris/pull/3395 Thanks, Dmitri. On Tue, Feb 17, 2026 at 2:47 PM Dmitri Bourlatchkov <[email protected]> wrote: > Hi Yufei, > > I'm open to continuing the discussion on PR 3395 if needed, but I don't > think it is a blocker for 1.4.0. > > > It is not a blocker from the release perspective, but [3395] makes the > NoSQL Persistence story "complete" from the end user's perspective. > > Given that everyone is in agreement with continuing discussions and > improvements in the Admin Tool, would you mind merging [3395] specifically > to provide a full solution to end users in 1.4.0 and adjusting on main with > additional proposals / considerations later? > > I'm just trying to understand if there may be any disadvantage to merging > it now. The possible "convenience" or "confusion" aspects can be discussed > in docs and in any case are outweighed (from my POV) by the fact that users > get a usable maintenance tool in the same release as the backend that needs > this tool. My impression from previous discussions about this PR is that > the majority of the community is fine with having it in the Admin Tool, at > least as the next step in the evolution of the project. > > [3395] https://github.com/apache/polaris/pull/3395 > > Thanks, > Dmitri. > > On Tue, Feb 17, 2026 at 2:17 PM Yufei Gu <[email protected]> wrote: > >> +1 on what Adnan and JB proposed. >> >> Hi Dmitri, >> >> We need a few followups for PR 3409, like CLI and doc changes, but I think >> it's fine to include it in 1.4.0 as it is guarded by the feature flag. >> >> I'm open to continuing the discussion on PR 3395 if needed, but I don't >> think it is a blocker for 1.4.0. >> >> Yufei >> >> >> On Tue, Feb 17, 2026 at 9:32 AM Dmitri Bourlatchkov <[email protected]> >> wrote: >> >> > Hi All, >> > >> > Any concerns with merging [3409] before 1.4.0? >> > >> > Note: the new functionality is covered by a feature flag, which is off >> by >> > default. >> > >> > [3409] https://github.com/apache/polaris/pull/3409 >> > >> > Thanks, >> > Dmitri. >> > >> > On Mon, Feb 16, 2026 at 9:37 PM Adnan Hemani via dev < >> > [email protected]> >> > wrote: >> > >> > > Hi all, >> > > >> > > I've gone through the GH issues and PRs tagged to the 1.4.0 label and >> > would >> > > like to make the following recommendations for a potential Apache >> Polaris >> > > 1.4.0 release branch cut on (tentatively) 2026-02-23. >> > > >> > > Please reply to this thread prior to that date if there is any >> feedback, >> > > comments, and/or concerns so that we can get community consensus >> before >> > we >> > > proceed with the release. If there are no replies to this email, the >> > 1.4.0 >> > > release branch will be cut on 2026-02-23. >> > > >> > > Open Issues (Recommendation in []): >> > > * [PUNT] #538 <https://github.com/apache/polaris/issues/538>: Table >> > > Maintenance Support in Polaris >> > > * No major work in progress to justify delaying the release. >> > > >> > > * [CLOSE] #550 <https://github.com/apache/polaris/issues/550>: >> Support >> > for >> > > GCP service account impersonation. >> > > * I will ping Michael to do this when he is back from vacation. >> > > >> > > * [CLOSE] #552 <https://github.com/apache/polaris/issues/552>: Safety >> > > against unparseable locations. >> > > * I believe all the work has been completed for this. Dmitri, can >> you >> > > please confirm? (Will follow up offline as well) >> > > >> > > * [DISCUSS] #650 <https://github.com/apache/polaris/issues/650> / >> #3395 >> > > <https://github.com/apache/polaris/pull/3395>: MongoDB Persistence >> > Backend >> > > * It seems that discussions are still active and ongoing, and >> there >> > is >> > > disagreement behind getting the change into Admin Tools while the core >> > > functionality is merged already. I can see the arguments from both >> sides >> > to >> > > push 1.4.0 without the Admin Tools change OR to hold the release until >> > > there is agreement on these last bit of changes. What are the >> community's >> > > thoughts? Default option (if no one chimes in): we will push the >> release >> > > as-is on the 23rd. >> > > >> > > * [PUNT] #2671 <https://github.com/apache/polaris/issues/2671>: DB >> > Schema >> > > Migration Between Releases >> > > * No major work in progress to justify delaying the release. >> > > >> > > * [PUNT] #3685 <https://github.com/apache/polaris/issues/3685>: >> > > `Create_Namespace` SQL Optimization >> > > * While there is traction, we may still be too far from a >> load-tested >> > > fix. This should be a high priority for 1.5.0. >> > > >> > > Open PRs: >> > > >> > > * [PUNT] #2180 <https://github.com/apache/polaris/pull/2180>: Async & >> > > reliable tasks API, SPI, Store interfaces >> > > * PR is not very active over the last few weeks and does not have >> > > enough active reviewers to see a strong path forward for merging in >> the >> > > next week or so. >> > > >> > > * [PUNT] #3256 <https://github.com/apache/polaris/pull/3256>: Object >> > > Storage Operations >> > > * From the ML, it seems that there are still two rival proposals >> that >> > > are attempting to solve similar issues. My recommendation is to >> unstick >> > > this discussion from the 1.4.0 release to give proper time for the >> > > discussion to resolve. >> > > >> > > When commenting, please reference the GH Issue/PR number so that we >> are >> > > clear on what is being discussed :) >> > > >> > > Best, >> > > Adnan Hemani >> > > >> > >> >
