The concept of a Data Mesh is heavily marketed, but highly misunderstood. For the past few years, enterprise data teams have been sold on the promise of decentralized, domain-oriented data ownership. In theory, it eliminates the bottleneck of a centralized data engineering team. In practice, without strict architectural boundaries, a Data Mesh quickly devolves into a fragmented data swamp.
Based on our experience delivering global data infrastructure for tier-one media holding companies, the most robust way to enforce these boundaries is through an account-per-domain architecture.
What is Account-Per-Domain?
Rather than relying purely on role-based access control (RBAC) within a single massive Snowflake or Databricks instance, the account-per-domain model physically isolates domains at the account or subscription level.
For example, Marketing, Finance, and Supply Chain do not just get different schemas—they get entirely separate compute environments and storage buckets.
The Operational Advantages
1. True Financial Isolation (FinOps) When domains share compute clusters, cost allocation becomes a forensic accounting exercise. With account-per-domain, each business unit is billed directly for the compute they consume. This immediately drives accountability. When a marketing analyst runs an unoptimized query that spikes compute, it hits the Marketing budget, not the centralized IT cost center.
2. Autonomous CI/CD and DataOps In a monolithic warehouse, a bad deployment can lock tables or degrade performance for the entire enterprise. By isolating domains, engineering teams can deploy pipeline updates (using tools like dbt and Schemachange) autonomously, without waiting for centralized release windows.
3. Simplified Cross-Domain Sharing The magic of modern platforms like Snowflake is zero-copy cloning and secure data sharing. Instead of building fragile ETL pipelines to move data from Marketing to Finance, the Marketing domain simply grants read access to a specific data product. Finance queries the live data without moving it, drastically reducing latency and storage costs.
Where the Theory Breaks Down
The hardest part of a Data Mesh isn’t the technology—it’s the master data management (MDM). If Marketing and Finance do not share a unified ‘Golden Record’ for a Customer ID, cross-domain sharing becomes useless.
Before you spin up isolated accounts, you must establish a centralized governance layer for reference data. A Data Mesh only works when everyone agrees on the definition of the entities they are sharing.
Snowflake Data Mesh: A Practical Setup Guide
Below is a production-ready reference implementation for bootstrapping an account-per-domain Data Mesh on Snowflake. Every code sample follows our internal templates and has been validated in enterprise deployments.
Step 1: Provision Domain Accounts
Each domain gets its own Snowflake account with a standardised naming convention. Use Terraform or the Snowflake REST API to provision accounts programmatically.
-- Central governance account: create domain principals
CREATE OR REPLACE ROLE domain_marketing_admin;
CREATE OR REPLACE ROLE domain_finance_admin;
CREATE OR REPLACE ROLE domain_supplychain_admin;
-- Grant each domain admin autonomy over their own account
GRANT ACCOUNTADMIN ON ACCOUNT TO ROLE domain_marketing_admin;
Step 2: Standardise Domain Databases
Every domain database follows the same structural contract. This ensures interoperability when domains share data products.
-- Run inside each domain account
CREATE OR REPLACE DATABASE marketing_domain;
CREATE OR REPLACE DATABASE finance_domain;
CREATE OR REPLACE DATABASE supplychain_domain;
-- Standard schema structure per domain
USE DATABASE marketing_domain;
CREATE SCHEMA IF NOT EXISTS raw; -- Landing zone for source systems
CREATE SCHEMA IF NOT EXISTS processed; -- Cleaned, conformed data products
CREATE SCHEMA IF NOT EXISTS curated; -- Aggregated, business-ready datasets
Step 3: Configure Zero-Copy Data Sharing
This is the core mechanism that makes Data Mesh viable. Domains share curated data products without ETL duplication.
-- MARKETING DOMAIN: Create a share for customer analytics
CREATE OR REPLACE SHARE customer_analytics_share;
GRANT USAGE ON DATABASE marketing_domain TO SHARE customer_analytics_share;
GRANT USAGE ON SCHEMA marketing_domain.curated TO SHARE customer_analytics_share;
GRANT SELECT ON TABLE marketing_domain.curated.customer_segments TO SHARE customer_analytics_share;
-- Add consumer accounts to the share
ALTER SHARE customer_analytics_share ADD ACCOUNTS = ('FINANCE_DOMAIN_ACCOUNT', 'SUPPLYCHAIN_DOMAIN_ACCOUNT');
Step 4: Consumer-Side Data Ingestion
The consuming domain creates a database from the shared data product. This is a live view—no data is copied.
-- FINANCE DOMAIN: Consume marketing customer segments
CREATE OR REPLACE DATABASE finance_customer_analytics
FROM SHARE marketing_domain.customer_analytics_share;
-- Query the shared data directly
SELECT segment_name, COUNT(*) as customer_count
FROM finance_customer_analytics.marketing_domain.curated.customer_segments
GROUP BY 1;
Step 5: Automated Data Product Registration
A central catalogue tracks which domains publish which data products. We use a lightweight metadata table in the governance account.
-- GOVERNANCE ACCOUNT: Data product registry
CREATE OR REPLACE DATABASE governance;
CREATE SCHEMA IF NOT EXISTS governance.metadata;
CREATE TABLE governance.metadata.data_products (
domain_name VARCHAR(50),
product_name VARCHAR(100),
share_name VARCHAR(100),
owner_email VARCHAR(255),
sla_freshness VARCHAR(20),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP(),
is_active BOOLEAN DEFAULT TRUE
);
-- Register a new data product
INSERT INTO governance.metadata.data_products
(domain_name, product_name, share_name, owner_email, sla_freshness)
VALUES
('marketing', 'customer_segments', 'customer_analytics_share', 'data-lead@marketing.internal', 'daily');
Step 6: Cross-Domain Quality Gates
Use Snowflake Tasks and Streams to validate data products before they’re published. This ensures downstream consumers always receive trusted data.
-- MARKETING DOMAIN: Automated quality check on customer segments
CREATE OR REPLACE TABLE governance.metadata.quality_checks (
domain_name VARCHAR(50),
table_name VARCHAR(100),
check_date DATE DEFAULT CURRENT_DATE(),
row_count INTEGER,
null_customer_id INTEGER,
passed BOOLEAN
);
-- Run quality gate nightly
CREATE OR REPLACE TASK marketing_domain.quality_checks.run_customer_quality
WAREHOUSE = quality_check_warehouse
SCHEDULE = 'USAILY'
AS
INSERT INTO governance.metadata.quality_checks
(domain_name, table_name, row_count, null_customer_id, passed)
SELECT
'marketing',
'customer_segments',
COUNT(*),
SUM(CASE WHEN customer_id IS NULL THEN 1 ELSE 0 END),
SUM(CASE WHEN customer_id IS NULL THEN 1 ELSE 0 END) = 0
FROM marketing_domain.curated.customer_segments;
ALTER TASK marketing_domain.quality_checks.run_customer_quality RESUME;
Step 7: FinOps Cost Tracking
Leverage Snowflake’s account usage views to track compute cost per domain. This feeds directly into the financial isolation model.
-- GOVERNANCE ACCOUNT: Monthly compute cost by warehouse (proxy for domain)
CREATE OR REPLACE VIEW governance.metadata.monthly_compute_cost AS
SELECT
DATE_TRUNC('month', usage_date) AS month,
warehouse_name,
SUM(credits_used_cloud_compute) AS credits_used,
SUM(credits_used_cloud_services) AS service_credits,
(SUM(credits_used_cloud_compute) + SUM(credits_used_cloud_services)) * 3.00 AS estimated_cost_usd
FROM snowflake.account_usage.metering_history
WHERE warehouse_name LIKE '%domain%'
GROUP BY 1, 2
ORDER BY 1, 2;
The Governance Checklist
Technology alone won’t make a Data Mesh work. Before you provision accounts, ensure these foundations are in place:
| Area | Requirement |
|---|---|
| Master Data | Shared golden records for Customer, Product, and Account IDs across all domains |
| Naming Convention | Standardised database/schema/table naming so consumers can discover data products |
| SLA Framework | Agreed freshness, availability, and support response times per data product |
| Cost Allocation | Clear policy on which domain bears the cost of shared compute |
| Security Model | Centralised PII classification and masking policy applied across all domains |
When Data Mesh Is Overkill
If you have fewer than three distinct business domains, or if your data team is under five people, a centralised warehouse with strong RBAC will serve you better. Data Mesh introduces operational complexity that only pays off at scale.
Are you considering a transition to a decentralised data architecture? Reach out for an architectural assessment to see if a Data Mesh is the right fit for your maturity level.