Snowflake Data Sharing for APAC Retail Group Analytics: A Step-by-Step Guide

Quick Answer: Snowflake data sharing for APAC retail group analytics uses zero-copy secure shares within the same cloud region and database replication across regions. Create separate accounts per jurisdiction, apply secure views with entity-level row filtering for governance, and replicate only across region boundaries to minimize costs.

What Success Looks Like Before We Start

Picture this: your Singapore head office pulls up a Sigma Computing dashboard at 9 AM. It shows yesterday's sell-through rates across 47 stores in Australia, 12 in Indonesia, and 23 in Singapore — all refreshed overnight, all governed by each country's data residency rules, and none of it required a single CSV export or data pipeline to duplicate. Your regional CFO in Sydney sees the same metrics, filtered to AU entities only, without ever requesting access from the SG data team.

Related reading: AI-Augmented Demand Forecasting APAC Retail: Benchmark Data Across Verticals

Related reading: React Native App Performance Benchmarks Across APAC Markets: 2026 Field Data

That's what Snowflake data sharing for APAC retail group analytics makes possible. No data copying. No ETL jobs moving terabytes between regions. No storage duplication costs that balloon as your store count grows.

Related reading: Digital Operations Maturity Model for APAC Retailers: A 5-Stage Benchmark

Last year, we helped a Hong Kong-based retail conglomerate with operations across SG, AU, and ID unify their BI reporting using exactly this architecture. The project took 8 weeks from architecture sign-off to production dashboards. Their monthly cross-border data transfer costs dropped by 62%, and their reporting latency went from "someone emails a spreadsheet on Tuesday" to near-real-time.

This tutorial walks through the exact steps to replicate that setup. We'll cover the Snowflake data sharing architecture for multi-region APAC retail, cross-border governance, and the specific SQL and configuration needed to get it running.

Prerequisites

Before starting, make sure you have the following in place:

Snowflake Accounts

• Separate Snowflake accounts per region — at minimum, one in ap-southeast-1 (Singapore) for SG/ID operations and one in ap-southeast-2 (Sydney) for AU operations. Snowflake's secure data sharing works zero-copy within the same cloud region, but cross-region sharing requires database replication, which we'll configure.
• Business Critical edition or higher on all accounts. This is non-negotiable for cross-region replication and the governance features (dynamic data masking, row access policies) you'll need for multi-entity compliance.
• ACCOUNTADMIN or SECURITYADMIN role access on each account for the initial setup.

Data Architecture

• A centralized data warehouse schema (we use a medallion architecture: RAW → STAGING → ANALYTICS) with clean, entity-tagged tables. Each row in your analytics layer should carry a country_code or entity_id column.
• dbt models already producing your analytics-ready tables, or equivalent transformation logic. Our reference implementation uses dbt-core 1.7 with the dbt-snowflake adapter.

Tooling

• SnowSQL CLI (v1.2.28+) or Snowsight worksheet access
• A BI tool that supports Snowflake native connectivity — we used Sigma Computing, but Tableau, Looker, or Power BI all work
• Familiarity with Snowflake roles, warehouses, and database objects

Governance Prep

• A documented data classification policy per entity. Indonesia's Government Regulation No. 71 of 2019 on electronic systems and Australia's Privacy Act 1988 impose different requirements on what PII can leave the jurisdiction. You need to know which columns require masking before sharing.

Step 1: Design the Multi-Region Account Topology

Snowflake's data sharing has a critical architectural constraint: shares are zero-copy only within the same cloud region and cloud provider. Cross-region sharing requires database replication, which does incur storage and data transfer costs.

For a typical SG-AU-ID retail group, we recommend this topology:

Account Layout

• Primary account (SG): ap-southeast-1 on AWS — hosts the master ANALYTICS database, all dbt transformations, and the golden source of truth
• Secondary account (AU): ap-southeast-2 on AWS — receives a replicated subset of ANALYTICS, hosts AU-specific shares
• ID operations: Consumed via the SG account (same AWS region ap-southeast-1) using direct secure sharing — no replication needed

