One Platform for All Your Data. Architected to Scale Without the Overhead.

Virtual warehouse configuration for each workload class the independently-scalable compute clusters that are the primary lever for both performance and cost management in Snowflake. Warehouse sizing: XS (1 node) through 6XL (512 nodes), where each size tier doubles the credit consumption and the parallel query capacity. Sizing guidance: ETL loading warehouses (Medium to XL, sized for throughput, set to auto-suspend after 5 minutes of inactivity because load jobs are batch-oriented), BI query warehouses (Small to Large with multi-cluster enabled on Enterprise edition, auto-suspend after 1 minute because interactive users drive intermittent load), and data science warehouses (Large to XL, auto-suspend after 10 minutes for longer-running exploratory queries). Multi-cluster configuration: the Enterprise edition feature that adds additional clusters to a warehouse when query queue depth exceeds threshold eliminating query queuing during peak load without paying for the additional clusters during off-peak.

Snowflake database and schema hierarchy design that reflects both the data's logical organisation and the access control model. Medallion architecture in Snowflake: RAW database (source data landed without transformation staging schemas named after each source system), TRANSFORMED database (cleaned, standardised, business-rule-applied data in a consistent schema), and ANALYTICS database (subject-area schemas containing the dimensional models and aggregated tables that BI tools and analysts query). Access control hierarchy: database-level grants for environment separation, schema-level grants for data domain access boundaries, and table/view-level grants for fine-grained row and column access. Naming conventions: consistent, predictable schema and object naming that enables automated grant management and makes the data catalogue browsable by analysts who did not build the environment.

Resource monitor design the Snowflake-native mechanism for preventing credit consumption from exceeding defined thresholds before the anomaly appears on the monthly invoice. Resource monitors at the account level (hard ceiling on total account credit consumption per period), warehouse level (threshold and action for each virtual warehouse), and the notification-only monitors that alert when a team's warehouse approaches its budget threshold without suspending the warehouse. Credit budget allocation: assigning credit budgets to each team's or workload's virtual warehouse that reflects the expected monthly consumption, with notification at 80% and suspension at 100% of the budget. Snowflake Credit Grants: monitoring credit use across on-demand and pre-purchased credit pools to ensure pre-purchased credits are consumed before expiry.

Snowflake network security configuration controlling which clients can connect to the Snowflake account and through which network paths. Network policies: IP allowlist restricting Snowflake account access to specific IP ranges (corporate office egress IPs, VPN gateway IPs, ETL tool IP ranges, BI tool IP ranges). AWS PrivateLink, Azure Private Link, and GCP Private Service Connect for private endpoint connectivity that routes traffic through the cloud provider's private network rather than the public internet required for Business Critical edition customers with data residency and network isolation requirements. Private Link architecture: the Snowflake account is given a private endpoint within the customer's VPC/VNet, and all application, ETL, and BI connectivity routes through this private endpoint without traversing the public internet. Tri-Secret Secure for Business Critical: the customer's own AWS KMS / Azure Key Vault key required for Snowflake to decrypt customer data enabling data access revocation by revoking the encryption key.

Snowflake Time Travel and Fail-Safe for data recovery and audit two of the platform's most valuable operational features that require no infrastructure setup and impose minimal performance overhead. Time Travel (Standard: 1 day, Enterprise: up to 90 days): querying any table, schema, or database as it existed at any point within the Time Travel retention window using AT or BEFORE clauses enabling recovery from accidental DELETE or UPDATE statements, comparison of current data to a historical snapshot, and the cloning of historical data states for investigation. CLONE: creating a zero-copy clone of a table, schema, or database at a specific historical moment the clone shares the source micro-partitions until either is modified, enabling instant environment refresh for development (clone production to development in seconds with no storage cost until data diverges). Fail-Safe (7 days after Time Travel expires): Snowflake's internal recovery mechanism for catastrophic data loss accessible via Snowflake support, not directly by customers.

Snowflake multi-cloud and multi-region deployment for organisations with data residency requirements, cloud provider diversification strategies, or the need to bring analytics compute close to data consumers in different geographies. Snowflake Business Continuity: cross-region replication of databases from a primary account to one or more secondary accounts (different region on the same cloud, or different cloud provider) with near-real-time lag, enabling failover of the analytics workload to a secondary region in the event of a regional outage. Cross-region data sharing: sharing data between Snowflake accounts in different regions via Snowflake's replication and sharing infrastructure, enabling a manufacturer with production data in Mumbai to share data with a customer analytics team in Singapore without exposing the raw ERP data or moving it outside the primary data residency boundary.

