Snowflake Open Data Sharing GA shares Iceberg tables outside Snowflake

4 hours ago

6 min read

Snowflake Open Data Sharing GA shares Iceberg tables outside Snowflake, title on a teal data skyline background. Data Studios original cover

Snowflake has moved Open Data Sharing out of preview. According to the Snowflake release note dated November 2, 2026, the feature is now generally available and lets a provider share live, read-only data held in Snowflake-managed Apache Iceberg tables with consumers who do not have a Snowflake account. Those consumers read the data through the standard Iceberg REST Catalog API from their own engine, so the provider does not build an export job, an ETL pipeline or a copy of the tables in another storage account.

The general availability release adds three capabilities on top of the preview: cross-region sharing to external consumers in Snowflake commercial regions on AWS and Azure, workload identity federation as an authentication option alongside programmatic access tokens, and the ability to add external consumers to an existing listing so that one listing serves Snowflake accounts and open clients at the same time. For a data team that already sends curated tables to partners or a separate lakehouse platform, the result is one governed share in place of a parallel file-delivery process. The scope is limited to Snowflake-managed Iceberg tables: Snowflake's documentation states that external consumers cannot read standard Snowflake tables or externally managed Iceberg tables.

··········

WHAT SNOWFLAKE OPEN DATA SHARING DOES FOR NON-SNOWFLAKE CONSUMERS.

Direct shares and listings reach other Snowflake accounts, and reader accounts serve people without their own Snowflake account. Open Data Sharing serves a team that runs its own analytics engine and wants to query the provider's tables in place. The consumer connects to a catalog endpoint that Snowflake exposes for the listing, requests a short-lived access token, and then reads table metadata and data files through the Iceberg REST Catalog API. Snowflake's documentation describes the access mode as vended credentials, requested by the client with the header X-Iceberg-Access-Delegation set to vended-credentials. Shared data is read-only and write operations are not supported.

Snowflake's overview page says the data stays in the provider's storage layer, removing egress costs and storage duplication. The same page states that auto-fulfillment for cross-region consumers incurs replication and storage costs, and it does not say who pays for compute when an external consumer runs its queries. That last point is one to clarify with Snowflake before committing to a sharing model with a partner.

........

Item	Status in the GA release
Shared objects	Snowflake-managed Iceberg tables only
Consumer access	Iceberg REST Catalog API, read-only
Authentication	PAT or workload identity federation
Cross-region consumers	AWS and Azure commercial regions
Existing listings	Can add external consumers
US government regions	Not supported
Failover and disaster recovery	Not supported yet

........

··········

HOW A PROVIDER SETS UP OPEN DATA SHARING IN SNOWFLAKE.

The setup follows a sequence of SQL objects documented by Snowflake. The provider works as ACCOUNTADMIN or with a role that holds the CREATE EXTERNAL CONSUMER privilege on the account, plus the privileges needed to create shares, listings and the shared objects.

The first object is the external consumer, created with CREATE EXTERNAL CONSUMER. Snowflake describes it as a restricted user bound to one region, and roles cannot be granted to it. The provider then attaches a credential: either a programmatic access token added with ALTER EXTERNAL CONSUMER ... ADD PAT, whose secret is shown only once, or a workload identity added with ALTER EXTERNAL CONSUMER ... ADD WORKLOAD IDENTITY.

The data must sit in Iceberg tables created with CATALOG = 'SNOWFLAKE', either on the Snowflake-managed external volume or on the provider's own external volume. The provider grants usage on the database and schema and SELECT on the tables to a share, then creates the listing with CREATE EXTERNAL LISTING. The listing manifest carries an open_sharing section with the catalog identifier and an external_targets section that names the external consumers. Snowflake documents that adding external_consumers without open_sharing makes the command fail, and that a manifest cannot combine external_targets with targets.

The last step produces the connection details for the consumer. Snowflake documents this system function, which returns the catalog name, the catalog URI, the scope and the OAuth token URI:

CALL SYSTEM$GET_LISTING_URL_FOR_EXTERNAL_CONSUMER('<listing>', '<consumer>');

The provider sends these values to the consumer together with the PAT secret or the details of the registered workload identity.

··········

WORKLOAD IDENTITY FEDERATION FOR EXTERNAL CONSUMERS.

With a PAT, the provider creates a secret and has to deliver it to the partner through a secure channel, then rotate it. With workload identity federation, the consumer's workload presents a token from its own identity provider, and Snowflake matches it to an identity registered on the external consumer. Snowflake's documentation states that no secret has to be created, distributed or rotated.

Four identity types are supported: AWS, AZURE, GCP and OIDC. The AWS example in Snowflake's documentation registers an IAM role by its ARN:

