Why can't a Snowflake share reach a consumer account in another region, and what do you do?

## Why the boundary exists Sharing works because it moves no data. A share is an entry in Snowflake's metadata layer saying "account X may read these objects", and the consumer's warehouse then reads the provider's micro-partition files directly from cloud object storage. Those files live in exactly one place: one cloud provider, one region. A consumer account in another region has no compute in that region and no path to read those files as though they were local. So the constraint is not an arbitrary product limitation — it falls out of the zero-copy design. Same cloud, same region: share directly. Anything else needs a physical second copy. ## Route 1: database replication, then share the replica The explicit approach is to make the copy yourself, into a provider-owned account in the consumer's region, and share from there. ```sql -- In the source (primary) account ALTER DATABASE analytics ENABLE REPLICATION TO ACCOUNTS myorg.eu_acct; -- In the provider's account in the target region CREATE DATABASE analytics AS REPLICA OF myorg.us_acct.analytics; ALTER DATABASE analytics REFRESH; CREATE SHARE eu_sales_share; GRANT USAGE ON DATABASE analytics TO SHARE eu_sales_share; GRANT USAGE ON SCHEMA analytics.public TO SHARE eu_sales_share; GRANT SELECT ON VIEW analytics.public.orders_shared TO SHARE eu_sales_share; ALTER SHARE eu_sales_share ADD ACCOUNTS = myorg.eu_partner; ``` The secondary is read-only and is brought up to date by `ALTER DATABASE ... REFRESH`, which you schedule with a task. Newer Snowflake deployments express the same thing through replication groups, which replicate a set of objects together and keep them consistent with each other — worth reaching for when the share spans several databases and you care that they refresh as a unit. Things that change once a replica is in the path: - **Freshness becomes a schedule.** With a same-region share, a committed write is visible on the consumer's next query. With replication, the consumer sees the state of the last successful refresh. If the partner's SLA says "within an hour", that SLA is now yours to operate — including alerting when a refresh fails. - **Cost moves onto the provider.** You pay storage for the copy in every target region, cross-region data transfer for each refresh, and compute for the refresh itself. Wide tables refreshed often are the expensive shape. - **You have another failure mode.** A refresh that silently stops leaves a partner quietly reading stale data, which is far worse than an outage they can see. ## Route 2: a listing with auto-fulfillment The managed alternative is to publish the data as a listing — private (targeted at named accounts) or public on the Marketplace — and let Snowflake handle remote regions. With cross-cloud auto-fulfillment enabled, when a consumer in another region or on another cloud requests the listing, Snowflake provisions and maintains the remote copy for you rather than you building replication by hand. The economics do not disappear: the provider still pays for storage and transfer of the fulfilled copies, and the freshness is still that of a maintained copy rather than a live read. What you buy is that you no longer operate the replication yourself, and consumers in many regions do not each require a bespoke setup. That is the deciding factor when the answer to "how many regions?" is "we don't know yet". ## How to choose Ask three questions: 1. **How many target regions, and are they known in advance?** One known region, one partner: manual replication is simple and gives you full control of the schedule. Many or unknown: a listing with auto-fulfillment. 2. **How fresh must it be?** Neither route gives live data. If the partner truly needs the current committed state, the real fix is for them to have an account in your region — that is a conversation, not a configuration. 3. **What is the volume, and how often does it change?** Cross-region transfer is charged on bytes moved. A wide, high-churn table refreshed every fifteen minutes into three regions is a cost line you should model before you promise it, and often an argument for replicating a narrowed, pre-aggregated view of the data rather than the raw fact table. ## The interview shape This usually arrives as "our EU subsidiary can't see the share" and the interviewer is checking whether you know the same-region constraint is inherent to zero-copy sharing rather than a permissions bug. The complete answer names the constraint, gives both routes, and then volunteers what changes once a copy exists: freshness becomes a schedule you operate, and the bill moves to the provider.