dbt project architecture following the Medallion (staging / intermediate / marts) layer convention: staging models (one per source table renaming columns to consistent business terminology, casting data types, applying light cleaning materialised as views for zero storage cost), intermediate models (joining and enriching staging data across source systems, applying business rules materialised as ephemeral or as views depending on reuse), and mart models (the dimensional or wide table aggregations that BI tools and analysts query materialised as tables or incremental models for query performance). Ref() function for dependency tracking: dbt builds models in dependency order and ensures that upstream models are built and tested before downstream models, automatically constructing the correct build sequence from the DAG of ref() calls between models.

Incremental materialisation for large tables where full table recreation on every dbt run is prohibitively slow or expensive dbt inserts or upserts only the new and changed rows since the last run rather than recreating the entire table. Incremental model design patterns in Snowflake: append-only incremental (new rows only, no updates simplest, fastest, uses COPY INTO or INSERT), unique key merge (upsert based on a unique key using Snowflake's MERGE INTO correct for fact tables where rows can be retroactively updated), and the delete+insert strategy for partitioned incremental models where Snowflake's MERGE is slower than deleting and reinserting the affected partitions. Lookback window configuration: querying the last N days of source data on each run (not just the most recent records) to handle late-arriving records that arrive after their event date.

dbt testing framework for data quality assurance: generic tests (not_null, unique, accepted_values, relationships configured in schema.yml and run automatically after each model build), singular tests (custom SQL test files that assert specific business logic conditions "total revenue in fact_orders matches total revenue in fact_payments", "no orders have a ship date earlier than the order date"), and dbt-expectations (the dbt extension of Great Expectations providing 50+ additional test types including expect_column_values_to_be_between, expect_column_unique_value_count_to_be_between, expect_table_row_count_to_be_between). Test results surfaced in dbt Cloud's run history and in Snowflake via INFORMATION_SCHEMA for custom monitoring. Test severity levels: WARN for soft data quality alerts that log but do not fail the pipeline, ERROR for hard quality failures that halt the pipeline until the issue is resolved.

dbt documentation site: auto-generated from the combination of dbt model names, schema.yml descriptions (model-level and column-level descriptions written in Markdown), and the DAG of ref() and source() calls that dbt traces automatically. The dbt docs site shows: the DAG lineage graph (visually showing which models depend on which sources and other models), model descriptions (what this model represents, how it is built, what it is used for), column descriptions (what each column contains, its data type, the tests applied to it), and test results (which tests passed and failed on the most recent run). Source freshness tests: dbt checks that source tables have been updated recently enough (configurable per source — the orders table should have a row with a loaded_at timestamp within the last 2 hours) before allowing downstream models to run, preventing stale data propagation.

CI/CD pipeline for dbt model deployment applying software development release practices to analytics transformations. Development workflow: dbt Cloud IDE or VS Code with dbt extension for model development, Git-based branching (feature branch per change, pull request for peer review), and slim CI (dbt's feature that rebuilds only the models modified in a pull request plus their downstream dependencies, using a clone of the production environment, rather than rebuilding the entire project for every PR making CI fast and cheap). GitHub Actions or GitLab CI integration: linting SQL with SQLFluff (enforcing consistent SQL style across the team), running dbt compile and dbt test on the PR's changed models, and deploying to production via dbt Cloud job or CLI on merge to main. Blue-green deployment for large Snowflake schema changes: building the new schema in parallel, validating, and swapping the BI tool's connection rather than running a potentially disruptive in-place schema migration.

dbt macros (Jinja-templated SQL functions) for reusable transformation logic eliminating the copy-paste repetition that makes raw SQL projects hard to maintain. Macro use cases: surrogate key generation (the generate_surrogate_key macro from dbt-utils hashes the business key columns into a consistent integer surrogate key), date spine generation (creating a complete sequence of dates for left-joining to fact tables to ensure every date appears in time-series reports regardless of whether any transactions occurred), pivot and unpivot operations, and the conditional column generation that adapts model SQL to the current target environment. dbt packages: dbt-utils (50+ utility macros), dbt-expectations (data quality tests), dbt-audit-helper (comparing model outputs between environments), and dbt-date (comprehensive date manipulation macros). Package management via packages.yml with pinned version numbers for reproducible environments.

Snowflake Dynamic Data Masking (DDM) for column-level data protection that applies masking rules at query time based on the querying user's role without modifying the underlying data or requiring multiple copies of the table. DDM policy creation: a SQL function that returns the column value for authorised roles and a masked or null value for all other roles (CASE WHEN CURRENT_ROLE() IN ('ANALYST_PII', 'DPO') THEN CREDIT_CARD_NUMBER ELSE '****-****-****-' || RIGHT(CREDIT_CARD_NUMBER, 4) END). Policy assignment: the masking policy is assigned to a column in CREATE TABLE or via ALTER COLUMN from that point, every query against that column is masked for unauthorised users transparently. Masking policy types: full masking (NULL), partial masking (first 4 / last 4 of credit card), hash masking (deterministic but irreversible for join-compatible pseudonymisation), format-preserving masking (replacing sensitive values with realistic-looking fake values that preserve data format for testing environments), and conditional masking (different masking for different roles).

Snowflake Row Access Policies (RAP) for row-level data filtering that restricts which rows a user can see in a table based on their identity the Snowflake equivalent of row-level security in Power BI or Oracle Virtual Private Database. RAP policy design: a SQL function that returns TRUE for rows the current user is authorised to see and FALSE for rows that should be filtered out. Implementation patterns: region-based access (each regional manager sees only their region's rows a lookup table mapping username to authorised region codes, joined in the policy function), customer-level access (a B2B portal scenario where each customer account sees only their own transaction rows the policy function joins to a customer-user mapping table), and classification-level access (users with CONFIDENTIAL role see all rows; users without see only rows tagged as PUBLIC). A single RAP policy can be applied to multiple tables simultaneously enabling consistent access control across the data model without per-table repetition.

Snowflake Object Tags for attaching metadata to database objects (databases, schemas, tables, columns) the foundation for automated governance policy application based on data sensitivity classification. Tag creation and assignment: SENSITIVITY_LEVEL (PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED), DATA_DOMAIN (FINANCIAL / HEALTH / PII / OPERATIONAL), RETENTION_PERIOD, GDPR_APPLICABLE. Tag-based masking policies: instead of assigning a masking policy to each column individually, tag all PII columns with TAG('SENSITIVITY_LEVEL', 'PII') and apply a masking policy to the SENSITIVITY_LEVEL tag — the masking policy automatically applies to every future column tagged as PII without requiring a manual ALTER COLUMN for each. Snowflake Data Classification (Horizon): the automated PII detection that scans table contents and recommends sensitivity tags based on column name patterns and data patterns (credit card numbers, email addresses, phone numbers, SSN formats) accelerating the classification of large legacy schemas.

Snowflake Role-Based Access Control (RBAC) architecture the role hierarchy that determines which users can access which objects, perform which operations, and consume which virtual warehouses. Standard role design pattern: SYSADMIN (manages database objects), SECURITYADMIN (manages roles and grants), ACCOUNTADMIN (highest privilege restricted to DBA team with MFA enforcement), and custom functional roles (ANALYST_FINANCE, ANALYST_SALES, DATA_ENGINEER, BI_TOOL_SERVICE_ACCOUNT) with object-level USAGE, SELECT, and INSERT grants. Role hierarchy inheritance: child roles inherit parent role privileges (ANALYST_FINANCE is granted to ANALYST role which is granted to SYSADMIN the hierarchy that makes privilege management scalable). Service account roles for ETL tools and BI tools: dedicated functional roles with only the permissions each tool requires, rather than granting SYSADMIN to every service connection. Snowflake Privilege Hierarchy: USAGE on warehouse, USAGE on database, USAGE on schema, SELECT on table all four grants required for a role to query a table.

Snowflake ACCESS_HISTORY view for column-level data access auditing recording every query that accessed each column in the Snowflake account, which user ran it, from which role, at what time, and what base objects the query's data came from (tracing through views to the underlying tables). Compliance audit queries: "which users accessed the PII columns in the CUSTOMER table in the last 90 days?", "which queries accessed CONFIDENTIAL-tagged columns outside business hours?", "which service accounts accessed financial data tables?" all answerable from ACCESS_HISTORY without requiring a separate audit log system. QUERY_HISTORY for operational audit: execution time, credit consumption, queued time, error messages, and the SQL text of every query enabling anomaly detection (queries consuming abnormally high credits, queries running at unexpected hours) and the performance investigation that identifies which queries are driving the majority of credit consumption.

Snowflake data lineage via the ACCESS_HISTORY base_objects_accessed and direct_objects_accessed columns, which trace the data access chain from the base table columns through views and transformations to the final output answering "which downstream reports would be affected if this source table column changed?". Integration with enterprise data catalogues: Alation, Collibra, and Microsoft Purview connect to Snowflake via the Snowflake Metadata API to pull table schemas, column descriptions, usage statistics, and lineage into the catalogue providing business users with a searchable, governed data catalogue that includes Snowflake objects alongside data from other systems. Snowflake Open Catalog (Polaris Catalog) for Apache Iceberg integration enabling non-Snowflake engines (Apache Spark, Trino, Flink) to query Snowflake-managed Iceberg tables through an interoperable open catalog standard.