This minimises replication to a single SG→AU link. According to Snowflake's documentation, cross-region replication latency for databases under 500 GB typically runs under 15 minutes for incremental refreshes.

1-- Run on the PRIMARY account (SG, ap-southeast-1)
2-- Enable replication for the ANALYTICS database
3ALTER DATABASE ANALYTICS ENABLE REPLICATION TO ACCOUNTS 
4  my_org.au_retail_account;  -- your AU account identifier

Verify with:

1SHOW REPLICATION DATABASES;

You should see ANALYTICS listed with is_primary = true and your AU account as an allowed replication target.

Step 2: Configure Database Replication to the AU Account

On the AU account, create the replica database:

1-- Run on the AU account (ap-southeast-2)
2CREATE DATABASE ANALYTICS_REPLICA
3  AS REPLICA OF my_org.sg_retail_account.ANALYTICS;

Now set up the replication schedule. For retail analytics, overnight batch is usually sufficient — your POS data lands in the raw layer by midnight local time, dbt runs complete by 2 AM, and the replicated data is available in AU by 3 AM AEST.

1-- Run on the AU account
2ALTER DATABASE ANALYTICS_REPLICA REFRESH;
3
4-- To automate, create a task that triggers refresh
5CREATE OR REPLACE TASK refresh_analytics_replica
6  WAREHOUSE = ETL_WH_XS
7  SCHEDULE = 'USING CRON 0 17 * * * UTC'  -- 3 AM AEST (UTC+10)
8AS
9  ALTER DATABASE ANALYTICS_REPLICA REFRESH;
10
11ALTER TASK refresh_analytics_replica RESUME;

Monitor replication lag with:

1SELECT * FROM TABLE(INFORMATION_SCHEMA.DATABASE_REPLICATION_USAGE_HISTORY(
2  DATE_RANGE_START => DATEADD('day', -7, CURRENT_TIMESTAMP()),
3  DATE_RANGE_END => CURRENT_TIMESTAMP()
4));

A note on costs: Snowflake charges for cross-region data transfer. Based on AWS pricing as of Q1 2025, SG-to-Sydney transfer runs approximately $0.09/GB (per AWS data transfer pricing documentation). For a typical mid-size retailer with 50-100 GB of analytics data, the incremental daily replication (usually 2-5 GB of changed data) costs roughly $5-15/month. Compare that to running duplicate ETL pipelines or maintaining separate data warehouses — we measured a 62% cost reduction for our client against their previous multi-region Redshift setup.

Step 3: Create Secure Shares with Row-Level Governance

This is where the architecture becomes specific to multi-entity retail groups. You don't want the AU team seeing Indonesian customer PII, and the ID team shouldn't access Australian financial data.

Create the Share on the SG Account (for ID consumers)

1-- Run on SG account
2CREATE OR REPLACE SHARE sg_id_retail_share
3  COMMENT = 'Analytics share for Indonesia retail entity';
4
5-- Grant usage on the database and schema
6GRANT USAGE ON DATABASE ANALYTICS TO SHARE sg_id_retail_share;
7GRANT USAGE ON SCHEMA ANALYTICS.MARTS TO SHARE sg_id_retail_share;

Apply Row Access Policies Before Sharing

Don't share the raw tables. Share views that enforce entity-level filtering:

1-- Create a secure view that filters to ID entity only
2CREATE OR REPLACE SECURE VIEW ANALYTICS.MARTS.V_DAILY_SALES_ID AS
3SELECT
4    sale_date,
5    store_id,
6    store_name,
7    product_sku,
8    product_name,
9    quantity_sold,
10    revenue_local_currency,
11    revenue_usd,
12    -- Mask customer PII per Indonesian regulation
13    MD5(customer_email) AS customer_email_hash,
14    LEFT(customer_phone, 4) || '****' AS customer_phone_masked
15FROM ANALYTICS.MARTS.FACT_DAILY_SALES
16WHERE country_code = 'ID';

