pg_lake 3.5 makes Iceberg catalogs portable for reads—but not yet for writes

Snowflake’s open-source pg_lake extension has widened the catalog choices available to Postgres applications, but its new portability has a clear boundary: reading is broader than writing.

What changed

The company says pg_lake 3.5 removed a hard-coded Apache Polaris URL layout from its Iceberg REST client. Administrators can now provide the complete REST-catalog base path, allowing Postgres to query Iceberg tables registered in Apache Polaris, Lakekeeper or Nessie without adding a reverse proxy solely to rewrite catalog URLs. The extension can also use short-lived storage credentials issued by the catalog for read-only tables. Snowflake Engineering

That sounds like universal catalog interoperability, but the implementation is uneven. Writable catalog tables are currently supported only with Polaris; Lakekeeper and Nessie access is read-only. Snowflake says Unity Catalog support has merged for the next release, not 3.5, and automatic prefix discovery will also arrive in that future tag. Even then, catalogs that do not return a usable prefix without a warehouse parameter will still need an explicit catalog_name. Snowflake Engineering

The operational catch

Version 3.5 introduces a breaking configuration change. Existing Polaris deployments that supplied only a host must update rest_endpoint to include the full /api/catalog mount path. Lakekeeper uses /catalog, while Nessie uses /iceberg. A deployment that upgrades the extension without changing the endpoint can therefore lose catalog connectivity even though the release is intended to broaden compatibility. Snowflake Engineering

The next release is meant to reduce some of that friction. Snowflake describes automatic prefix discovery through the Iceberg REST /v1/config endpoint, clearer diagnostics that distinguish a missing catalog from a missing namespace, unauthenticated catalog access for development environments, and Unity Catalog handling for prefixes containing slashes. Those changes are on the roadmap or merged to the main branch, but they should not be treated as 3.5 capabilities until a new version is tagged. Snowflake Engineering

What practitioners should take away

For teams using Postgres as an application-facing query layer over a shared lakehouse, 3.5 makes read interoperability materially easier: the same Iceberg tables can be exposed without copying them back into Postgres. It does not yet make catalog choice irrelevant. The catalog still determines whether Postgres can write, how the namespace prefix must be configured and which upgrade steps are required.

The practical migration test is therefore two-part: verify read access through the chosen REST endpoint, then separately verify whether the workflow needs catalog commits. A successful SELECT against Lakekeeper or Nessie does not prove that the same architecture can accept writes.