Lakehouse architecture · Part one of two

Six Things Called Catalog, One Credential Underneath

Table truth in the lakehouse has converged on one protocol. Everything above it has not, and the reason is a credential. A layer model for the parts that still differ, where Databricks, Snowflake and IBM actually stand in August 2026, and the question nobody puts in the diagram.

David Leconte · 31 August 2026 · 17 min read

The interesting part of the lakehouse catalog question is settled, and the part that replaced it is barely being discussed.

Table truth — what makes a set of Parquet files a table with a schema, snapshots and commits — has converged. All three major estates now serve the Apache Iceberg REST catalog specification. Unity Catalog implements it and vends credentials to external engines.² Snowflake's Horizon exposes it natively, powered by Apache Polaris, which graduated to a Top-Level Project at the Apache Software Foundation in February 2026.³¹ IBM's Metadata Service implements selected APIs from both the Iceberg REST and Unity Catalog specifications.⁴⁰

So the read path is contractually convergent, and every remaining difference has moved somewhere else. Upward, into who may write and under what authority, whether a policy survives leaving its perimeter, whether a semantic definition is portable. And downward, into a mechanism that almost every architecture diagram draws as a single arrow and that turns out to decide the whole governance question: what exactly the catalog hands an engine when it says yes.

You cannot see any of it while "catalog" remains one word.

How to read this. The first half builds the instrument — a six-layer model, a table of false friends, and where the three platforms actually stand in August 2026. The second half, from The credential question onward, is the part I had not seen written down anywhere and is where the argument earns its keep. If the layer model is already familiar to you, skip straight there.

One word, six jobs

Databricks says Unity Catalog and means a governance perimeter. Snowflake says Horizon Catalog and means a control surface, while Open Catalog means a hosted Apache Polaris, while a database is what actually namespaces tables. IBM says catalog and may mean a watsonx.data object binding storage to engines, or the metastore behind it, or a governance construct, or a Presto engine binding, or a Db2 system catalog.

These are not synonyms across vendors, and not reliably synonyms within one. The consequence is worse than imprecision: a comparison conducted across mismatched layers is unfalsifiable, because no evidence can settle a claim whose subject changes between speakers.

The fix is to stop treating "catalog" as an object and start treating it as a stack of jobs. Each layer answers exactly one question. An object belongs to the layer whose question it answers — and if it answers two, a vendor has collapsed layers, which is a design decision with a price attached.

That right-hand panel is the argument, not decoration. The same physical table carries six independently-clocked lifecycles at once: a storage registration that outlives it, because the bucket persists after DROP; a table truth bounded by DDL; engine bindings created and dropped per engine without touching the table; policies versioned on their own cadence; a semantic definition that survives re-platforming, because a "gross margin" metric outlives the table it reads; and a share revoked while the table lives on.

Six independent lifecycles, six layers. Any claim that one object governs all of this is a claim about collapse.

A note on the numbering. L1 to L6 is my own convention for this analysis, not a vendor's. IBM, for instance, documents three access levels of its own and the label "L4" appears nowhere in its corpus. Use the layers as a lens, not as terminology to quote back at anyone.

The hourglass

Draw the market as it stands and it makes an hourglass. Many engines above, many storage systems below, and in the middle a single narrow protocol that everything now passes through.

Hourglasses are what happens when an industry agrees on exactly one thing. The internet has one at IP; the container ecosystem has one at the OCI image. The shape is diagnostic: above and below the waist, variety proliferates cheaply, because anything that speaks the waist protocol composes with everything else that does. That is precisely what has happened to table truth. An engine written against the Iceberg REST specification reads tables owned by any of the three platforms, and a table can sit on any object store any of them supports.

What makes this particular hourglass worth drawing is that it is only an hourglass in the middle. Look at what sits above the engines and the pattern breaks completely.

The waist is real and it is the good news: an engine written against the Iceberg REST specification can read tables owned by any of the three. That is a genuine, hard-won interoperability win, and it happened fast.