Grant the view to the share:

1GRANT SELECT ON VIEW ANALYTICS.MARTS.V_DAILY_SALES_ID 
2  TO SHARE sg_id_retail_share;
3
4-- Add the ID consumer account to the share
5ALTER SHARE sg_id_retail_share ADD ACCOUNTS = my_org.id_retail_account;

Create the Share on the AU Account (for AU consumers)

Same pattern, but on the AU replica:

1-- Run on AU account
2CREATE OR REPLACE SHARE au_retail_share
3  COMMENT = 'Analytics share for AU retail entity teams';
4
5CREATE OR REPLACE SECURE VIEW ANALYTICS_REPLICA.MARTS.V_DAILY_SALES_AU AS
6SELECT
7    sale_date,
8    store_id,
9    store_name,
10    product_sku,
11    product_name,
12    quantity_sold,
13    revenue_local_currency,
14    revenue_usd,
15    -- AU Privacy Act allows hashed emails for analytics
16    SHA2(customer_email, 256) AS customer_email_hash
17FROM ANALYTICS_REPLICA.MARTS.FACT_DAILY_SALES
18WHERE country_code = 'AU';
19
20GRANT USAGE ON DATABASE ANALYTICS_REPLICA TO SHARE au_retail_share;
21GRANT USAGE ON SCHEMA ANALYTICS_REPLICA.MARTS TO SHARE au_retail_share;
22GRANT SELECT ON VIEW ANALYTICS_REPLICA.MARTS.V_DAILY_SALES_AU 
23  TO SHARE au_retail_share;

Step 4: Set Up Consumer Access with Reader Accounts (If Needed)

If your ID entity doesn't have its own Snowflake account (common for smaller regional offices), you can create a Reader Account — a managed Snowflake account that you administer and pay for:

1-- Run on SG account (the provider)
2CREATE MANAGED ACCOUNT id_reader_account
3  ADMIN_NAME = 'id_analytics_admin',
4  ADMIN_PASSWORD = '<strong-password>',
5  TYPE = READER,
6  COMMENT = 'Reader account for Indonesia retail entity';

Capture the account locator from the output, then:

1ALTER SHARE sg_id_retail_share ADD ACCOUNTS = <id_reader_account_locator>;

The trade-off here is cost allocation. With a reader account, compute costs for the ID team's queries hit your SG account's bill. For a small team running 5-10 dashboard queries per day, expect roughly $50-80/month on an XS warehouse with auto-suspend at 60 seconds. For larger teams, push for a full Snowflake account so costs are attributed correctly.

Step 5: Build a Unified Group-Level Analytics View

The head office in SG typically needs a consolidated view across all entities. Here's where Snowflake data sharing for APAC retail group analytics delivers the most value — a single query that spans all markets without any data movement:

1-- Run on SG account (head office)
2-- This view unions local SG data with shared/replicated views
3CREATE OR REPLACE VIEW ANALYTICS.MARTS.V_GROUP_DAILY_SALES AS
4
5-- SG data (local, zero-copy)
6SELECT
7    'SG' AS market,
8    sale_date,
9    store_id,
10    store_name,
11    product_sku,
12    product_name,
13    quantity_sold,
14    revenue_usd
15FROM ANALYTICS.MARTS.FACT_DAILY_SALES
16WHERE country_code = 'SG'
17
18UNION ALL
19
20-- ID data (local, zero-copy — same region)
21SELECT
22    'ID' AS market,
23    sale_date,
24    store_id,
25    store_name,
26    product_sku,
27    product_name,
28    quantity_sold,
29    revenue_usd
30FROM ANALYTICS.MARTS.FACT_DAILY_SALES
31WHERE country_code = 'ID'
32
33UNION ALL
34
35-- AU data (replicated from AU account)
36SELECT
37    'AU' AS market,
38    sale_date,
39    store_id,
40    store_name,
41    product_sku,
42    product_name,
43    quantity_sold,
44    revenue_usd
45FROM ANALYTICS.MARTS.FACT_DAILY_SALES
46WHERE country_code = 'AU';

