skip to content

In Snowflake, how do you share data with a partner that has no Snowflake account?

level: middleimportance: should knowfreq 40%

answer

  1. the partner is not a Snowflake customer
  2. the provider provisions the account itself
  3. query cost lands on the wrong side
  4. resource monitor before you hand over credentials

basics

~10 s

Create a reader account: a Snowflake account the provider creates and owns, into which a share is imported. The partner logs in and queries, and the provider is billed for all compute it consumes.

solid answer

~50 s

A direct share requires the consumer to have their own Snowflake account. When they do not, the provider creates a **reader account** with `CREATE MANAGED ACCOUNT ... TYPE = READER`, then imports the share into it exactly as an ordinary consumer would. The partner gets credentials and a normal Snowflake UI and SQL surface over the shared objects. The important differences from a real consumer account are ownership and billing: the reader account belongs to the provider, its users cannot load their own data or share onward, and every credit its warehouses burn lands on the **provider's** bill. That inverts the usual economics of sharing, so a reader account needs a resource monitor with a hard limit from day one, and it is best treated as an onboarding ramp until the partner becomes a Snowflake customer in their own right.

code

sql · 11 lines
sql
-- Provider account
CREATE MANAGED ACCOUNT partner_reader
  ADMIN_NAME = 'partner_admin',
  ADMIN_PASSWORD = '<strong-secret>',
  TYPE = READER;

ALTER SHARE sales_share ADD ACCOUNTS = <reader_account_locator>;

-- Inside the reader account
CREATE DATABASE partner_sales FROM SHARE provider_acct.sales_share;
GRANT IMPORTED PRIVILEGES ON DATABASE partner_sales TO ROLE partner_analyst;

go deeper

for a junior

Know that the mechanism exists and what it is called: the provider creates a reader account so a non-Snowflake partner can log in and query shared data.

for a middle

Explain that the provider owns and administers the account and pays for its compute, and that reader-account users cannot load data or create shares of their own.

for a senior

Show the operational reflexes: small warehouses, short auto-suspend, a hard-limited resource monitor, secure views, network policy and MFA — because someone else's query is spending your credits.

for a principal

Frame it as a ramp with a deliberate exit. Decide when partners should be moved to their own accounts or a private listing, and be explicit about the cost and administrative burden of holding many reader accounts.

## The gap reader accounts fill Snowflake's direct sharing model assumes both sides are Snowflake customers: the provider creates a share, the consumer runs `CREATE DATABASE ... FROM SHARE ...` in **their** account and queries it on **their** warehouse. Plenty of real partners — a small supplier, a regulator, a customer evaluating your data — have no Snowflake account and no intention of buying one for a single feed. A reader account (created by `CREATE MANAGED ACCOUNT`) closes that gap. It is a genuine Snowflake account, provisioned and owned by the provider, in which the provider imports the share on the partner's behalf. ```sql CREATE MANAGED ACCOUNT partner_reader ADMIN_NAME = 'partner_admin', ADMIN_PASSWORD = '<strong-secret>', TYPE = READER; ``` The provider then adds that account to the share and, inside the reader account, creates the database from the share and grants imported privileges to whatever role the partner's users will use. From the partner's point of view they now have a Snowflake login, the web UI, and SQL over the shared tables and secure views. ## What is different from a real consumer account - **Ownership.** The provider administers it: users, roles, warehouses, network policy. The partner is a guest, not a tenant. - **Read-only by design.** Users in a reader account query shared data; they cannot load their own data into it, and they cannot create shares of their own. - **Billing inverts.** This is the point interviewers press. In ordinary sharing the consumer pays compute; in a reader account the *provider* pays for every warehouse the partner runs. A curious partner writing an unfiltered cross join is spending your credits. ## Operating one safely Because the compute bill is yours, a reader account without guardrails is an open tab: - Size the reader account's warehouses small (XS or S) and set an aggressive `AUTO_SUSPEND` so idle sessions stop the credit clock. - Attach a **resource monitor** with a hard limit and a suspend action, not just a notification trigger, so an accident caps out rather than compounding. - Give the partner a role with only the imported privileges it needs, and expose secure views rather than base tables so the slice is defined server-side. - Apply a network policy restricting the partner's login to their IP ranges, and require MFA on the admin login. ## When to use it, and when not to Reader accounts are best framed as a **ramp**, not a destination. They are right when the partner count is small, the volume is modest, and the relationship is worth the compute you are absorbing — a proof of value, a regulator, a handful of suppliers. They scale badly: every reader account is another account for you to administer, another warehouse fleet to size, another line on your bill that grows with someone else's curiosity. The alternatives, in rough order of preference as the relationship matures: 1. **The partner gets their own Snowflake account** and consumes a direct share. Administration and compute cost move to them, where they belong. 2. **A private listing**, if you want a discoverable, self-serve entry point for several such partners while keeping the consumer-pays model. 3. **An export pipeline** (`COPY INTO` an external stage, or an API in front of the data) when the partner's stack genuinely is not Snowflake and never will be — accepting the staleness, the egress and the pipeline you now own. ## The interview shape The question is usually posed as a scenario — "our biggest customer wants this dataset but they run on-prem Postgres" — and it tests two things. First, that you know the mechanism exists and is called a reader (managed) account, rather than reaching straight for a nightly S3 dump. Second, that you immediately name the billing inversion and the controls that follow from it. A candidate who describes reader accounts as "just like a consumer account" has missed the only thing about them that will ever appear in a postmortem.

  • What guardrails would you put on a reader account before handing over the credentials?
    A small warehouse with a short auto-suspend, a resource monitor with a hard suspend limit rather than a notification-only trigger, a role carrying only the imported privileges required, secure views instead of base tables, a network policy limiting logins to the partner's IP ranges, and MFA on the admin user.
  • When would you push the partner to get their own Snowflake account instead?
    As soon as their usage is material or their count grows. Their own account moves the compute bill and the day-to-day administration to them, lets them join your data to theirs, and removes an account you would otherwise operate. Reader accounts are an onboarding ramp; keeping dozens of them is an operational and financial liability.

It is a guest badge you print and pay for: the visitor gets through the door and uses your facilities, and every coffee they drink appears on your invoice.

saying these in an interview costs you the question

  • Says the partner is billed for compute in a reader account
  • Thinks the partner can load their own data into it
  • Reaches straight for a nightly file export instead
  • Treats reader accounts as a permanent solution at scale
  • Hands over credentials with no resource monitor or network policy

context

resolving links…