The top band is the part that gets glossed over. There is no interchange standard at all for governance, semantics or distribution. No Iceberg-REST equivalent for a policy. Every enforcement model is proprietary to its perimeter, every semantic definition is expressed in a vendor's own object, and the only way to move policy between estates is to re-implement it. When someone tells you the lakehouse is now open, ask which band they mean.

The false friends

Six words survive translation between vendors while changing referent, which is the precise definition of a false friend. Read the column, not the word.

The costliest is "open catalog". In two estates it is a common noun; in the third it is a registered product name for a service that no longer accepts new first-use accounts. A team saying "we're standardising on the open catalog" has said nothing verifiable until someone asks which one.

Where the three stand

Databricks — collapse by extension

Unity Catalog spans five of the six layers, from table truth to distribution, under one grant model and one metastore per region. Managed Iceberg reached general availability alongside Delta on 21 May 2026¹, and August 2026 alone added role-based access control at GA on the 19th, sharing of managed Iceberg tables on the 14th, and three separate ABAC extensions.⁶ Classification is native and agent-driven⁹, and business semantics now ship as metric views, Domains and Pages, where A Page is a governed, authoritative definition of a business concept⁷ — a business glossary in all but name.

The cost of the collapse comes in three parts. Policies, metrics, shares and audit exist only inside the Unity Catalog boundary. Federated catalogs are read-only, with internal Hive metastores the sole exception³, and credential vending is explicitly unsupported on foreign Iceberg tables.² And the open-source escape hatch is partial: Unity Catalog OSS remains a Linux Foundation sandbox project.⁸

Snowflake — open at the bottom, re-centred at the top

Snowflake genuinely opened table truth, contributed Polaris to the ASF, and made an unusually specific anti-fork commitment:

"Horizon Catalog uses Apache Polaris as its catalog engine, the same open source project anyone can download and operate themselves… We are not shipping a separate 'community edition' that behaves differently from what we run in production."²⁹

Read that alongside the fact that Open Catalog, the managed Polaris service, no longer accepts new first-use accounts and new customers are pointed at Horizon.¹⁶ The strategy legible from the artefacts is to commoditise the layer where a competitor led, and differentiate above it.

Which makes the governance claim the one to examine, and it will not survive the next section intact.

IBM — six layers, no single owner

IBM occupies every layer with a different product at each. The convergence point is table truth: the Metadata Service implements selected APIs from the Iceberg REST Catalog and Unity Catalog Open API spec⁴⁰. Selected is load-bearing, and IBM says so — multi-level namespace creation is unsupported, and Presto cannot query views created through the REST catalog API, an incompatibility that extends to Spark-created views too. Still, it makes watsonx.data the only one of the three whose technical catalog natively speaks a competitor's contract.

The fragmentation is at governance: an instance integrates with only one of the following policy engines — Apache Ranger or IBM Knowledge Catalog, not both.⁴² And the choice is not symmetric. Ranger's service types cover Presto and Spark⁴³, while IBM documents Knowledge Catalog governance for Presto (C++), and Presto (Java) engines only. IBM's own governance product covers fewer of IBM's own engines than the Apache alternative does. Above that, the semantic layer runs in a single region⁴⁷ and there is no marketplace equivalent to what the other two ship.

"Bidirectional" means three things

Every vendor here uses "bidirectional interoperability" for capabilities that are not the same capability. As of today there are three distinct directions with three different maturities, and conflating them is the most common technical error in these conversations.

The confusion is not accidental, and it is not quite dishonest either. Each direction genuinely is a form of writing across a catalog boundary, so each genuinely earns the adjective. What the shared phrase hides is that they answer different questions. Outbound asks whether this platform can act as a client of someone else's catalog. Inbound asks whether this platform will let someone else's engine mutate tables it owns. Through asks whether this platform will broker access to tables nobody here owns. A team that needs the second and is sold the first has bought a working feature that does not solve its problem.

They also carry different risk. Outbound writes put your data in a catalog you control, executed by an engine you are already paying for. Inbound writes hand mutation rights over your tables to an engine you may not operate, under a credential discussed later in this article. The maturity dates below matter, but the authority question matters more and does not appear on any release note.

The third panel is the one worth pausing on. A catalog that brokers access to tables it does not own has moved from layer two to layer three — it has stopped being a metastore and started being an engine binding. If you have one word for both, you cannot see that happen.

