Network Policies, Private Connectivity & Transactions/Locking

Secure network-level access to Snowflake and understand its transactional concurrency model.

Network policies restrict which IP addresses can connect to a Snowflake account (or specific users) using allowed/blocked IP lists, providing a network-layer security control independent of RBAC — even a user with valid credentials and correct role grants cannot connect from a disallowed IP address. Policies can be applied account-wide or scoped to individual users for more granular control (e.g., service accounts restricted to a CI/CD pipeline's IP range).

A network policy is like a building's front desk that only lets in visitors from a pre-approved list of addresses, regardless of whether they have a valid ID; private connectivity is a dedicated private tunnel between two buildings that never uses the public street; and Snowflake's transaction model is like a busy shared kitchen where chefs working on different dishes (rows/partitions) never get in each other's way, but two chefs both grabbing the same pot (same table/partition) at once will have one of them wait their turn.

Key Concepts

For organizations wanting to avoid any traffic over the public internet entirely, Snowflake supports private connectivity options: AWS PrivateLink, Azure Private Link, and Google Cloud Private Service Connect, which route traffic between a customer's private cloud network and Snowflake entirely within the cloud provider's private backbone, never traversing the public internet — a common requirement in regulated industries.

private connectivityAWS PrivateLinkAzure Private LinkGoogle Cloud Private Service Connect

Separately, Snowflake's transaction and locking model differs from traditional row-level-locking databases: Snowflake uses a form of statement-level snapshot isolation for most DML, and because micro-partitions are immutable, most concurrent operations on different rows/partitions don't block each other at all. However, concurrent DML statements attempting to modify the same table (in some cases the same micro-partitions) can still encounter transaction conflicts, which Snowflake resolves by having the second transaction wait or fail with a transaction abort if it detects a conflicting concurrent write, rather than allowing the kind of fine-grained row-level locking seen in OLTP databases — a reflection of Snowflake's OLAP-oriented design.

statement-level snapshot isolationsame tabletransaction and locking modeltransaction abort

Explicit transactions use standard BEGIN/COMMIT/ROLLBACK syntax, and autocommit is enabled by default for individual statements, meaning most single DML statements don't require explicit transaction blocks unless multiple statements must succeed or fail atomically together.

BEGINCOMMITROLLBACK