Apache Polaris dev list digest (Sept 1–5 2025)

Voting on the 1.1.0‑incubating release candidate

The community focused on testing and voting for Polaris 1.1.0‑incubating RC0. Jean‑Baptiste Onofré shared the candidate tarball, commit ID, Helm chart, KEYS file and Maven repository URLs and asked everyone to verify signatures, run tests and vote within 72 hours. Contributors ran through build scripts and integration tests: Alexandre Dutra and Pierre Laporte cast +1 votes after verifying checksums, signatures and performing read/write benchmarks. Russell Spitzer initially encountered a DNS‑related failure in RestCatalogKeycloakFileIT on macOS; Jean‑Baptiste reproduced the issue and suggested it was a local environment problem rather than a release blocker, proposing a follow‑up fix if necessary. Yufei Gu and Dmitri Bourlatchkov completed their own tests (including smoke tests against Iceberg) and gave +1 votes. With several binding and non‑binding approvals and no critical blockers, the vote proceeded successfully. (Thread: g3mqhovvx3670spdpw25hc84d7jb1fjd)

Adding a JDBC metastore index

Artur Rakhmatulin proposed adding an idx_entities_lookup index to the Polaris JDBC metastore. He explained that the existing schema only indexed primary keys and foreign keys, which resulted in expensive scans when listing entities. His benchmark on PostgreSQL showed that adding a multi‑column index on (realm, namespace, name, type) dramatically improved performance. He supplied SQL for both Postgres and H2 and requested feedback on whether to include the index by default or document it as an optional performance optimisation. (Thread: tbxkjvmvq3d62sxrr8m0q88o79bv5p)

Proposal for operational metrics

Pierre Laporte opened a discussion on adding Data‑Lake operational metrics to Polaris. He suggested creating a component that aggregates high‑level metrics (e.g., total files, read/write counts, last modified time) for Iceberg tables and views. Pierre noted that only a few metrics (number of files, timestamps of first/last read/write) could be derived from existing Iceberg metrics; the rest would require events from the upcoming Events API. Prashant Singh supported the idea, pointing out that metrics like ScanMetrics are useful for optimizing table layout and compaction and that other catalogs (such as Gravitino) expose them. The group agreed that capturing and persisting metrics in Polaris would help operators understand how data is used. (Thread: 3r6kx6kxkv71nsm1h3p0c6n1)

Proposed changes to OpenAPI responses

Adnan Hemani proposed updating the Polaris OpenAPI specification so that create* endpoints return the newly created resource instead of an empty body. He argued that returning the resource (as RFC 9110 recommends) improves client usability and facilitates event generation. The proposal covers APIs such as createCatalog, createPrincipalRole, createCatalogRole, createNamespace, and integration/permission endpoints. Adnan invited feedback and said he would start a vote if there was community consensus. (Thread: k8kp3bb4p6xz4hffbjrvkcw3tojy)

UI and onboarding improvements

Jean‑Baptiste Onofré resumed work on the Polaris UI and onboarding experience. He shared that initial components were working against the backend and that he planned to open a draft pull request in the polaris‑tools repository to gather feedback. Yufei Gu thanked him for the update. (Thread: k8kp3bb4p6xz4hffbjrvkcw3tojy#ui)

Table Source and Common Table API meeting

Jean‑Baptiste and Laurent revisited their Polaris Table Source and Common Table API proposal. The design allows Polaris to register external data sources—structured files (Parquet, JSON, CSV), unstructured blobs (video, images) and existing tables—and wrap them in Iceberg tables while enforcing governance. On Sept 4 JB thanked contributors for their questions and proposed a dedicated meeting on Sept 11 to discuss the relationship with the Generic Table API. Yufei Gu noted that multiple Polaris talks were scheduled for Sept 11 at the Council of Committees conference and asked to move the meeting to the following week. JB agreed to reschedule after the conference. (Thread: 95fb75y25j9rntzcgkibjdvibt)

Preparing the September Incubator report

Finally, Jean‑Baptiste reminded everyone that Polaris’s quarterly incubator report was due on Sept 25. He shared a link to the report template on the ASF Confluence and asked contributors to provide updates on releases, community growth, and ongoing development so the report could be assembled on time. (Thread: k8kp3bb4p6xz4hffbjrvkcw3tojy#incubator)

Takeaway

During the first week of September 2025, the Polaris dev community concentrated on finalizing the 1.1.0 release candidate, improving performance via new JDBC indexes, and designing features such as operational metrics and richer OpenAPI responses. Work on the UI and on onboarding continued, and the team scheduled follow‑up meetings to refine the Table Source proposal while coordinating around the ASF Council of Committees conference. The week also marked the start of preparations for the September incubator report.