Apache Polaris dev list digest (Sept 8–12, 2025)

#data #database #datascience #dataengineering

Passwordless database authentication

Fabio Rizzo from JPMorgan asked whether Polaris can connect to PostgreSQL without a username and password, using AWS IAM authentication instead of static credentials. The current Helm charts and configuration require a JDBC URL plus username and password. Dmitri Bourlatchkov explained that Polaris uses Quarkus for JDBC datasource management, so anything supported by the PostgreSQL JDBC driver should work in Polaris; however, Helm charts may need to expose the necessary configuration. Jean‑Baptiste Onofré agreed that password‑less support would be a welcome improvement. Yufei Gu suggested looking at AWS’s advanced JDBC wrapper for examples, but noted that Quarkus was not mentioned in its documentation. She proposed trying alternative connection pools like HikariCP or DBCP. Fabio tested the wrapper and concluded that Quarkus still doesn’t support IAM authentication out of the box, so some changes in Polaris would be required. Yufei invited Fabio to propose the changes as a contribution.

Thread: Aurora postgres passwordless DB

Public OpenAPI changes

Adnan Hemani continued refining the Polaris OpenAPI specification. In a message on Sept 8 he proposed cleaning up path parameters and ensuring that event‑generation semantics are consistent across all API endpoints. He pointed out cases where “id” and “name” parameters were mixed and suggested a more consistent naming scheme. He also recommended that all operations that modify resources emit events so that integrations (such as triggers and metrics systems) can react uniformly. The proposal was open for feedback, with plans to incorporate any changes into the 1.2.0 milestone.

Thread: Proposed Public OpenAPI Changes

RC0 vote results

On Sept 10 Jean‑Baptiste Onofré announced the results of the vote to release Apache Polaris 1.1.0‑incubating RC0. The release passed with one binding +1 vote from Dmitri Bourlatchkov and one +1 (non‑binding) from JB himself; no ‑1 votes were cast. The community agreed that a DNS‑related test failure on macOS should not block the release. Work continued on follow‑up issues (e.g., #2501) and a decision to cut a possible RC1 if necessary.

Thread: [RESULT][VOTE] Release Apache Polaris 1.1.0‑incubating (rc0)](https://lists.apache.org/thread/g3mqhovvx3670spdpw25hc84d7jb1fjd)

Operational metrics proposal

Pierre Laporte’s proposal to add Data‑Lake operational metrics to Polaris continued to gather feedback. Contributors discussed which metrics could be derived from Iceberg’s existing ScanMetrics and CommitMetrics and which would require the planned Events API. Pierre suggested focusing initially on simple counts (total files, number of reads/writes) and timestamps (first/last read/write), while Prashant Singh argued that exposing richer ScanMetrics would enable better compaction and layout decisions. The group agreed to scope an initial set of metrics for the 1.2.0 milestone.

Thread: [PROPOSAL] Add Data Lake operational metrics to Polaris](https://lists.apache.org/thread/hfks22z60kdt0jlz5s4yk67dd038fr4n)

Other updates

JDBC metastore index: Artur Rakhmatulin’s proposal to add an idx_entities_lookup index to the JDBC metastore, intended to speed up entity listings, received support and was awaiting benchmarking results before merging.
Idempotency key for REST mutations: Huaxin Gao suggested adding an optional Idempotency‑Key header to Polaris REST mutations so that clients could safely retry requests. The community was broadly positive, viewing it as a step toward more robust APIs.
1.1.0 release process: The ongoing RC0 vote thread included final +1 votes and a plan to prepare a possible RC1 if the remaining issues were fixed quickly. Contributors continued updating changelog entries and triaging issues for the 1.2.0 milestone.

Takeaway

The Polaris dev list focused on operational polish rather than major new features during Sept 8–12 2025. Discussions ranged from modernizing authentication (IAM‑based, passwordless connections) and refining the OpenAPI contract to finishing the 1.1.0 release and planning for 1.2.0. Contributors encouraged users to propose changes and welcomed additional hands to implement improvements like password‑less database connections and richer metrics.