This single view powers the group dashboard. No ETL. No storage duplication for the SG and ID data. The AU data is replicated once daily — the only incremental cost.

Step 6: Connect BI and Validate Latency

Connect your BI tool to the SG account's V_GROUP_DAILY_SALES view. In Sigma Computing (our tool of choice for this project), the connection setup is straightforward:

1# Sigma Computing connection config
2connection_type: snowflake
3account: my_org-sg_retail_account.ap-southeast-1
4warehouse: BI_WH_MEDIUM
5database: ANALYTICS
6schema: MARTS
7role: BI_ANALYST_ROLE
8authentication: oauth  # recommended over password for production

Latency Benchmarks to Expect

From our implementation, here are the query performance numbers on a MEDIUM warehouse:

• SG/ID data (local, zero-copy): 2-4 seconds for a 90-day aggregation across 59 stores
• AU data (replicated): identical performance — once replicated, the data is local to the SG account
• Group-level union query: 5-8 seconds for the full 82-store, 90-day rollup

For comparison, the client's previous architecture (Redshift in SG + BigQuery in AU + manual CSV consolidation) took 3-4 hours for the same group-level view, and that was on a good day.

Related reading: Adobe Commerce vs Shopify Plus in 2026: Enterprise Comparison

Related reading: n8n vs Zapier vs Make: Enterprise Automation Comparison for 2026

Step 7: Implement Monitoring and Cost Controls

Snowflake data sharing costs can surprise you if you don't monitor proactively. Set up resource monitors and usage tracking:

1-- Create a resource monitor for replication costs
2CREATE OR REPLACE RESOURCE MONITOR replication_monitor
3  WITH CREDIT_QUOTA = 100  -- monthly credits
4  FREQUENCY = MONTHLY
5  START_TIMESTAMP = IMMEDIATELY
6  TRIGGERS
7    ON 75 PERCENT DO NOTIFY
8    ON 90 PERCENT DO NOTIFY
9    ON 100 PERCENT DO SUSPEND;
10
11-- Track replication costs over time
12SELECT 
13    database_name,
14    DATE_TRUNC('day', start_time) AS replication_date,
15    SUM(credits_used) AS credits_used,
16    SUM(bytes_transferred) / POWER(1024, 3) AS gb_transferred
17FROM TABLE(INFORMATION_SCHEMA.DATABASE_REPLICATION_USAGE_HISTORY(
18    DATE_RANGE_START => DATEADD('month', -1, CURRENT_TIMESTAMP())))
19GROUP BY 1, 2
20ORDER BY 2 DESC;

According to Snowflake's 2024 pricing guide, replication credits are charged at your account's standard credit rate. On Business Critical edition in AP regions, that's approximately $4.00/credit (Snowflake pricing page, Q1 2025). Budget accordingly — our client's monthly replication cost settled at around $180/month after the initial full sync.

Handling the Snowflake Data Sharing Limitations You'll Actually Hit

Let's be honest about the constraints. These are the limitations we encountered in production:

Cross-Cloud Sharing Isn't Zero-Copy

If your AU entity runs on Azure and SG runs on AWS, you need Snowflake's listing feature (formerly Data Exchange) or cross-cloud auto-fulfillment, which Snowflake introduced in 2023. It works, but adds latency and cost. Our strong recommendation: standardise on a single cloud provider across all accounts. We chose AWS because of its broader APAC region coverage — 8 regions across Asia-Pacific versus Azure's 6, per cloud provider documentation as of early 2025.

Share Objects Are Read-Only

Consumer accounts can query shared data but cannot modify it. This seems obvious, but it creates friction when local teams want to enrich shared data with local context. The workaround: create local databases that join shared views with local tables.

