Snowflake Secure Data Sharing lets organisations share live data with external parties without copying or moving it. This guide covers how shares, listings, and the data marketplace work — and the governance questions you need to answer before sharing.
Snowflake Secure Data Sharing allows you to share live, read-only access to data in your Snowflake account with other Snowflake accounts — without copying the data, moving it, or giving the recipient credentials to your account. The recipient queries the data directly from your storage layer. This guide covers how sharing works, the mechanics of shares and listings, the data marketplace, and the governance questions you need to resolve before making your first share.
How Snowflake data sharing actually works
Traditional data sharing involves extract → transfer → load: you pull data from your database, send it to a partner (via SFTP, email, or an API), and they load it into their system. The data is duplicated, stale from the moment it is transferred, and governed by a separate pipeline.
Snowflake shares work differently. A share is a Snowflake object that grants a specific external Snowflake account read access to specific databases, schemas, tables, or views in your account. The data does not move — the recipient queries your data files directly, using Snowflake's multi-cluster shared data architecture. When you update the data, the recipient sees the update immediately.
This is possible because Snowflake's architecture separates compute from storage. Your data is stored in Snowflake-managed object storage (S3 or Azure Blob beneath the abstraction). The recipient's Snowflake virtual warehouse runs queries against your storage, not a copy of it. Only the metadata (schema definitions, access grants) needs to be shared.
Creating a share
A Snowflake share is created and managed by the data provider:
1. CREATE SHARE creates the share object
2. GRANT DATABASE, SCHEMA, TABLE, or VIEW to the share grants access to specific objects
3. ALTER SHARE ADD ACCOUNTS adds the recipient Snowflake account(s)
The recipient then creates a database from the share:
CREATE DATABASE shared_data FROM SHARE provider_account.share_name;
After this, the recipient can query the shared data exactly like any other Snowflake table, using their own virtual warehouse compute. The provider's compute is not used for the recipient's queries.
Reader accounts
If your data recipient does not have a Snowflake account, you can create a Reader Account — a limited Snowflake account provisioned by the provider specifically for sharing. Reader accounts:
- Are fully managed by the provider (you create and maintain them)
- Cannot query any data other than what you have shared with them
- Use compute managed and billed by the provider (not the recipient)
Reader accounts are appropriate for sharing with external partners, customers, or regulators who do not have Snowflake. The provider bears the compute cost for recipient queries — size the reader account's warehouse appropriately and consider query credits used.
Secure views for controlled sharing
You often do not want to share an entire table with a recipient. A customer-facing share should not expose raw PII. A partner share may include only aggregated data. Secure views solve this.
A secure view in Snowflake is a view where the view definition is hidden from the recipient (unlike standard views, which expose their SQL to users with sufficient privileges). Create a secure view that exposes only the columns and rows the recipient should see, then share the view rather than the underlying table.
For dynamic filtering (a recipient should only see their own customers' data), use Snowflake's IS_GRANTED_TO_INVOKER_ROLE() function or the CURRENT_ACCOUNT() function in a WHERE clause to filter the view to records that belong to the querying account.
Data listings and the Snowflake Marketplace
A Snowflake Listing allows you to share data with many consumers without creating individual share objects for each. Create a listing in the Snowflake Data Marketplace (Snowsight → Data Products → Provider Studio) and specify:
- The data product name and description
- The share object it references
- Access type: Immediate (any Snowflake customer can access), Personalised (consumers must request access, you approve), or Trial (free preview with full access requiring approval)
Once listed, the data product is discoverable by other Snowflake users. Consumers can browse the marketplace and add your data to their account without any direct coordination with you.
The Snowflake Data Marketplace hosts thousands of commercial and free data products — weather data, financial market data, demographic data, geospatial datasets. If you are building a data product to sell, the marketplace is a distribution channel.
Governance before sharing
Before sharing data externally, answer these questions:
**What is in the data?** Audit the tables and columns in the share for PII (names, emails, addresses, SSNs), regulated data (HIPAA, GDPR, CCPA scope), contractually restricted data (data licensed from a third party with redistribution restrictions), and confidential business information (margins, unreleased product data, proprietary algorithms).
**Who has the authority to approve sharing?** Data sharing decisions with external parties often require sign-off from Legal, Security, or a Data Governance Committee. Establish the approval process before the technical setup.
**What is the recipient permitted to do with the data?** Snowflake's sharing is technically read-only, but the recipient can query the data with any SQL and download results. A data sharing agreement (a legal contract, not a Snowflake setting) should specify permitted uses, prohibit re-identification of individuals, and establish breach notification obligations.
**Is the data masked or aggregated appropriately?** Use secure views to expose only the minimum necessary data. For aggregate reporting shares (a partner who needs to see your shared revenue, not individual transactions), aggregate in the secure view rather than sharing row-level data.
Cost model
The data provider pays for storage (already paid as normal Snowflake storage costs). The data recipient pays for the compute (virtual warehouse credits) they use to query the shared data — unless you have set up Reader Accounts, in which case the provider pays compute for reader queries.
There is no transfer cost, no pipeline cost, and no additional storage cost for sharing (no copies of the data are made).
Limitations
- Shared data is read-only for the recipient. No writes, no DML.
- Cross-region and cross-cloud sharing requires data replication to a Snowflake account in the recipient's region. Snowflake's database replication feature handles this but adds replication cost and some latency.
- A share can include only objects from a single database (as of mid-2026). To share objects from multiple databases, create a database with secure views that reference objects from both.
For the broader Snowflake architecture context, see snowflake architecture best practices and snowflake pricing guide. Our data architecture consulting practice can help you design governed data sharing architectures for partner or customer data products — book a free architecture review.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →