skip to content

When delivering data to 40 partners daily, when is a Snowflake share the wrong choice?

level: principalimportance: should knowfreq 32%

answer

  1. cheap only when everyone is in your region
  2. who pays compute flips for non-customers
  3. an auditor wants a file, not a live view
  4. applications need milliseconds, not warehouses
  5. tier the partners instead of choosing once

basics

~20 s

A share is wrong when partners are not on your cloud region, need data in their own stack, require point lookups at application latency, or need an immutable as-of snapshot for contractual or audit reasons.

solid answer

~50 s

Sharing wins on the axes it was built for: no pipeline, no egress, live data, and revocation in one statement. It stops being the right answer in four situations. First, the partner is not a Snowflake customer or is in another region — then you are into reader accounts (you pay their compute), replication or listings (you pay storage and transfer per region), which erodes the cost argument. Second, the partner's consumers are applications needing millisecond point lookups; a warehouse is not that, and an API over a serving store is. Third, the delivery is contractual — a fixed, immutable, signed extract as of a date — where live data is a liability, not a feature, and a file drop is what the auditor wants. Fourth, the data must land in their lake or their tooling, in which case `COPY INTO` an external stage they own is honest. Most estates end up with both, and the design decision is which partners belong on which path.

code

sql · 16 lines
sql
-- Tier 1: same-region Snowflake partners, entitlement-driven share
GRANT SELECT ON VIEW analytics.public.orders_shared TO SHARE partner_share;
ALTER SHARE partner_share ADD ACCOUNTS = myorg.partner_a, myorg.partner_b;

-- Tier 4: the contractual extract, driven by the SAME entitlement table
COPY INTO @partner_a_stage/orders/2025-08-01/
FROM (
  SELECT o.*
  FROM analytics.public.orders o
  JOIN analytics.public.entitlements e
    ON o.customer_id = e.customer_id
  WHERE e.snowflake_account = 'MYORG.PARTNER_A'
    AND o.order_ts >= '2025-08-01'
)
FILE_FORMAT = (TYPE = PARQUET)
HEADER = TRUE;

go deeper

for a junior

Know the basic contrast: a share gives live read-only access with no pipeline, while an export produces files somebody has to load and that you can never take back.

for a middle

Be able to name the conditions a direct share requires — same cloud region, a Snowflake account on the far side — and what the fallbacks cost when those do not hold.

for a senior

Argue the tradeoffs concretely: who pays compute in each arrangement, where freshness becomes an SLA you operate, and which paths make revocation trivial versus impossible.

for a principal

Own the distribution strategy for the whole partner estate — tier the partners, define entitlement once as data so every path enforces it identically, and model the regional fulfillment cost before committing to it contractually.

## Framing the decision At forty partners the question is no longer "can Snowflake do this" but "what am I committing to operate for the next three years". Compare the options on the axes that actually generate incidents and invoices. ## What sharing buys you - **No pipeline.** No export job, no scheduler, no landing bucket, no loader on their side, no reconciliation when a file is missing. This is the largest hidden win: the pipeline you do not build cannot page you. - **No copy, no egress.** Same-region consumers read your micro-partitions; you pay storage once. - **Live data.** Committed writes are visible on their next query. No freshness SLA to define or defend. - **Instant, complete revocation.** `ALTER SHARE ... REMOVE ACCOUNTS` and the access is gone. Every file you have ever delivered, by contrast, stays delivered forever. - **A precise access surface.** You grant specific objects and specific rows via secure views, not a bucket somebody may misconfigure. ## Where it stops fitting **1. The partners are not where you are.** A direct share requires the same cloud and region and a Snowflake account on the far side. Across forty partners you will not get that for free. The fallbacks each cost you something: reader accounts put their compute on your bill and their administration on your team; replication or listing auto-fulfillment puts remote storage and cross-region transfer on your bill and turns freshness into a refresh schedule you must monitor. Model this before promising it — with forty partners spread over several regions, "sharing is free" quietly becomes untrue. **2. The consumer is an application, not an analyst.** Warehouse queries are seconds-scale and a warehouse must be running to answer. If the partner's use case is a per-request lookup behind their product, the right architecture is an API over a serving store they or you operate, fed from the warehouse — not a share and certainly not forty partners each spinning up a warehouse against your data. **3. The delivery is contractual or regulated.** When the obligation is "the position file as of month-end, immutable, reproducible on audit", live data is a defect. You want a generated, checksummed, retained artifact. `COPY INTO @stage` producing dated files, retained on your side, is the honest implementation. A share cannot promise that the number they saw last Tuesday is the number they see today — indeed it promises the opposite. **4. The partner's stack is not Snowflake and never will be.** If their analysts live in a different platform, a share gives them a login to a tool they do not use. Files into storage they own, or a listing if their platform can consume one, respects the reality. **5. Data residency forbids the read.** If the contract or regulation says the data may not leave a jurisdiction, neither a cross-region share nor a replicated copy is permissible, and the answer is a locally-hosted derived dataset — often aggregated or de-identified — rather than any form of raw sharing. ## The design that usually wins Rather than choosing once for forty partners, tier them: - **Tier 1 — Snowflake customers in your region.** Direct share of a secure view driven by an entitlement table, so onboarding is an `INSERT` and offboarding is a `DELETE`. This should be the default and should absorb the majority. - **Tier 2 — Snowflake customers elsewhere, or partners you want to onboard self-serve.** A private listing with auto-fulfillment. You accept storage and transfer per region and monitor freshness; you avoid building anything. - **Tier 3 — non-Snowflake partners, small and strategic.** A reader account with a small warehouse, short auto-suspend, a hard-limited resource monitor, and a network policy. Explicitly time-boxed: it is a ramp to Tier 1 or 2. - **Tier 4 — contractual extracts and foreign stacks.** A single, well-instrumented export path to files, shared by all such partners, with retention and checksums. What makes this a principal-level answer is that the entitlement model is common across tiers. One secure view filtered by `CURRENT_ACCOUNT()` for shares, and the same entitlement table driving the export job's partitioning, means access is defined once as data and enforced everywhere. The failure mode to avoid is forty bespoke arrangements, where nobody can answer "who can see customer 12345's rows" without reading forty configurations. ## What to instrument regardless Whichever tiers you run, you owe yourself: an inventory of who has what, alerting on replication or export failures (silent staleness is the worst outcome), credit monitoring on any reader accounts, and a rehearsed revocation path. Sharing makes revocation trivial and exports make it impossible — that asymmetry alone is a good reason to keep the export tier as small as you can.

  • A partner asks for both a live share and a monthly immutable extract. Is that redundant?
    No, and it is a common shape. The share serves analysts who want current data; the extract serves the contractual or audit obligation that a specific set of numbers as of a date can be reproduced later. They answer different questions. What must be shared between them is the entitlement definition, so both paths filter identically.
  • How would you keep the access model consistent across shares, reader accounts and file exports?
    Define entitlement once, as a provider-owned table mapping each partner to the keys they may see. Shares consume it through a secure view filtered by CURRENT_ACCOUNT(); the export job consumes it to decide which rows go into which partner's files. Onboarding and offboarding become DML in one place, and the question 'who can see this row' has a single answer.
  • What would make you kill the file-export tier entirely?
    When the only partners left on it could be served by a listing, and no contractual obligation requires an immutable artifact. Exports are the tier with unbounded revocation risk — delivered files cannot be recalled — plus egress cost and a pipeline to operate. Shrinking it is a security win as much as a cost one.
  • How do you stop forty partner arrangements from becoming forty snowflakes to operate?
    Standardise on a small number of tiers with the same entitlement source, and refuse bespoke deals below a revenue threshold. Keep an inventory of who is on which tier, alert on staleness in every copy-based path, cap every reader account with a resource monitor, and rehearse revocation. The goal is that onboarding partner forty-one costs a row, not a project.

Sharing is giving partners a seat in your reading room; an export is mailing them a printed copy. The reading room is cheaper and always current, but only for the people who can reach the building, and only when nobody needs a stamped document to file.

saying these in an interview costs you the question

  • Treats sharing as free regardless of region or partner platform
  • Proposes a share for millisecond application lookups
  • Uses a live share to satisfy an immutable audit extract
  • Builds forty bespoke arrangements with no common entitlement model
  • Ignores that exported files can never be revoked

context

resolving links…