Apache Polaris Dev List Digest August 25-29

#database

Apache Polaris Dev List

Release planning and project updates (Aug 25–29 2025)

Preparing the 1.1.0‑incubating release – Jean‑Baptiste Onofré announced that 18 issues remained in the 1.1.0 milestone and proposed bumping enhancement and proposal items to the 1.2.0 release in order to keep monthly releases on schedule. Community members agreed to move open enhancements (such as support for OpenLineage and SPI proposals) to 1.2.0, while leaving bug fixes in 1.1.0. Dmitri Bourlatchkov reviewed the remaining issues (e.g., #2367, #1901, #552) and suggested deferring complex items to 1.2.0.
- Contributors coordinated on specific pull requests: they agreed to merge #2341 (credential refresh config) before the cut, moved #2197 (credential reset API) to 1.2.0, and flagged #2436 (feature‑gating custom S3 endpoints) as a blocker.
- By Aug 29, JB Onofré was ready to start the release process but identified PR #2473 as a last‑minute blocker; he asked for urgent review and committed to publishing the release blog once the blocker was addressed. The thread shows a clear cadence: issues are triaged into monthly milestones, with only critical fixes making it into 1.1.0.

Thread: Release preparation discussion

Polaris community sync meeting – On Aug 29, JB Onofré thanked participants of the August 28 community sync and shared a link to the meeting recording. He noted that the website would be updated with meeting notes and encouraged members to review the video.

Thread: Community sync recap

Proposal: Polaris Table Source and Common Table API – JB Onofré and Laurent proposed a new “Polaris Table Source” that would let users register external data (structured files like Parquet/CSV/JSON, unstructured files like images and videos, or entire existing tables) into Polaris while having Polaris act as the single governing catalog. The proposal distinguishes between structured sources (where Polaris wraps Iceberg tables around data), unstructured sources (where metadata is stored separately), and table imports (importing an existing Iceberg table). They shared a detailed design doc and invited feedback.

Thread: Polaris Table Source proposal

Design discussions and feature proposals

Limiting namespace locations – Eric Maynard raised a discussion about limiting namespace locations. He referenced PR #2422, which introduces restrictions on where namespaces can be created to prevent unintended directory sprawl. The proposal asks the community to evaluate the default behaviour and suggest whether administrators should be able to override it.
Events community sync follow‑up – Adnan Hemani posted a follow‑up summarising action items from the Polaris events API community meeting. He thanked those who could make it and opened the floor for further comments on event instrumentation and API design. (This continues the earlier Aug 19 events sync summary thread.)
Adding a user‑principal tag in metrics – Kostas Zoumptazian proposed adding a “user principal” tag to the metrics emitted by Polaris. The idea is to include the authenticated principal name in metrics to improve observability and auditing. He provided a link to PR #2341, which adds the tag as part of the metrics context.
S3 remote signing – Alexandre Dutra started a new thread on Aug 25 about remote signing for S3 requests. Polaris currently vends credentials; remote signing would allow clients to send unsigned S3 requests and have Polaris sign them using catalog‑owned keys. Alexandre linked to an initial implementation and highlighted that remote signing avoids credential hijacking while still requiring RBAC changes. Community members agreed that remote signing should be discussed as a major feature.
Optional client ID/client secret in createPrincipal – Dmitri Bourlatchkov followed up on a proposal to allow clients to reset or omit client IDs and secrets when using the createPrincipal API. He linked to PR #2197 and asked whether it should be included in 1.1.0. The consensus by Aug 28 was to defer it to 1.2.0 because it involves authentication changes.
Feature flag for credential refresh endpoints – Dmitri Bourlatchkov asked whether Polaris should gate the new /credentials refresh endpoint behind a feature flag. Prashant Singh replied that separate gating isn’t necessary because credentials are already vended on loadTable, and the refresh endpoint doesn’t present a security risk. This thread reflected the general preference for keeping the API simple without adding unnecessary feature flags.

Summary

During the last week of August 2025, the Polaris dev community focused on triaging issues for the 1.1.0‑incubating release, deferring enhancements to 1.2.0, and addressing blockers for the imminent release. They held a community sync meeting and shared a recording, floated a new Table Source proposal to ingest external data into Polaris, and discussed feature flags, remote signing, and authentication APIs. The cadence of monthly releases and the push to proactively populate the changelog continued to shape decisions.