The credential question

Here is the mechanism that every architecture diagram draws as a single arrow.

When an external engine wants to read an Iceberg table, it asks the catalog to load it and signals that it can accept delegated storage access. The Iceberg REST specification defines this as an HTTP header, X-Iceberg-Access-Delegation, with exactly two permitted values — vended-credentials and remote-signing. The specification is careful to make it a request, not a demand: it is an optional signal to the server that the client supports delegated access, and the server may choose to supply access via any or none of the requested mechanisms.³²

What is striking is how little the specification says about what comes back. The StorageCredential object has exactly two required fields: a prefix, which indicates a storage location prefix where the credential is relevant, and an untyped string map. No credential type is mandated, no expiry field is defined, no lifetime semantics exist at all.³² Everything concrete is left to implementations, and they have filled the vacuum differently: Apache Polaris calls AWS STS AssumeRole with an inline session policy scoped to the specific table locations and operations on S3, mints a user-delegation SAS on Azure, and downscopes an OAuth token on GCS.³³ Databricks documents a one-hour default expiry and a dedicated privilege that is deliberately excluded from ALL PRIVILEGES to avoid accidental exfiltration.¹⁰

Now follow what happens to the user.

The end user is not in the room

This is the finding that reorganises everything above it.

Search the entire Iceberg REST OpenAPI specification for a mechanism to propagate end-user identity to storage and there is nothing — no impersonation, no on-behalf-of, no principal forwarding. The only identity plumbing in the document belongs to the deprecated OAuth token-exchange endpoint and authenticates a client to the catalog, never to the object store.³² Apache Polaris makes the consequence explicit and countable: Three distinct IAM identities take part in the S3 credential-vending flow, and the end user is not among them. Polaris uses the caller's identity to decide whether to vend and how narrowly to scope the prefix, then the client uses those credentials to talk to S3 and KMS directly.³⁵

None of this is a defect in the specification. It is a consequence of the thing that makes the specification valuable: direct engine-to-storage reads, with no proxy in the data path. You cannot have both that and enforcement in the same request.

What the project itself says

No primary source states the bypass in blunt terms. There is no sentence in the specification, the Iceberg documentation or the Polaris documentation saying "vended credentials bypass column masking and row filtering." That absence is worth reporting honestly, and it is not the end of the matter, because the project has documented the underlying problem in its own words — and more damningly than a blunt statement would.

The active fine-grained-access-control proposal for the REST specification puts every enforcement obligation on the client: the catalog returns restrictions, and a reader must enforce projections on the columns it is actually reading.³⁷ It has been open and unmerged since 2026; two earlier attempts to place fine-grained access control in the specification were closed as not planned. On the project's development list the reasoning is stated plainly:

"we are conflating trust with proof: proof is very hard and very expensive, and arguably unachievable"… "Trust contract (out of spec): admin/catalog decides which clients are non-malicious and wired up to enforce."³⁶

And on identity, from the same discussion: identity propagation across multi-tenant query engines is a real problem, but it's orthogonal to the spec.³⁶

The honest reading is that the tension is not denied. It is relocated — reclassified from a specification problem into a deployment and trust problem, and moved out of scope. Which is a defensible engineering decision, and one that transfers the entire burden onto whoever operates the estate. If your governance model assumes the catalog enforces, and the catalog's own project says enforcement is a property of clients you have chosen to trust, those are different models.

Worth knowing too: the alternative delegation mode, remote signing, keeps the catalog in the path for every object request — and the project's own contributors describe the cost as per-file round trips that can cause server overwhelm for very huge tables, with a non-configurable fifteen-minute signature lifetime on AWS and GCS.³⁶ The choice is not between safe and unsafe. It is between a proxy you must scale and a credential you must trust.

What each vendor actually does about it

All three had to resolve the same tension, and the convergence in their answers is the strongest evidence that the tension is structural rather than incidental.

Two of the three converged on the identical resolution: when fine-grained policy has to hold, stop vending credentials and bring the query back inside. Both accepted the same collateral damage — read-only, and a single engine or connector. Neither has demonstrated fine-grained enforcement co-existing with genuine direct-to-storage open-catalog access, because on the evidence above, nobody can.

