In Snowflake, what does a secure data share give a consumer account, and what gets copied?

## What a share actually is A share is a named account-level object in the **provider's** Snowflake account. It lives in the cloud services (metadata) layer and contains exactly two things: a collection of grants on objects, and a list of consumer accounts entitled to import it. It contains no rows. Nothing about it resembles an export, a replication job or a copy. The object types you can put in a share are limited: databases and schemas (usage), tables, external tables, secure views, secure materialized views and secure UDFs. Notably a *standard* view cannot be added to a share — it must be declared `SECURE`, because a share hands query access to a party outside your account and Snowflake will not expose a view whose definition and optimizer behaviour could leak the underlying data. ## Setting one up On the provider side, the grant chain must be complete from the database down: ```sql CREATE SHARE sales_share; GRANT USAGE ON DATABASE analytics TO SHARE sales_share; GRANT USAGE ON SCHEMA analytics.public TO SHARE sales_share; GRANT SELECT ON TABLE analytics.public.orders TO SHARE sales_share; ALTER SHARE sales_share ADD ACCOUNTS = myorg.partner_acct; ``` A missing `USAGE` on the schema is the single most common reason a consumer sees an empty database. On the consumer side: ```sql CREATE DATABASE partner_sales FROM SHARE provider_org.provider_acct.sales_share; GRANT IMPORTED PRIVILEGES ON DATABASE partner_sales TO ROLE analyst; ``` The second statement matters and is often forgotten: privileges arriving through a share are *imported* privileges, and the consumer's ACCOUNTADMIN must pass them to the roles that will actually query. ## Why nothing is copied Snowflake stores table data as immutable compressed columnar micro-partitions in cloud object storage owned by the provider's account, with all metadata held centrally. A share adds an entry to that metadata saying "account X may read these objects". When the consumer's warehouse executes a query, it reads the provider's micro-partition files directly. There is no second copy to fall behind, so freshness is a non-issue: as soon as a provider transaction commits, the consumer's next query sees it. This is also why the consumer's shared database contributes nothing to their storage bill — they own no bytes. ## Who pays for what - **Provider**: storage for the one physical copy of the data. Nothing for the consumer's queries. - **Consumer**: compute. They run queries on their own virtual warehouse, in their own account, on their own credits. This split is what makes sharing attractive commercially — a provider can serve many consumers without their query load touching the provider's warehouses or bill. It also means a consumer's runaway dashboard cannot degrade the provider, since the compute clusters are entirely separate. ## What the consumer cannot do The imported database is read-only in a strong sense: - no `INSERT`/`UPDATE`/`DELETE`, and no DDL inside it; - it cannot be cloned; - it cannot be re-shared onward to a third account; - Time Travel over the shared objects is not available to the consumer. If the consumer needs a mutable or historical copy, they do the obvious thing: `CREATE TABLE my_copy AS SELECT ... FROM partner_sales...`, which is their own data on their own storage bill, and which immediately reintroduces every staleness problem sharing was meant to remove. ## Where it fits in an interview The scenario that pulls this out is "a partner or a subsidiary needs our data". The weak answer is a nightly `COPY INTO` to S3 plus a loader on their side — a pipeline to build, monitor, secure and pay egress on, delivering yesterday's data. The strong answer is a share: no movement, no lag, revocable in one statement (`ALTER SHARE ... REMOVE ACCOUNTS`), and the access surface is exactly the objects you granted rather than a bucket somebody may have made world-readable. The constraints worth naming unprompted are that both accounts must be in the same cloud region for a direct share (otherwise replication or a listing is required), and that only secure views can carry any row- or column-level restriction you want to impose.