Explain Secure Data Sharing & Reader Accounts in Databases

48 / 66

Snowflake

Secure Data Sharing & Reader Accounts

Share live data across Snowflake accounts without copying or moving it.

Sharing data with another company normally means exporting files, transferring them, and loading them on the other side — a pipeline to build, run and monitor, and a copy that is always out of date.

It's like giving someone a live, read-only window into your filing cabinet instead of mailing them photocopies — they always see the current contents, and you never lose control of the original.

Key Concepts

Snowflake shares the data where it already lives. Nothing is copied and nothing moves.

How it works. The provider creates a share and grants objects into it:

    CREATE SHARE sales_share;
    GRANT USAGE ON DATABASE prod TO SHARE sales_share;
    GRANT SELECT ON TABLE prod.public.orders TO SHARE sales_share;
    ALTER SHARE sales_share ADD ACCOUNTS = partner_account;

The consumer creates a database from it and queries it like any other, read-only:

    CREATE DATABASE partner_data FROM SHARE provider.sales_share;

The consumer is reading the provider's storage. There is no second copy, so the data is never stale — a row written by the provider is visible to the consumer immediately.

That also means the provider can revoke access instantly, and the data was never in the consumer's possession to keep.

Who pays for what. This split is the detail interviewers ask about. The provider pays for storage, since it is their data. The consumer pays for compute, because queries run on the consumer's own warehouse.

So sharing costs the provider essentially nothing, no matter how heavily the consumer queries it.

Reader accounts, for consumers who are not on Snowflake. A provider can create a lightweight account managed by them, for the partner to log into:

    provider pays the compute for a reader account

That flips the cost model — deliberately, because this is how you deliver data as a product to customers who are not Snowflake users. Reader accounts need a credit limit set, or a partner's heavy query becomes your bill.

Share a secure view, not a table. A plain view can leak more than intended through its definition and through the query profile. A secure view hides its definition and restricts optimisations that could expose rows the consumer should not see.

Combined with a row access policy, one share can give each consumer only their own rows from a shared table, which is how a provider serves many customers from one dataset.

This is what the Marketplace is. Public datasets on the Snowflake Marketplace are shares. Subscribing gives you a database that queries the publisher's storage — no download, no load, current immediately.

The limits to state. Both sides must be in the same cloud region, or the provider must set up replication to the consumer's region. Shared data is strictly read-only, and cannot be re-shared onward by the consumer.

What the interviewer is probing.1. "How does sharing avoid copying data?" Probing: the mechanism. Stalls: "It copies efficiently." Moves up: the consumer queries the provider's micro-partitions through metadata; nothing is transferred or duplicated.

2. "Who pays for a share?" Probing: the commercial detail. Stalls: "The provider." *Moves up:* the consumer pays the compute on their own warehouse; the provider pays only the storage.

3. "What is a reader account for?" Probing: the case. Stalls: "Read-only users." Moves up: a consumer who is not a Snowflake customer — the provider creates and pays for the account's compute.

4. "What are the constraints on sharing?" Probing: the limits. Stalls: "None." Moves up: same cloud and region unless you replicate, and shares are read-only with secure views needed to restrict rows.