One contradiction to be aware of before you quote anyone

Snowflake's own pages disagree about how far its enforcement reaches. The Horizon overview makes an engine-agnostic claim — Masking and row-access policies are enforced across any Iceberg REST Catalog-compatible engine¹⁷ — while every operational page narrows it to Apache Spark with the Snowflake Spark connector, at specified minimum versions.²⁵

What happens when Trino or DuckDB — both listed as supported engines against the same endpoint — reads a table carrying a masking policy? The documentation does not say. I found no statement that the request is blocked and none that unmasked data is returned. A connector-based mechanism has no obvious path to a non-Spark engine, which makes one answer more likely, but that is inference and I am not going to publish it as fact. If your design depends on the answer, test it or get it in writing; do not take it from either the overview page or from me.

And the key custody question underneath

There is a matching pattern one layer down, and it is the same on both major platforms, which is what makes it worth noticing rather than dismissing as a product gap.

Open-format tables sit outside each vendor's strongest key-custody boundary. Databricks supports customer-managed keys for Unity Catalog, and the scope statement is explicit: This feature only applies to catalogs backed by default storage. It doesn't apply to catalogs with external storage locations.¹⁴ Snowflake's Tri-Secret Secure gives real custody — If the customer-managed key (CMK) in the composite master key hierarchy is revoked, your data can no longer be decrypted by Snowflake²⁸ — but Iceberg tables that use Snowflake storage support only server-side encryption (SSE). Customer-managed keys (CMK) are not supported, even if your account has Tri-Secret Secure enabled.²⁷

IBM deserves the same scrutiny and gets it. watsonx.data supports BYOK through Key Protect and KYOK through Hyper Protect Crypto Services at provision time — but read the scope: Backend object storage repositories for internal metadata and 10 GB limited trial bucket.⁴⁴ That is internal metadata and a trial bucket, not customer-registered data buckets. The frequently-quoted assurance that KYOK provides technical assurance that IBM cannot access the customer keys is a statement in the Hyper Protect documentation about HPCS⁴⁶ — where the same table marks that assurance No for BYOK — and it does not appear anywhere in the watsonx.data corpus. Nor is HPCS available in most of the non-US regions watsonx.data lists.

What to do with this

The six layers are not a scoring rubric and they produce no winner. They produce the ability to be specific about disagreement, which is the only durable thing in a market that ships something material every fortnight.

When someone says a catalog is "more open", the model forces the question at which layer — and the answer is almost always the waist, where all three have converged and the differences have largely evaporated. A conversation that stays at the waist is a conversation about a solved problem. That is precisely why so many of them stay there.

Five questions worth more than any feature matrix:

1. Which layer is this claim about? If it cannot be placed, it cannot be checked.
2. Which direction of write? Outbound is GA since October 2025²², with Unity on Azure only from April 2026²³; inbound read went GA in February and inbound write in May 2026²¹¹⁹, having been preview in March²⁰; through-Horizon access is thirteen days old and in preview²⁴. Three capabilities, one phrase.
3. Is the engine reading storage directly? If yes, the granularity ceiling is a path prefix and no mask or filter is in play, whatever the overview page says.
4. Where does the end user's identity stop? On the evidence here, at the catalog. Design as though everything past that point is one service principal, because it is.
5. What is inside the key-custody boundary, and is your open-format data in it? On both major platforms, currently, it is not.

One practical habit, learned expensively. Status in this market lives in dated release notes, not on feature pages — several Snowflake feature pages carry no GA or preview banner at all, so the page documenting a capability cannot tell you whether it is generally available.¹⁸ Databricks publishes monthly platform notes with explicit GA language and dates⁴, and those are the citable artefact. Put an expiry on a claim rather than a date of writing: anything preview-tier deserves re-checking at four weeks, anything GA at a quarter.

Including this article.

Notes

Every source below was retrieved on 31 August 2026. Vendor engineering blogs and press releases are marked as such and used for wording, never for feature status. Where IBM's published documentation site refused automated retrieval, IBM's own documentation source repository was used instead and the provenance is flagged. Entries marked consulted support a statement without being quoted.

