Secure Data Sharing for Enrichment: Imported Databases, Tables and Views

1.How Secure Data Sharing delivers enrichment data

Every Marketplace listing, private listing and organizational listing is delivered through the same mechanism: Secure Data Sharing. A provider creates a share, grants it access to selected objects (databases, tables, dynamic tables, secure views, UDFs and more), and adds consumer accounts. The consumer then creates a database from that share. That database is an imported database, and its access is managed with the same role-based access control as any other object.

No data moves between accounts. Sharing runs through Snowflake's services layer and metadata store, so imported data takes no consumer storage and access is near-instant. The only consumer cost is the virtual warehouse compute used to query it. Because the share points at the provider's live objects, new objects and updates to existing objects are immediately available to every consumer, and the provider can revoke access at any time. The trade-off is that all shared objects are read-only: you can't modify or delete them, and you can't add or change their data. Data can be offered in four ways, compared in the table below. One more account type is worth knowing: reader accounts, created by a provider for consumers who aren't Snowflake customers. A reader account can consume data only from the provider that created it, and it can't load data or run DML.

Sources1

2.The Internal Marketplace and organizational listings

Enrichment data doesn't always come from a third party. Often the most useful correlating data set belongs to another team in your company, such as a customer master owned by CRM or product data owned by supply chain. Snowflake's answer is the Internal Marketplace: a curated, secure space for sharing data inside your organization. Providers publish organizational listings to it, using Provider Studio in Snowsight or the API. Consumers can find internal data products without searching through externally shared listings on the public Marketplace. Access is controlled by account targeting and role-based access control, so only authorized users can reach the data. The goal is consistency: when teams draw on the same published data sets, there's less redundancy and fewer competing versions of the truth.

Organizational listings can also be queried directly. In government regions, for example, consumers can't search the Internal Marketplace in Snowsight. Instead they open the listing URL from the provider, or access the listing in SQL through its Uniform Listing Locator (ULL), as in the sample below. Auto-fulfillment, however, is triggered only when the listing is obtained through Snowsight, not through SQL.

SHOW AVAILABLE LISTINGS; SELECT * FROM <ull>.<schema>.<view>

Sources2

3.Creating the imported database and granting access

When you select Get on a listing, Snowsight creates the imported database for you. A share received directly can be mounted in Snowsight (Data sharing » External sharing, Shared with you tab, Ready to Get section) or in SQL. Before you mount it, DESC SHARE lists the share's objects with a <DB> prefix, which means no database has been created from the share in your account yet. The SQL form is a CREATE DATABASE with a sharing-specific clause, where provider_account is the providing account and share_name is the share.

CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>

CREATE DATABASE <name> FROM  ?  <provider_account>.<share_name>

A share can be consumed only once per account, so you create a single database from each share and give other roles access to it. Users get access to a share's objects when you grant the IMPORTED PRIVILEGES privilege on the imported database to their roles, either in Snowsight (Catalog » Explorer, Privileges) or with a GRANT ... TO ROLE statement. Not every role can make that grant: it must own the imported database or hold the global MANAGE GRANTS privilege.

Sources3

4.Creating tables and views over shared data

Imported objects are read-only, so you can't add a column to the provider's table or write your own data into it. Enrichment therefore happens in objects you create in your own database, which reference the imported one. A view is the lightest option. Its select_statement can be any valid SELECT over one or more source tables, including a join between your sales table and a shared weather table. The view always reflects the provider's latest updates, because it stores only the query. The syntax below shows the main view options. SECURE makes the view secure; by default a view is not. TEMPORARY limits the view to the session that created it. If you later want to share an enriched result onward, you can always create a new secure view before you create the outgoing share.

CREATE OR ALTER [ SECURE ] [ { [ { LOCAL | GLOBAL } ] TEMP | TEMPORARY | VOLATILE } ] [ RECURSIVE ] VIEW <name>
  [ ( <column_list> ) ]
  [ CHANGE_TRACKING =  { TRUE | FALSE } ]
  [ COMMENT = '<string_literal>' ]
  AS <select_statement>

CREATE OR ALTER [  ?  ] [ { [ { LOCAL | GLOBAL } ] TEMP | TEMPORARY | VOLATILE } ] [ RECURSIVE ] VIEW <name>

When you need the enriched result stored, for example as a stable snapshot or to avoid repeating an expensive join, create a table. CREATE TABLE has several variants, and the one that fits enrichment is CREATE TABLE … AS SELECT (CTAS), which creates a table already populated with the result of a query. The other variants answer different needs, as the table below shows.

Sources43

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.After importing a shared table, you can add your own enrichment columns or rows to it.Why is that wrong?

   Every object shared between accounts is read-only. Enrich by creating your own views or tables that reference the imported data.

   Covered in How Secure Data Sharing delivers enrichment data

2. 2.Each team can create its own database from the same share in one account.Why is that wrong?

   A share can be consumed only once per account. Create one imported database and grant IMPORTED PRIVILEGES on it to the roles that need it.

   Covered in Creating the imported database and granting access

3. 3.A view is secure by default, so it can be shared onward safely without the SECURE keyword.Why is that wrong?

   Views aren't secure unless you specify SECURE. The documented default is a non-secure view.

   Covered in Creating tables and views over shared data

Practise it for real

Find a free listing that correlates with your data, mount it, give an analyst role access, and expose the enriched result as a view.

1. 1.Run SHOW AVAILABLE LISTINGS, then browse Marketplace » Snowflake Marketplace and check a candidate listing's data dictionary and Data Preview.

   Why: You confirm that the listing has a column you can join on before you install it.

   You should see: A free listing with a table that shares a key (such as a date or region) with one of your tables.

2. 2.Using ACCOUNTADMIN or a role with CREATE DATABASE and IMPORT SHARE, select Get, set a database name and select Get again.

   Why: Getting the listing creates the read-only imported database from the provider's share.

   You should see: A new database in your account, plus an option to open a worksheet with an example query.

3. 3.As the database owner, grant IMPORTED PRIVILEGES on the imported database to your analyst role (Catalog » Explorer, or a GRANT ... TO ROLE statement).

   Why: Access to a share's objects is granted through IMPORTED PRIVILEGES, not through grants on individual objects.

   You should see: The analyst role can query the imported tables.

4. 4.In a database you own, run CREATE VIEW with an AS <select_statement> that joins your table to the imported table.

   Why: Imported objects are read-only, so the enrichment has to live in an object you create.

   You should see: A view that returns your rows plus the provider's columns and reflects the provider's updates.