TL;DR
Snowflake data sharing lets one Snowflake account give another account live, read-only access to selected tables and views without copying or moving the data. The provider creates a share, grants objects to it, and adds the consumer’s account. The consumer then creates a database from that share and queries it like any other database. A direct share suits known accounts in the same region, while a listing covers other regions, the Marketplace and paid data. The provider pays for storage, each consumer pays for the compute its own queries use, and the provider also pays for any reader accounts it creates. Govern it with secure views, least-privilege grants and regular access reviews, because every grant goes live the moment you run it.
Key Takeaways Snowflake data sharing gives other accounts live, read-only access to your objects, and no data gets copied for same-region consumers. Direct shares work only inside one region, so listings handle cross-region, cross-cloud, Marketplace and paid sharing. Providers set up a share with a handful of SQL statements, and consumers mount it with one CREATE DATABASE command. Reader accounts let partners without Snowflake query your data, but the provider pays every credit they burn. Secure views, database roles and account-level filters decide what each consumer sees, so build them before the first grant. Direct shares give providers no usage telemetry, so teams that need consumption data should publish through listings. Watch on YouTube
Snowflake Summit 2026 Explained: CoWork, CoCo, Cortex Sense & Horizon
A walkthrough of where Snowflake is taking its platform in 2026, including Horizon, the layer that governs discovery and sharing across accounts.
A Distributor, a Supplier and a Table Nobody Copied Picture a regional grocery distributor that exports last week’s store sales to a CSV file every Monday at 6 a.m. Its largest snack supplier picks the file up from an SFTP folder and loads it by mid-morning.
By then, the numbers are already days old. Then someone renames a column, and the supplier’s loader fails quietly for three weeks before anyone notices.
Now picture the same two companies on Snowflake. The distributor’s data engineer runs a handful of SQL statements, and the supplier’s analyst opens a database that points straight at the distributor’s own table. No file moves, nothing lands on a server, and new rows appear for the supplier as soon as the distributor loads them.
The supplier pays only for the warehouse that runs its queries. Meanwhile, the distributor keeps one copy of the data and full control over who sees it. Revoking access later takes one command.
The SQL takes minutes. The decisions around it take longer and matter more, such as which sharing method to use, what each partner may see and who pays for which queries.
What Is Snowflake Data Sharing and How Does It Work? Snowflake data sharing is the platform’s native way to give another Snowflake account read access to objects in your account. Snowflake calls the feature Secure Data Sharing , and it works between any two full accounts, including two accounts inside your own company. The account that shares is the provider, and the account that receives is the consumer.
The mechanism sits in Snowflake’s services layer instead of the storage layer. Because Snowflake separates storage from compute, as our Snowflake data warehouse guide explains, a consumer’s warehouse can read the provider’s micro-partitions directly. So the provider grants access, and the consumer brings its own compute to the same bytes.
What Goes Inside a Share A share is a named Snowflake object that holds a set of grants. The provider adds privileges on a database, its schemas and specific objects, and then lists the consumer accounts allowed to use them. You can grant privileges to the share directly, or bundle them in a database role and grant that role to the share.
The list of shareable objects keeps growing. It covers tables, dynamic tables, external tables, Iceberg tables, secure views, secure materialized views , semantic views, user-defined functions and Cortex Search services. Most enterprise shares, however, still come down to a few curated tables and secure views.
Why Nothing Gets Copied Snowflake states it plainly. With Secure Data Sharing, no data gets copied or transferred between accounts, and shared data takes no storage in the consumer account. That makes sharing different from zero-copy cloning , which creates a new, writable object inside your own account.
Freshness follows from the same design. When the provider updates a shared table, every consumer sees the change on its next query, since there is only one table. In the opening story, the supplier stops asking for Monday’s file because Monday’s file no longer exists.
What Consumers Can and Cannot Do Consumers can query, join and aggregate shared objects just like their own tables. They cannot insert, update, delete or create objects inside the imported database, because every shared object is read-only. A consumer can also create only one database per share.
Several features stop at the share boundary. A consumer cannot clone an imported database, cannot use Time Travel on it and cannot replicate it to another region.
Teams that need history or a writable copy have to build it on their side. Usually that means a scheduled CREATE TABLE AS SELECT into their own database.
Direct Share, Listing or Marketplace: Which Sharing Method Fits? Snowflake gives providers four ways to share, and the right one depends on where consumers live and how much control you need. Snowflake’s sharing overview lists them as direct shares, listings, data exchanges and clean rooms, and listings come in private, public Marketplace and organizational forms.
Clean rooms restrict which queries a partner may run, so they solve a different problem. Our Snowflake data clean rooms article covers them on their own.
Direct Shares for Known Accounts in Your Region A direct share is the simplest form. You create the share in SQL or Snowsight, grant objects, and add named accounts in the same Snowflake region. It suits the distributor and supplier from the opening story, since both run in the same region and know each other’s account identifiers.
Direct shares stay lean on purpose, and that is mostly a strength. They carry no descriptions, no sample queries and no usage reporting, and they cannot cross regions. Once a share outgrows those limits, Snowflake lets you convert a direct share with active consumers into a listing.
Private Listings for Named Partners A listing wraps a share in a data product. It adds a title, description, sample queries and terms, and it gives the provider consumption metrics.
A private listing is the natural next step once the supplier from the opening story adds an account outside the distributor’s region. It goes to named accounts, and those accounts can sit in any region or cloud. That works because Cross-Cloud Auto-Fulfillment replicates the product for them.
Snowflake Marketplace for Public Data Products Public listings appear on the Snowflake Marketplace, where any Snowflake customer can find them. According to Snowflake’s listings documentation , a provider can offer free access, a limited trial lasting 1 to 90 days, or paid access. Paid listings are only available to consumers and providers in specific regions, so check eligibility before you plan a revenue line around them.
Organizational Listings and the Internal Marketplace Large companies often run dozens of Snowflake accounts across business units. Organizational listings publish data products to an Internal Marketplace that only your organization can see.
The Internal Marketplace follows the same idea as a data mesh , where domains publish governed products. It also pairs well with discovery features in Snowflake Horizon Catalog .
Data Exchange for a Managed Group A data exchange is a private hub that you request from Snowflake. You invite members and decide who may publish and who may consume. Most new programs reach for private listings instead, but exchanges still make sense for industry groups or partner networks with a central administrator.
Table 1: Snowflake data sharing methods compared
Factor Direct share Private listing Marketplace listing Organizational listing Who can consume Named accounts in your region Named accounts in any region Any Snowflake customer Accounts in your organization Cross-region and cross-cloud No (needs replication) Supported through auto-fulfillment Through auto-fulfillment Within the organization Descriptions and sample queries No Yes Shown publicly Part of the internal catalog Charge for access No Paid listings, where eligible Paid listings, where eligible No (pricing plans and offers are not available) Consumer usage metrics None Consumption reports Listing telemetry and consumption Access history in the organization account Recommended for A few known partners or sister accounts in one region Partners across regions, or any share that needs usage data Public or paid data products Internal data products across business units
Start with a direct share when consumers are few, known and local. Move to a listing as soon as you need another region, a public audience or proof of who uses the data.
Kanerika Service
Plan Your Snowflake Sharing Model With Kanerika
Kanerika’s Snowflake team designs shares, listings, secure views and database roles that fit your partners, regions and contracts.
Explore Snowflake Services How to Set Up Snowflake Data Sharing as a Provider The provider side takes six steps, and only two of them involve the share itself. Preparation and testing fill the rest, and that is where most production problems start. Each example below follows the distributor sharing weekly sell-through data with its supplier.
Step 1: Decide What to Share and With Whom List the exact tables or views the consumer needs, and check each one for personal or contract-restricted fields. Then collect the consumer’s account identifier in the organization.account format and confirm its region. If the region differs from yours, skip ahead to the cross-region section before you build anything.
Plan for freshness at the same time. Many providers land partner-facing data through Snowpipe continuous loading , so the shared table fills within minutes of each file arriving. Consumers then see those rows on their next query.
Step 2: Create the Share Creating a share needs the ACCOUNTADMIN role or a role with the global CREATE SHARE privilege. Most teams grant that privilege to a dedicated data-sharing admin role so they avoid running daily work as ACCOUNTADMIN. The share starts empty, so this step carries no risk on its own.
USE ROLE data_sharing_admin; -- holds the global CREATE SHARE privilege
CREATE SHARE supplier_sales_share
COMMENT = 'Weekly sell-through for the snack supplier';Step 3: Grant Access to the Objects A share needs USAGE on the database and schema, then SELECT on each object. The safest pattern exposes a secure view instead of the raw table, because the view decides which rows and columns leave your account. Here, a mapping table links each supplier ID to the consumer account that may see it. Store each consumer’s account locator in that table, since CURRENT_ACCOUNT() returns the locator, not the organization.account name used in ALTER SHARE.
CREATE OR REPLACE SECURE VIEW sales_db.shared.sell_through_v AS
SELECT s.store_id, s.sku, s.sale_date, s.units_sold
FROM sales_db.core.daily_sales s
JOIN sales_db.core.supplier_access a
ON s.supplier_id = a.supplier_id
WHERE a.snowflake_account = CURRENT_ACCOUNT();
GRANT USAGE ON DATABASE sales_db TO SHARE supplier_sales_share;
GRANT USAGE ON SCHEMA sales_db.shared TO SHARE supplier_sales_share;
GRANT SELECT ON VIEW sales_db.shared.sell_through_v TO SHARE supplier_sales_share;For larger shares, put the object grants in a database role and grant that role to the share. Consumers can then map the shared role to their own roles, which lets one share serve analysts and finance users differently. One catch is easy to miss, since a shared database role does not support future grants.
Step 4: Add Consumer Accounts Adding an account makes the share visible to that consumer right away. You can add many accounts to the same share, and each one sees only the rows the secure view allows.
ALTER SHARE supplier_sales_share
ADD ACCOUNTS = snackorg.snack_prod;
SHOW GRANTS TO SHARE supplier_sales_share;Step 5: Test What the Consumer Will See Snowflake lets a provider impersonate a consumer account for secure views. Set the SIMULATED_DATA_SHARING_CONSUMER session parameter to the consumer’s account and query the view. If the row count looks wrong here, it will look wrong to the partner too.
ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = snack_prod;
SELECT COUNT(*), MIN(sale_date), MAX(sale_date)
FROM sales_db.shared.sell_through_v;
ALTER SESSION UNSET SIMULATED_DATA_SHARING_CONSUMER;Step 6: Keep the Share Current Updates to shared objects flow to consumers immediately. New objects do not, and that includes any table you drop and recreate under the same name. Snowflake treats a recreated table as a brand-new object, so you must grant it to the share again or the consumer’s query fails.
This trips up teams whose pipelines rebuild tables with CREATE OR REPLACE every night. Either switch those jobs to MERGE or TRUNCATE and INSERT, or add the GRANT statement to the end of the job. Our guide to Snowflake stored procedures shows how to wrap both steps in one call.
How Consumers Access Shared Data in Snowflake The consumer side is shorter, but it has its own permission model. You need ACCOUNTADMIN or a role with the IMPORT SHARE and CREATE DATABASE privileges to mount a share. After that, regular role-based access control decides which of your users can query it.
Find the Incoming Share and Create a Database From It SHOW SHARES lists every inbound share, and DESC SHARE shows the objects inside one. Once you confirm the contents, a single CREATE DATABASE statement mounts it as a read-only database.
SHOW SHARES;
DESC SHARE distorg.dist_prod.supplier_sales_share;
CREATE DATABASE distributor_sales
FROM SHARE distorg.dist_prod.supplier_sales_share;
GRANT IMPORTED PRIVILEGES ON DATABASE distributor_sales TO ROLE analyst_role;Grant Access and Join Shared Data With Your Own Tables IMPORTED PRIVILEGES gives a role access to everything in the share. If the provider shared database roles instead, grant those roles to your account roles for finer control. Then the shared view behaves like local data, so the supplier can join it to its own product master without an ETL step.
SELECT p.brand, SUM(s.units_sold) AS units_last_7_days
FROM distributor_sales.shared.sell_through_v s
JOIN snack_db.core.products p ON p.sku = s.sku
WHERE s.sale_date >= DATEADD(day, -7, CURRENT_DATE())
GROUP BY p.brand
ORDER BY units_last_7_days DESC;Consumers who want change history should build it themselves. Snowflake advises against sharing secure views on streams. Instead, consumers should create their own streams on shared tables once the provider enables change tracking.
Our Snowflake streams guide explains how those offsets work. When the provider allows resharing, a consumer can reshare a direct share, but only inside its own organization. The reshare must go through a secure view in the consumer’s own database.
Reader Accounts: Sharing With Partners Who Have No Snowflake Account Secure Data Sharing only works between Snowflake accounts, which leaves out partners who never signed up. Reader accounts fill that gap. The provider creates a small managed account, shares data to it, and hands the partner a login.
CREATE MANAGED ACCOUNT bakery_partner_reader
ADMIN_NAME = bakery_admin,
ADMIN_PASSWORD = '<strong-password>',
TYPE = READER,
COMMENT = 'Read-only access for a partner without Snowflake';
SHOW MANAGED ACCOUNTS; -- returns the locator to add to the shareThe convenience comes with strings attached. According to Snowflake’s reader account documentation , the provider owns the account and pays for every credit its warehouses use.
Those warehouses can also consume an unlimited number of credits unless you cap them. So create a resource monitor inside each reader account before you hand over the login.
Reader accounts also have hard limits. They can only read data from the provider that created them, and they cannot load or modify data. They also cannot refresh dynamic tables .
A provider can create 75 reader accounts by default, and provisioning can take up to five minutes. If a partner plans to query heavily, ask them to open their own account, because then they pay for their own compute.
Sharing Across Regions and Cloud Platforms Suppose the supplier opens a second Snowflake account in another region for its European team. A direct share cannot reach it, because direct shares stop at the region boundary. Snowflake gives providers two routes across, and they differ mainly in how much plumbing you own.
The first route is a listing with Cross-Cloud Auto-Fulfillment. Snowflake replicates the data product to each region where a consumer requests it, and you choose a refresh pattern. The auto-fulfillment documentation describes interval refreshes from one minute to eight days, fixed schedules, and on-demand triggers through SYSTEM$TRIGGER_LISTING_REFRESH once an upstream load finishes.
The second route is manual replication. First you create an account in the target region and replicate the database and share there in a replication group.
After the first refresh, you add local consumers to the secondary share. Snowflake’s cross-region sharing guide notes that you need one copy per region, not one per consumer.
-- In the source account
CREATE REPLICATION GROUP sales_share_rg
OBJECT_TYPES = DATABASES, SHARES
ALLOWED_DATABASES = sales_db
ALLOWED_SHARES = supplier_sales_share
ALLOWED_ACCOUNTS = distorg.dist_eu;
-- In the target account (distorg.dist_eu)
CREATE REPLICATION GROUP sales_share_rg AS REPLICA OF distorg.dist_prod.sales_share_rg;
ALTER REPLICATION GROUP sales_share_rg REFRESH;
ALTER SHARE supplier_sales_share ADD ACCOUNTS = snackorg.snack_eu;Replication works at the database level, so replicating a large database to share a thin slice wastes money. Snowflake’s own example copies only the needed rows into a smaller database with streams and scheduled Snowflake tasks , then replicates that database. Before any of this, confirm that your contracts and regulators allow the data to sit in the target country.
Sharing beyond Snowflake is a separate topic. Open table formats such as Iceberg tables can reach other engines.
Our Snowflake to Fabric data sharing article covers that path for Microsoft Fabric. Teams comparing platforms can also read how Databricks Delta Sharing handles the same job.
On-Demand Webinar
Snowflake + Fabric: Expert Strategies for Interoperability, Data Sharing & Migration
A recorded session on moving and sharing data between Snowflake and Microsoft Fabric, for teams whose consumers sit outside Snowflake.
Watch the Webinar → Security and Governance Controls for Shared Data A share is a live door into your account, so governance has to come before the first grant. The good news is that every control below runs on features you already use for internal access. The difference is that mistakes now reach another company.
Share the Minimum, Through Dedicated Roles Least privilege means giving each party the minimum access needed to do the job, as NIST defines it . For sharing, that means one share per audience and a dedicated admin role with CREATE SHARE.
Broad database-level grants have no place in a share when a single view will do. Our data access governance guide covers the wider review process.
Filter Rows and Columns With Secure Views Secure views hide their definition and the underlying tables from consumers. When combined with CURRENT_ACCOUNT(), as in the provider example above, one view can serve many partners while each sees only its own rows. Snowflake also recommends clustering keys on the large base tables behind shared views, which our Snowflake clustering guide explains.
Policies, Tags and Database Roles Row access and masking policies that the provider sets stay in force when consumers query a share. Policy logic needs care, though.
If a condition checks CURRENT_ROLE or CURRENT_USER, Snowflake returns NULL for those functions in the consumer account. That happens because the provider does not control the consumer’s users.
Snowflake’s row access policy guide suggests CURRENT_ACCOUNT() in the condition instead. Another option is IS_DATABASE_ROLE_IN_SESSION, paired with a shared database role that the consumer maps to its own roles. Test each policy with the simulated consumer parameter, and see our roundup of data masking tools for options beyond native policies.
Residency, Contracts and Business Critical Accounts Legal terms often matter more than SQL. Check that each data set may leave your company and that the contract covers onward use. Also confirm the consumer’s region is allowed, since rules such as GDPR Chapter V limit transfers of personal data outside the EU.
Accounts on the Business Critical edition need Snowflake to enable sharing with lower editions. Even then, Snowflake advises against sending sensitive data to them.
Revocation and Offboarding Access ends the moment you remove an account from a share or revoke an object grant. Write that step into every partner offboarding checklist, and review active shares at least quarterly. Our broader Snowflake security article and the Snowflake data governance guide cover the account-wide controls that sit around sharing.
Checklist
Data Governance Checklist
Use Kanerika’s checklist to confirm ownership, classification, access reviews and audit steps before you open data to partners.
Get the Checklist → What Snowflake Data Sharing Costs Providers and Consumers Costs come from the storage, compute and transfer around a share, and they land on different parties depending on the method. Snowflake’s introduction is clear that consumers pay only for the compute they use, while providers keep paying for storage.
Table 2: Who pays for what in Snowflake data sharing
Cost item Direct share Listing with auto-fulfillment Reader account Storage of shared data Provider The provider, plus storage in each remote region Provider Query compute Consumer Consumer Provider Replication compute and egress None in one region Provider None in one region Data product fee None Consumer, if the listing is paid Set by your own contract
Auto-fulfillment is where budgets drift. Snowflake’s auto-fulfillment cost guide lists compute to copy and sync data, storage in each remote region, and egress between regions. Each extra region and each faster refresh raises the bill, so match the refresh interval to how often the source data really changes.
To estimate before launch, size each cost driver on its own. Remote storage grows with your shared data volume and the number of remote regions. Replication compute grows with how much data changes between refreshes and how often you refresh. Then add the reader-account compute you will carry. Track consumer and reader spend as its own line, and use our Snowflake cost optimization tactics for warehouse sizing.
How to Monitor and Audit Your Shares Monitoring starts with three commands that show what is shared and with whom. Run them on a schedule and compare the output with your approved access list, because drift is easy to miss across dozens of shares.
SHOW SHARES; -- outbound and inbound shares
DESC SHARE supplier_sales_share; -- objects inside the share
SHOW GRANTS TO SHARE supplier_sales_share; -- privileges granted
-- Listing consumption, latency up to 2 days
SELECT event_date, listing_display_name, consumer_account_name, jobs
FROM SNOWFLAKE.DATA_SHARING_USAGE.LISTING_CONSUMPTION_DAILY
WHERE event_date >= DATEADD(day, -30, CURRENT_DATE())
ORDER BY event_date DESC;One gap surprises many providers. A direct share gives you no view of how consumers use the data, because their queries run on their own compute. Listings fix that, since the DATA_SHARING_USAGE views report consumption and access history with up to two days of latency and one year of retention.
For reader accounts, the provider sees the compute directly, so review it alongside your Snowflake query history . Pair those checks with data lineage so you know which upstream change will reach which partner.
Common Snowflake Data Sharing Mistakes Most incidents trace back to a short list of habits. Each one is easy to prevent once you know to look for it.
Picking a direct share for a remote consumer. Confirm the consumer’s region first, then choose a listing or replication.Sharing raw tables. Expose secure views with only the columns and rows a partner needs.Recreating shared tables nightly. CREATE OR REPLACE drops the object from the share until you grant it again.Forgetting consumer roles. The consumer must grant IMPORTED PRIVILEGES or shared database roles before anyone can query.Leaving reader accounts uncapped. Add a resource monitor, since the provider pays every credit.Skipping offboarding. Remove accounts from shares when a contract ends, and log the change.How Kanerika Helps Enterprises Share Data on Snowflake Kanerika is a Snowflake Select Tier Partner , and our data teams treat sharing as a governance project that happens to use SQL. Engagements usually run in five stages.
First we assess who needs which data, in which region and under which contract terms. Then we design the method mix, the secure views and the database roles before anyone creates a share.
The build stage creates shares and listings as code, so every grant lives in version control and gets re-applied after each pipeline run. We wire fresh data in with streams, tasks or Snowpipe, and we add resource monitors to every reader account.
After launch, governance and enablement take over, with quarterly access reviews, cost reports per consumer and a short runbook for partner onboarding and offboarding. Our Snowflake consulting services and data governance services pages describe the full scope.
Classify First, Share Second The governance half matters most, and our work for a global bank shows why, even though that project ran on Microsoft Purview rather than Snowflake. Kanerika classified personal data across SAP, core banking and lakehouse systems. Then the team set data sharing rules based on data type and sensitivity.
The bank reported zero data breaches, 100% adherence to compliance regulations and a 72% improvement in data classification accuracy. The same order of work, classify first and share second, applies to any Snowflake sharing program.
Our data engineering services team builds grant re-application, reader-account resource monitors and offboarding steps into the pipeline from day one.
Case Study
Zero Breaches and 100% Compliance for a Global Bank
Kanerika classified sensitive data and set sharing rules by data type and sensitivity, lifting classification accuracy by 72%.
Read the Case Study → Wrapping Up Snowflake data sharing replaces file exports with live, read-only access to one copy of the data. A provider creates a share, grants a secure view and adds an account, and the consumer mounts it as a database in a single statement. Use direct shares for known partners in your region, and listings once you cross regions, publish publicly or need usage data.
Budget for consumer compute on their side and reader accounts on yours, and keep auto-fulfillment refreshes in line with real change rates. Above all, govern every share as a live door, because that is exactly what it is.
Frequently Asked Questions
What is Snowflake data sharing? Snowflake data sharing is a native feature that lets one Snowflake account give another account live, read-only access to selected databases, tables, secure views and functions. The provider grants objects to a named share and adds consumer accounts. Consumers create a database from the share and query it with their own warehouses, while no data gets copied.
Does Snowflake data sharing copy or move data? No, not within a region. Consumers query the provider’s stored data through Snowflake’s services layer, so the shared data takes no storage in the consumer account. Cross-region sharing is different, because listings with auto-fulfillment or manual replication create one copy of the data product in each remote region, and the provider pays for that copy.
What is a share in Snowflake? A share is a named Snowflake object that holds the privileges needed to share a database. The provider grants USAGE on a database and schema and SELECT on tables or secure views, either directly or through a database role. The provider then adds consumer accounts, and it can revoke any grant or account at any time.
How do you share data between two Snowflake accounts? The provider runs CREATE SHARE, grants USAGE on the database and schema, grants SELECT on the objects, and adds the consumer with ALTER SHARE ADD ACCOUNTS. The consumer runs CREATE DATABASE FROM SHARE and grants IMPORTED PRIVILEGES to its roles. Both accounts must sit in the same region for a direct share to work.
What is the difference between Snowflake data sharing and Snowflake Marketplace? Data sharing is the underlying capability that grants another account access to your objects. The Marketplace is a public catalog where providers publish listings built on top of shares. A listing adds descriptions, sample queries, terms, usage metrics and optional pricing, and it can reach consumers in any region through auto-fulfillment.
Is Snowflake data sharing free? Partly. Consumers pay nothing to store shared data, but they pay for the warehouse compute their queries use. Providers keep paying for storage and pay for all compute in reader accounts they create. Cross-region listings add replication compute, remote storage and egress charges for the provider, and paid listings add a product fee for consumers.
What is a reader account in Snowflake? A reader account is a managed account that a provider creates for a partner with no Snowflake account of its own. The partner can query data shared by that provider only and cannot load or change data. The provider pays every credit the reader account uses, so a resource monitor on its warehouses is essential.
Can you share Snowflake data across regions and clouds? Yes, but not with a direct share, which works only inside one region. Use a private or public listing with Cross-Cloud Auto-Fulfillment, which replicates the data product to each region where consumers request it. Alternatively, replicate the database and share to an account in the target region with a replication group.
What happens when you add a new table to a shared database? A new table does not appear for consumers automatically. The provider must grant SELECT on it to the share. The same rule applies when a pipeline drops and recreates a table under the same name, because Snowflake treats the recreated table as a new object. Updates to existing shared tables, however, appear immediately.
How do you control and revoke access to shared data in Snowflake? Expose secure views instead of raw tables, filter rows with CURRENT_ACCOUNT, and use shared database roles for finer control. Masking and row access policies stay in force for consumers. To revoke access, remove the consumer account from the share or revoke the object grant, and the change takes effect immediately.
Can a consumer reshare data from a Snowflake direct share? Only inside its own organization, and only when the provider allows resharing. The consumer creates a secure view over the imported data in its own database, then grants that view to a new share. Resharing a direct share to accounts outside the organization, or to another region, is not supported, so listings handle those cases.