1. Databricks, Platform release notes — May 2026: managed Iceberg, foreign Iceberg and Iceberg v3 generally available, 21 May 2026; also the 28 May entry for cross-engine ABAC. docs.databricks.com ↩
2. Databricks, External access to Iceberg — the Iceberg REST implementation, the read/write matrix, and Credential vending on Foreign Iceberg tables is not supported. Last updated 3 August 2026. docs.databricks.com ↩
3. Databricks, Catalog federation: Internal Hive metastores allow reads and writes — the sole exception to read-only foreign catalogs. docs.databricks.com ↩
4. Databricks, Platform release notes — April 2026: ABAC GA 28 April, governed tags GA 2 April, Data Classification GA 20 April. docs.databricks.com ↩
5. Databricks, Platform release notes — June 2026: external lineage GA; Following the release of open-source OpenSharing, Delta Sharing is now OpenSharing. docs.databricks.com ↩
6. Databricks, Platform release notes — August 2026: RBAC GA 19 Aug; managed Iceberg sharing GA 14 Aug; three ABAC extensions 11, 17 and 21 Aug; Pages Beta 12 Aug. docs.databricks.com ↩
7. Databricks, Unity Catalog semantics and Pages: A Page is a governed, authoritative definition of a business concept. business-semantics · Pages ↩
8. Unity Catalog OSS: Unity Catalog is currently a sandbox project with LF AI and Data Foundation (part of the Linux Foundation). github.com/unitycatalog ↩
9. Databricks, Data classification: Databricks Data Classification uses an agent to automatically classify and tag tables in your catalog. docs.databricks.com ↩
10. Databricks, Credential vending: Issued credentials allow direct access to the cloud storage location, scoped to the relevant path.; The default expiration time is one hour.; and To avoid accidental exfiltration, ALL PRIVILEGES does not include the EXTERNAL USE SCHEMA privilege. Whether the expiry is configurable is not documented on this page. docs.databricks.com ↩
11. Databricks, Filters and masks: You cannot use Iceberg REST catalog or Unity REST APIs to access tables with row filters or column masks. and Path-based access to files in tables with policies is not supported. docs.databricks.com ↩
12. Databricks, Cross-engine ABAC (Beta): Databricks uses a specialized serverless compute layer to filter and return sanitized data to the external engine. and Only reads are supported from external engines when fine-grained access controls (FGAC) are enforced. Note the tension with note 11, which still states the flat prohibition. docs.databricks.com ↩
13. Databricks, Storage credentials: A storage credential represents an authentication and authorization mechanism for accessing data stored on your cloud tenant. — the service identity behind vending. docs.databricks.com — consulted
14. Databricks, Customer-managed keys for Unity Catalog: This feature only applies to catalogs backed by default storage. It doesn't apply to catalogs with external storage locations. and, on revocation, After you disable the key, Databricks can no longer decrypt data in catalogs using this CMK configuration. docs.databricks.com · CMK overview ↩
15. Databricks, SCIM provisioning — account-level SCIM from the identity provider; workspace-level SCIM is legacy. docs.databricks.com — consulted
16. Snowflake, Open Catalog overview: Snowflake Open Catalog is a managed service for Apache Polaris™; Customers who haven't previously created a Snowflake Open Catalog account can't sign up for their first Open Catalog account. docs.snowflake.com ↩
17. Snowflake, Horizon Catalog — the engine-agnostic enforcement claim: Masking and row-access policies are enforced across any Iceberg REST Catalog-compatible engine. docs.snowflake.com ↩
18. Snowflake, Access Snowflake-managed Iceberg tables using an external query engine through Horizon Catalog — the vended-credentials configuration, captioned twice This code doesn't enforce data protection policies:; the restriction list including Writing to tables that have fine-grained access control policies or tags isn't supported.; and the per-user-and-role token model, You need to obtain an access token for each user — service or human — and role. This page carries no GA or preview banner. docs.snowflake.com ↩
19. Snowflake, release note 26 May 2026 — inbound external write GA. docs.snowflake.com ↩
20. Snowflake, release note 16 March 2026 — inbound write, Preview. docs.snowflake.com ↩
21. Snowflake, release note 6 February 2026 — inbound read, GA. docs.snowflake.com ↩
22. Snowflake, release note 17 October 2025 — externally managed Iceberg writes and catalog-linked databases, GA. docs.snowflake.com ↩
23. Snowflake, release note 6 April 2026 — Iceberg write support for Azure Unity Catalog, GA. docs.snowflake.com ↩
24. Snowflake, release note 18 August 2026, Preview: You can now use the Horizon Iceberg REST Catalog (IRC) API to access externally managed Apache Iceberg™ tables in a catalog-linked database from external engines such as Apache Spark™, Trino, DuckDB, or PyIceberg. docs.snowflake.com ↩
25. Snowflake, Enforce access policies when querying with an external engine through Horizon Catalog: The Spark connector supports querying tables that are protected by Snowflake policies by routing the query through Snowflake, which ensures efficient use of compute and consistent enforcement. and Queries on tables that are protected with any other data policy result in an error. Scoped throughout to Apache Spark at specified minimum versions. docs.snowflake.com ↩
26. Snowflake, release note 27 January 2026 — enforce data protection policies when querying Iceberg tables from Apache Spark. docs.snowflake.com — consulted
27. Snowflake, Iceberg tables on Snowflake storage: Iceberg tables that use Snowflake storage support only server-side encryption (SSE). Customer-managed keys (CMK) are not supported, even if your account has Tri-Secret Secure enabled. docs.snowflake.com ↩
28. Snowflake, Tri-Secret Secure: If the customer-managed key (CMK) in the composite master key hierarchy is revoked, your data can no longer be decrypted by Snowflake. Neither this page nor the encryption-management page mentions Iceberg or external volumes. docs.snowflake.com ↩
29. Snowflake Engineering, Apache Polaris: The End of Data Vendor Lock-In, 9 April 2026. snowflake.com — vendor engineering blog ↩
30. Snowflake, release note 2 March 2026 — querying semantic views in standard SQL, GA. docs.snowflake.com ↩
31. Apache Polaris, Apache Polaris Graduates to Top Level Project!, 19 February 2026. polaris.apache.org · foundation announcement 5 March 2026: news.apache.org ↩
32. Apache Iceberg, REST Catalog OpenAPI specification, main branch — the X-Iceberg-Access-Delegation parameter (Optional signal to the server that the client supports delegated access…, The server may choose to supply access via any or none of the requested mechanisms.), the StorageCredential schema (Indicates a storage location prefix where the credential is relevant.), the /sign endpoint, and the deprecation of the built-in token endpoint. The specification defines no credential type, no expiry field, and no end-user identity propagation. github.com/apache/iceberg ↩
33. Apache Polaris 1.7.0, Vended credentials: Polaris calls AWS STS AssumeRole with an inline session policy scoped to the specific table locations and operations (read, list, write) the caller is authorized to perform. polaris.apache.org ↩
34. Apache Polaris 1.7.0, Access control — the privilege model, in which TABLE_READ_DATA Enables reading data from the table by receiving short-lived read-only storage credentials from the catalog: reading and receiving credentials are the same grant, and the vocabulary bottoms out at the table. polaris.apache.org — consulted
35. Apache Polaris 1.7.0, Configuring AWS S3: Three distinct IAM identities take part in the S3 credential-vending flow. and the client uses those credentials to talk to S3 and KMS directly. polaris.apache.org ↩
36. Apache Iceberg developer list, fine-grained access control and read restrictions, 2026: we are conflating trust with proof: proof is very hard and very expensive, and arguably unachievable; Trust contract (out of spec): admin/catalog decides which clients are non-malicious and wired up to enforce.; identity propagation across multi-tenant query engines is a real problem, but it's orthogonal to the spec. On remote signing: one of the concerns of the current remote signing was that it was requested was per file and it can cause server overwhelm for very huge tables. lists.apache.org · remote-signing thread — official project mailing list; discussion, not ratified specification ↩
37. Apache Iceberg, pull request 13879 — read restrictions for the REST specification, open and unmerged: A reader must enforce projections on the columns it is actually reading. Quoted from the raw diff. Two earlier attempts, issues 10909 and 14187, were closed as not planned. patch-diff.githubusercontent.com ↩
38. Apache Polaris 1.7.0, External identity providers: Apache Polaris supports authentication via external identity providers (IdPs) using OpenID Connect (OIDC) — note this is an implementation choice; the specification defines no SSO or OIDC integration. polaris.apache.org — consulted
39. IBM, Release notes for watsonx.data: MDS replaces the Hive Metastore from version 2.1; and at 2.2.1, The Metadata Service (MDS) in watsonx.data now supports issuing vended credentials through the Iceberg and Unity REST APIs., framed as without the need to manage long-lived access keys. IBM documentation source repository — ibm.com/docs refuses automated retrieval; this is IBM's own docs source, repository HEAD dated 26 May 2026 ↩
40. IBM, Unity Catalog REST API and Iceberg REST Catalog API: Metadata Service implements selected APIs from the Iceberg REST Catalog and Unity Catalog Open API spec.; X-Iceberg-Access-Delegation is supported for vended-credentials.; unsupported features include Multi-level namespace creation; and Presto cannot query views created using the Iceberg REST catalog API due to encoding incompatibility. IBM documentation source repository ↩
41. IBM, MDS Iceberg REST Catalog and Unity Catalog API specification — the temporary-table-credentials and temporary-path-credentials endpoints, whose response carries aws_temp_credentials, azure_user_delegation_sas, gcp_oauth_token and expiration_time. No credential lifetime is documented as an input. cloud.ibm.com/apidocs — consulted
42. IBM, Integrating Apache Ranger: You can only integrate with one of the following policy engines starting with watsonx.data version 2.1. — Apache Ranger or IBM Knowledge Catalog. The Knowledge Catalog page states its own scope: You can define IKC governance policies for Presto (C++), and Presto (Java) engines. Ranger page · Knowledge Catalog page — IBM documentation source repository ↩
43. IBM, Ranger service types: Create resource policies in this Ranger service type to enforce security on catalogs(Iceberg, Hive and Hudi), buckets, schemas and tables used by Presto engine in watsonx.data., with the equivalent Hadoop SQL type for Spark; and for external Spark, add authz.IBMSparkACExtension to spark.sql.extensions — a cooperating-client model. Ranger service types · external Spark extension ↩
44. IBM, Data security: Backend object storage repositories for internal metadata and 10 GB limited trial bucket are encrypted by using AES-256. Customer Bring-your-own-key (BYOK) via Key Protect and Keep-your-own-key(KYOK)via Hyper Protect Crypto(HPCS) are supported at provision time — quoted verbatim, spacing included. The regional tables list HPCS as unavailable in Frankfurt, London, Tokyo and Sydney. IBM documentation source repository ↩
45. IBM, Registering Amazon S3 storage: The Role ARN is used to generate temporary credentials with permissions defined by the role's access policies. — the vended credential carries the role's permissions, not the caller's. IBM documentation source repository — consulted
46. IBM, Hyper Protect Crypto Services FAQ: In addition to the BYOK capabilities, KYOK provides technical assurance that IBM cannot access the customer keys. The same page's comparison table marks technical assurance No for BYOK and Yes for KYOK. This statement is about HPCS and does not appear in the watsonx.data documentation. IBM documentation source repository ↩
47. IBM Cloud Global Catalog API, live query, 31 August 2026 — watsonx BI carries geo_tags ['us-south']. globalcatalog.cloud.ibm.com ↩

Stated limits. Three things in this article rest on absence rather than statement, and are marked as such in the text: that no primary Iceberg source declares the vending bypass in plain terms; that IBM documents no interaction between credential vending and its policy engines; and that no source settles what a non-Spark engine receives when it reads a policy-protected Snowflake table. IBM findings were retrieved from IBM's own documentation source repository because ibm.com/docs refuses automated retrieval; that repository's HEAD is dated 26 May 2026, so anything IBM published since would not appear here. Corrections are welcome and will be applied with the date attached.