Stages: Internal and External

Analogy categoryAnalogies

A stage in Snowflake is simply a pointer to a location where data files are held for loading into tables or unloading out of them. Internal stages live inside Snowflake's own managed storage, while external stages point to a bucket or container you already own in AWS S3, Azure Blob Storage, or Google Cloud Storage, with Snowflake reading and writing files there using a storage integration or credentials rather than owning the storage itself.

🏏

Cricket analogy: Like the difference between a stadium's own dedicated nets (internal stage) and a nearby public ground a touring team books for extra practice (external stage) — both are usable practice space, but only one is owned by the home venue.

Types of Internal Stages

Snowflake automatically provisions three kinds of internal stages for every user and table: a user stage (referenced as @~) private to one user, a table stage (referenced as @%table_name) tied to a single table, and named stages you create explicitly with CREATE STAGE, which are the only kind that can be shared across multiple users or tables and support access via roles and grants. Named internal stages are generally preferred for pipelines because user and table stages cannot be renamed, shared, or altered with stage-level parameters.

🏏

Cricket analogy: Like a player's personal kit bag (user stage) that only they use, versus the team's shared dressing room locker for one specific match (table stage), versus the stadium's central equipment store that any authorized team can book (named stage).

External Stages and Storage Integrations

For an external stage, Snowflake needs credentials to read from and write to your cloud storage; the modern, recommended approach is a storage integration, which creates an IAM role trust relationship (on AWS) or equivalent identity binding (Azure, GCP) so Snowflake never has to hold your raw access keys directly. Once a storage integration exists, CREATE STAGE simply references it alongside the bucket URL and an optional file format, and any user with USAGE privilege on the stage can then run COPY INTO or LIST against it without ever seeing the underlying credentials.

🏏

Cricket analogy: Like a touring team getting a trusted access badge from a host stadium (storage integration) rather than being handed a master key — the badge lets them enter the specific gate (bucket) without ever holding the stadium's actual keys.

sql

-- Create a storage integration (AWS example, admin-only)
CREATE STORAGE INTEGRATION s3_int
  TYPE = EXTERNAL_STAGE
  STORAGE_PROVIDER = 'S3'
  ENABLED = TRUE
  STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/snowflake-role'
  STORAGE_ALLOWED_LOCATIONS = ('s3://raw-data-bucket/orders/');

-- Create an external stage using the integration
CREATE OR REPLACE STAGE sales.raw_stage
  URL = 's3://raw-data-bucket/orders/'
  STORAGE_INTEGRATION = s3_int
  FILE_FORMAT = (FORMAT_NAME = 'csv_standard');

-- List files currently visible in the stage
LIST @sales.raw_stage;

Choosing Between Internal and External

External stages are the natural choice when data already lives in a cloud data lake and multiple tools besides Snowflake need to read it, since the files remain in their original bucket under your existing lifecycle policies and IAM controls. Internal stages make sense for smaller, self-contained pipelines, ad-hoc file uploads via SnowSQL's PUT command, or when you want Snowflake to fully own the file lifecycle including automatic encryption and PURGE-based cleanup after a successful load.

🏏

Cricket analogy: Like a national board keeping a shared archive of match footage on a public ground multiple broadcasters film from (external stage), versus a single franchise keeping its own private highlight reel just for internal team review (internal stage).

Files in any Snowflake stage (internal or external) are automatically encrypted at rest, and internal stages additionally use client-side encryption during PUT uploads. This is separate from, and in addition to, any encryption already applied to files sitting in an external S3 or Azure bucket.

A stage is a pointer to files used for loading into or unloading out of Snowflake tables.
Internal stages live in Snowflake-managed storage; external stages point to your own S3, Azure Blob, or GCS location.
Every user and table automatically gets a private user stage (@~) and table stage (@%table_name).
Named stages, created explicitly, are the only kind that can be shared and granted to roles.
Storage integrations let Snowflake access external cloud storage via a trust relationship, without holding raw credentials.
External stages suit shared data lake locations; internal stages suit self-contained, Snowflake-owned pipelines.
LIST and PUT are used to inspect and upload files to a stage before running COPY INTO.