ALTER EXTERNAL CONSUMER acme_consumer ADD WORKLOAD IDENTITY acme_aws
  TYPE = AWS
  ARN = 'arn:aws:iam::123456789012:role/acme-iceberg-reader';

Azure identities require an issuer and the managed identity's object ID as subject, Google Cloud identities require the service account's unique ID as subject, and generic OIDC identities require an issuer and a subject, with an optional audience list. When the audience list is omitted, the token's aud claim must be snowflakecomputing.com. The registered properties cannot be changed after creation; to change one, the provider removes the identity and adds a new one.

A workload identity can be disabled and re-enabled without deleting it, and SHOW USER WORKLOAD IDENTITY AUTHENTICATION METHODS FOR EXTERNAL CONSUMER reports each identity's status and its last_used time, which gives the provider an audit point for partner access. Separately, CREATE OR REPLACE EXTERNAL CONSUMER does not carry over existing workload identities or PATs, so a scripted redeployment can silently cut off a partner until the credentials are added again.

··········

[[ADPLUS_300x250_1]]

CROSS-REGION SHARING AND REGION RULES.

Each external consumer is bound to a single region, set with REGION = 'PUBLIC.<snowflake_region>' when the consumer is created and fixed afterward. If the region is omitted, the consumer uses the provider account's region. Snowflake specifies that the region determines where the data is stored and served from, and has no bearing on where the consumer's client connects from.

Consumers in the provider's own region are supported on AWS, Azure and Google Cloud commercial regions. Consumers in other regions are supported on AWS and Azure commercial regions, and Snowflake states that Google Cloud is not supported for the REGION setting yet. Cross-region consumers require an auto_fulfillment block in the listing manifest, with a refresh schedule and refresh type, and one listing can serve consumers in several regions.

Network policies are the main governance gap documented by Snowflake: they are enforced only for consumers in the provider's region and are not enforced for cross-region consumers. A provider that relies on IP restrictions for partner access should treat cross-region listings as unprotected by those rules and use authentication controls instead.

··········

WHAT THE CONSUMER NEEDS TO READ THE SHARED ICEBERG TABLES.

On the consumer side, Snowflake documents a connection with Apache Spark 3.5 and Iceberg 1.9.1 as its worked example and states that any engine supporting the Iceberg REST Catalog API can connect. The client exchanges the PAT secret, or the token from its identity provider, at the OAuth token endpoint with grant_type set to client_credentials and the scope session:role:external. Workload identity clients also send the X-Snowflake-Workload-Identity-Provider header with the identity type.

The Spark configuration in the documentation includes two settings that consumer teams tend to miss. Vectorized reads must be disabled with spark.sql.iceberg.vectorization.enabled set to false, which Snowflake describes as required for Open Data Sharing tables, and the Iceberg bundle must match the cloud that serves the listing, with iceberg-aws-bundle by default and iceberg-azure-bundle for listings served from an Azure region.

........

Consumer setting	Value documented by Snowflake
Catalog type	rest
Scope	session:role:external
Access delegation header	vended-credentials
Vectorized reads (Spark)	Disabled
Bundle for Azure-served listings	iceberg-azure-bundle

........

External consumers see only the Snowflake-managed Iceberg tables in a share, while Snowflake consumers of the same listing see every object in it, so a mixed listing can present different content to the two audiences.

··········

HOW OPEN DATA SHARING FITS NEXT TO SNOWFLAKE'S OTHER RECENT CHANGES.

In the same week of release notes, Snowflake also made access to externally managed Iceberg tables through the Horizon Catalog generally available and extended Snowflake CoWork Deep Research with cited web sources. On the Databricks side, Unity Catalog recently gained relationships between metric views in Beta, and OpenAI's Data agent in ChatGPT Work connects to BigQuery, Snowflake and Databricks, so partners increasingly read the same governed tables from several engines and assistants.

··········

SNOWFLAKE OPEN DATA SHARING: WHAT TO CONFIRM BEFORE YOU SHARE.

Snowflake confirms general availability as of November 2, 2026, read-only access to Snowflake-managed Iceberg tables through the Iceberg REST Catalog API, PAT or workload identity authentication, and cross-region consumers in AWS and Azure commercial regions. Several points depend on the provider's setup: which tables are already Snowflake-managed Iceberg tables, which region each consumer is bound to, whether cross-region auto-fulfillment adds replication and storage costs to the account, and whether network policies apply to a given consumer. The documentation does not state an edition requirement, does not say who pays for compute when external consumers query, lists no support for US government regions, and notes that failover and disaster recovery are not supported yet. A provider planning a partner share should test the consumer connection in a non-production listing, confirm billing with Snowflake, and document which identities can read each listing before moving production data.

··········

·····

DATA STUDIOS

·····

datastudios.org