You run a data platform, and your team keeps its Iceberg tables behind a catalog that is not Apache Polaris. Someone suggests querying those tables straight from Postgres using pg_lake, Snowflake's open source extension that lets Postgres read and write Apache Iceberg tables in object storage. You start reading, and you find the snag before you finish the first page.
The snag is a small assumption with large consequences. Snowflake's engineering post, "pg_lake 3.5: Universal Iceberg REST Catalog Support for Postgres," says pg_lake shipped with a REST catalog client whose URLs "assume the Apache Polaris layout." The Iceberg REST Catalog specification defines paths such as /v1/{prefix}/namespaces, "but it does not prescribe where these paths are mounted on a server." Each catalog picked its own base path, and pg_lake hardcoded the one belonging to Polaris. If your catalog mounts the same paths somewhere else, the client simply guesses wrong.
Here is what changed. pg_lake 3.5, released in September, accepts a full base URI. That means you can point Postgres at Lakekeeper or Nessie as well as Polaris, and query Iceberg tables using storage credentials vended by the catalog. The fix is plain: take the base URI as configuration and append only the paths the specification defines.
You should read the limits carefully, because the post is precise about them. Writable tables are "supported on Apache Polaris only." Other catalogs are read-only for now, and that gap is tracked in a public issue. The post offers no adoption figures. The next release is said to bring automatic prefix discovery, clearer errors for misconfigured catalogs, unauthenticated catalogs for development, and Unity Catalog. So if you need to write from Postgres into a non-Polaris catalog, you wait. If you need to read, you can start.
The line you will probably repeat to your security team is this one: "When pg_lake requests access to an Iceberg table, the catalog decides whether Postgres can see it and which storage credentials it gets, the same way it does for every other engine." You do not have to build a second set of access rules inside Postgres. Security lives in the catalog, once, and every engine, now including yours, asks it.
Then the post turns to Snowflake's own record, and this is the part that makes it more than a release note. The APIs.io catalog lists 49 API pages for Snowflake, including the Snowflake Iceberg Table API and the Snowflake Catalog Integration API, which connects Snowflake to external Iceberg catalogs of exactly the kind pg_lake now talks to. The agentic access profile maps 408 operations, 276 of them acting and 14 human-in-the-loop. On Agent Readiness, the MCP server, agent skills, idempotency, reversibility, error semantics and delegated identity are lit.
The scores are mixed, and the post says so. The Kin Score is 81.2, in the exemplar band, carried by access clarity at 92.1 and developer ergonomics at 80.4, with contract governance at 45.5. The Agent Readiness score is 45.6. Several dimensions are not lit, a well-known catalog among them.
That is where the post draws its comparison. A specification that defines paths but not where they mount leaves every client to guess, and the first client guesses the vendor it knows. Snowflake fixed that for Postgres. The unlit dimensions on its own record, the post says, are the same kind of mount point for agents: a place where a client has to guess, because nothing says where to look.
What you take away is practical. Check which catalog you run, and whether you need reads or writes. For reads, Lakekeeper, Nessie and Polaris work today, and Unity Catalog is promised next. For writes, Polaris is the only answer so far. And when you evaluate any vendor, including one that just fixed a hardcoded path, look at its own record too.
Read the original: https://apis.io/2026/10/22/snowflake-unties-pg-lake-from-one-iceberg-catalog/