1-- On the ID reader account
2CREATE DATABASE LOCAL_ENRICHMENT;
3CREATE TABLE LOCAL_ENRICHMENT.PUBLIC.ID_STORE_ATTRIBUTES (
4    store_id VARCHAR,
5    mall_name VARCHAR,
6    lease_expiry_date DATE,
7    local_manager VARCHAR
8);
9
10-- Join shared data with local enrichment
11SELECT 
12    s.*, 
13    e.mall_name, 
14    e.local_manager
15FROM shared_sg_analytics.MARTS.V_DAILY_SALES_ID s
16LEFT JOIN LOCAL_ENRICHMENT.PUBLIC.ID_STORE_ATTRIBUTES e 
17    ON s.store_id = e.store_id;

Time Travel and Cloning Don't Work on Shared Objects

Consumers cannot use Snowflake's time travel or clone features on shared data. If AU needs point-in-time recovery on shared analytics data, they need to build that into their own local snapshots.

The Branch8 Implementation: What We Learned in 8 Weeks

When we built this architecture for a Hong Kong-based retail group with 82 stores across SG, AU, and ID, the technical setup was actually the easy part — about 2 weeks of work using dbt-core 1.7, Snowflake Business Critical, and Fivetran for source ingestion.

The remaining 6 weeks were spent on governance. Getting legal teams across three jurisdictions to agree on what data could cross borders, what needed masking, and who owned the access control policies — that was the real project. We ended up creating a shared Notion database (later migrated to Atlan for proper data cataloguing) that mapped every column in the analytics layer to a classification level and a jurisdictional rule.

The payoff: monthly cross-border data costs dropped from approximately $2,400/month (multi-region Redshift + BigQuery + manual transfers) to around $900/month (Snowflake replication + compute). More importantly, the group CFO could finally see consolidated daily sales by 9 AM Hong Kong time, instead of waiting for a weekly email.

What to Do Next

If you've followed these steps, you now have a working Snowflake data sharing setup across your APAC retail entities. Here's what to tackle next:

• Add dynamic data masking policies using Snowflake's native masking policy objects instead of the manual column-level masking in secure views. This scales better as your schema evolves.
• Implement Snowflake's governance features (available on Business Critical+) for access history tracking and object-level tagging. This feeds directly into audit requirements under PDPA (Singapore) and Indonesia's PDP Law.
• Evaluate Snowflake Marketplace listings if you want to enrich your retail analytics with third-party data — foot traffic data from SafeGraph or weather data from Weather Source can improve demand forecasting models.
• Set up automated testing with dbt tests and Snowflake's SYSTEM$STREAM_HAS_DATA function to validate that replicated data hasn't drifted.

A frank assessment of who this approach is not for: if your retail group has fewer than 3 market entities, or your total data volume is under 10 GB, the overhead of multi-account Snowflake with replication doesn't justify itself. You'd be better served by a single Snowflake account with role-based access control and row access policies. The multi-account architecture starts paying for itself when you have genuine cross-border governance requirements and data volumes where duplication costs become material.

If you're evaluating this architecture for your APAC retail group, reach out to Branch8. We've deployed this pattern across multiple retail and F&B clients and can scope the effort for your specific market footprint in under a week.

Sources

• Snowflake Documentation — About Secure Data Sharing: https://docs.snowflake.com/en/user-guide/data-sharing-intro
• Snowflake Documentation — Database Replication and Failover: https://docs.snowflake.com/en/user-guide/db-replication-intro
• Snowflake Documentation — Resource Monitors: https://docs.snowflake.com/en/user-guide/resource-monitors
• AWS Data Transfer Pricing: https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer
• Indonesia Government Regulation No. 71 of 2019 on Electronic Systems: https://jdih.kominfo.go.id/produk_hukum/view/id/695/t/peraturan+pemerintah+nomor+71+tahun+2019
• Australia Privacy Act 1988 — OAIC Overview: https://www.oaic.gov.au/privacy/the-privacy-act
• Snowflake Pricing Documentation: https://www.snowflake.com/en/data-cloud/pricing/
• Sigma Computing — Snowflake Connection Setup: https://help.sigmacomputing.com/docs/connect-to-snowflake