This feature enables the replication of objects from a source account to one or more target accounts in the same organization. Replicated objects in each target account are referred to as secondary objects and are replicas of the primary objects in the source account. Replication is supported across regions and across cloud platforms.
Region support for replication and failover/failback¶All Snowflake regions across Amazon Web Services, Google Cloud Platform, and Microsoft Azure support replication.
Customers can replicate across all regions within a region group. To replicate between regions in different region groups, (i.e. from a Snowflake commercial region to a Snowflake government or Virtual Private Snowflake region), please contact Snowflake Support.
Replication groups and failover groups¶A replication group is a defined collection of objects in a source account that are replicated as a unit to one or more target accounts. Replication groups provide read-only access for the replicated objects.
A failover group is a replication group that can also fail over. A secondary failover group in a target account provides read-only access for the replicated objects. When a secondary failover group is promoted to become the primary failover group, read-write access is available. Any target account specified in the list of allowed accounts in a failover group can be promoted to serve as the primary failover group.
Replication and failover groups provide point-in-time consistency for the objects on the target account. The objects that can be included in a replication or failover group are listed below in Replicated objects.
Replication feature / edition matrix¶Note that some replication features are only available for Business Critical Edition (or higher). The following table lists the availability of replication features for each Snowflake edition:
Feature
Standard
Enterprise
Business Critical
VPS
Database replication
✔
✔
✔
✔
Share replication
✔
✔
✔
✔
Replication Group
✔
✔
✔
✔
Account object (other than database and share) replication
✔
✔
Failover Group
✔
✔
Data protected with Tri-Secret Secure
✔
✔
✔
✔
Replicated objects¶This feature supports replicating the objects listed below. Database replication and share replication are available on all editions. Replication of all other objects is only available for Business Critical Edition (or higher). For details on feature availability, see the Replication feature / edition matrix.
Object
Type or Feature
Replicated
Notes
✔
Replication of some databases is not supported or might fail the refresh operation. For more information, see Current limitations of replication.
Security, API, Notification, Storage, External Access
✔
For additional caveats and details on the supported types, see Integration replication.
Requires Business Critical Edition (or higher).
✔
Requires Business Critical Edition (or higher).
✔
Requires Business Critical Edition (or higher).
Programmatic access tokens for users
✔
If users and roles are replicated, programmatic access tokens for users are replicated automatically.
✔
Resource monitor notifications for non-administrator users are replicated if you include users in the group, however account administrator notification settings are not replicated. For more information, see Replication of resource monitor email notification settings.
Requires Business Critical Edition (or higher).
✔
Includes account and database roles.
Includes privileges granted to roles, as well as roles granted to roles (i.e. hierarchies of roles).
If users and roles are replicated, roles granted to users are also replicated.
The REPLICATE and FAILOVER privileges are not replicated.
Requires Business Critical Edition (or higher).
✔
Replication of inbound shares (shares from providers) is not supported.
✔
Requires Business Critical Edition (or higher).
✔
Requires Business Critical Edition (or higher).
Database replication¶This feature supports replicating databases. A snapshot includes changes to the objects and data. If roles are replicated (in the same or different replication or failover group), the database refresh also synchronizes the privilege grants on the secondary database and the objects in the database (schemas, tables, views, etc.) to roles in the account. Refer to Grants for database objects for more details.
Replication of some databases is not supported or might fail the refresh operation. For more information, see Current limitations of replication.
Replicated database objects¶When a primary database is replicated, a snapshot of its database objects and data is transferred to the secondary database. However, some database objects are not replicated. The following table indicates which database objects are replicated to a secondary database.
For specific usage information about these objects, see Replication considerations.
Note
Objects that are not supported for replication are skipped during the refresh operation.
Object
Type or Feature
Replicated
Notes
Schemas
✔
By default, all schemas in replicated databases are replicated. If you use failover groups, you can choose which schemas within a database are replicated. For more information, see Schema-level replication for failover groups.
Tables
Permanent tables
✔
Transient tables
✔
Temporary tables
Automatic Clustering of clustered tables
✔
Dynamic tables
✔
For more information, see Replication and dynamic tables.
External tables
Hybrid tables
Apache Iceberg™ tables
Table constraints
✔
Except if a foreign key in the database references a primary/unique key in another database. .
Event tables
Sequences
✔
Views
Views
✔
If a view references any object in another database (e.g. table columns, other views, UDFs, or stages), . both databases must be replicated.
Materialized views
✔
Secure views
✔
Semantic views
File formats
✔
Stages
Stages
✔
Supported for replication and failover groups only. Not supported for database replication. . For more information, see Stage, pipe, and load history replication.
Temporary stages
Pipes
✔
Supported for replication and failover groups only. Not supported for database replication. . For more information, see Stage, pipe, and load history replication.
Stored procedures
✔
For more information, see Replication of stored procedures and user-defined functions (UDFs).
Streams
✔
For more information, see Replication and streams.
Tasks
✔
For more information, see Replication and tasks.
Data metric functions (DMFs)
Data Quality
✔
For more information, see Replication of data metric functions (DMFs).
UDFs
✔
For more information, see Replication of stored procedures and user-defined functions (UDFs).
Policies
Aggregation policies
✔
Authentication policies
✔
Column-level Security (masking)
✔
For masking, row access, and tag-based masking policies, see policy replication considerations.
Join policies
✔
Password policies
✔
Privacy policies
✔
For more information, see Privacy policies.
Projection policies
✔
Row access policies
✔
Session policies
✔
For session, password, and authentication policies, see replication and security policies.
Tag-based masking policies
✔
Tags
Object Tagging
✔
For tags, see Replication and tags.
Alerts
✔
Secrets
Secrets for External API Authentication
✔
You can replicate secrets by using a replication group and failover group. For additional details, see Replication and secrets.
Network rules
✔
For replication of network policies that use network rules, see Replicating network policies.
Class instances
CUSTOM_CLASSIFIER
✔
Replication is supported for instances of the CUSTOM_CLASSIFIER class. Instances of all other Snowflake classes are not replicated. For the full list of Snowflake classes, see Available classes.
Packages policies
Python UDF, UDTF, stored procedures
✔
If there is a packages policy set on the source account, in order to successfully replicate account objects, the database containing the packages policy must be replicated to the target account in the same or different replication or failover group. Otherwise, the refresh operation fails with a dangling references error.
Objects for machine learning workflows
Models
✔
For usage information, see Snowflake Model Registry.
Datasets
✔
For information about how replication works for Datasets, see Dataset replication.
Git repository clones
✔
For information about how replication works for Git repository clones, see Git repository replication. For usage information for Git repository clones, see Using a Git repository in Snowflake.
Database replication and encryption¶Snowflake protects metadata and data sets at rest and in transit between the source and target accounts. The account master key (AMK) encrypts the key hierarchy within the account as shown in the hierarchical key model. Snowflake encrypts replicated data in the target account using the account master key and the key hierarchy in the target account, regardless of whether you enable Tri-Secret Secure in the target account.
When you enable Tri-Secret Secure in the target account, Snowflake uses the composite master key and the corresponding key hierarchy in the target account to encrypt the data. Note that target accounts do not have Tri-Secret Secure enabled by default; you must enable this feature.
For more information about data encryption in Snowflake, see Understanding end-to-end encryption in Snowflake.
Integration replication¶Account replication supports the replication of integrations for the following features:
Security integrations of the following types:
Federated Authentication & SSO (i.e. SAML2)
SCIM
Snowflake OAuth
External OAuth
For more information about security integrations, see Replication of security integrations & network policies across multiple accounts.
API integrations.
After replicating API integrations to a target account, you must grant access to the remote service to the replicated external functions. For more information, see Updating the remote service for API integrations.
Notification integrations of the following types:
TYPE = EMAIL
TYPE = QUEUE with DIRECTION = OUTBOUND
TYPE = WEBHOOK
Storage integrations.
When you replicate a storage integration, you must establish a new trust relationship for your cloud storage in the target accounts. To learn more, see Configure cloud storage access for secondary storage integrations.
External access integrations.
For more information about external access integrations, see External network access overview.
The feature supports replicating network policies.
For more information, see Replication of security integrations & network policies across multiple accounts.
Parameter replication¶This feature supports replicating account-level parameters and object parameters. Object parameters are replicated when the object is included in the replication group. For example, if WAREHOUSES are replicated, warehouse-specific parameters (e.g. STATEMENT_TIMEOUT_IN_SECONDS) are replicated. For a full list, see Object parameters.
Account-level parameter replication includes all Account parameters and parameters set on the account. Account-level parameters (e.g. DATA_RETENTION_TIME_IN_DAYS) are replicated when ACCOUNT PARAMETERS is included in the list of object types for a replication group.
This feature supports replicating resource monitors and privileges granted on resource monitors to roles. A secondary resource monitor follows the same quota reset schedule as its primary. For example, if the quota on the primary resource monitor resets on the first of the month, and the secondary is first replicated on the 15th of the month, its quota will reset on the first of the next month along with the primary.
Replication of resource monitor email notification settings¶Email notification settings for resource monitors are not included with resource monitor replication. Email notifications for non-administrator users can be replicated with resource monitors. However, account administrator notification settings are currently not replicated:
If users and resource monitors are included in the object_types list for the replication or failover group, notification settings for non-administrator users are replicated:
The notify_users list for a warehouse-level resource monitor is replicated to target accounts.
Email notifications for non-administrator users are sent on the target account.
If resource monitors is included in the object_types list for the replication or failover group, but users is not included, the notify_users list for a secondary warehouse-level resource monitor is empty.
Account administrator notification settings are not replicated:
An account administrator must enable email notifications in each account using the web interface.
Resource monitor notifications are sent to account administrators if they have enabled email notifications in the source and/or target accounts.
This feature supports replicating roles, including role hierarchies. Role objects must be replicated to replicate access privileges. Replicated access privileges are listed in Replication of roles and grants below.
Note
All roles are replicated.
User replication¶This feature supports replicating users and their properties to target accounts, the following user authentication methods, and provisioning users and groups with SCIM:
Note
If USERS and ROLES objects are replicated to a target account, these object types are read-only in the target account and cannot be modified. Users and roles must be created in the source account, then replicated to each target account. Refer to Replication and read-only secondary objects.
This feature supports replicating warehouses and privileges granted on warehouses to roles (if roles are replicated). The state of the primary warehouse is not replicated. Warehouses are replicated in the suspended state to each target account and can be resumed in the target account.
Account replication supports replicating Datasets. Datasets are materialized data objects that you use with Snowflake ML. For usage information, see Snowflake Datasets. Replication is supported for Datasets created starting with the General Availability of the Dataset replication feature. For the release announcement, see Mar 20, 2025: Snowflake Datasets (General availability).
Replication of roles and grants¶In order to replicate grants on objects to roles, roles must be replicated from the source account to the target account. To replicate roles in a replication or failover group, you must include roles in the object_types list. Roles can be in a separate replication or failover group from the data objects on which the privileges are granted.
When roles are replicated, grants on objects are only replicated to a target account if:
The privilege was granted by the owner of the object or indirectly by a role that was granted the privilege with the WITH GRANT OPTION parameter by the owner of the object.
Both the grantee and grantor role for a privilege grant are located in the target account.
The object is replicated (i.e. the object type is included in the object_types list).
Otherwise the grant on the object is not replicated.
For information about replicating secondary roles and session policies, see Session policies with secondary roles.
Note
If a role is dropped that has the OWNERSHIP privilege on an active pipe in the target account, the refresh operation fails.
Privileges on replication groups and failover groups are not replicated. If the REPLICATE or FAILOVER privilege has been granted on replication groups or failover groups, these privileges need to be granted in both the source and target accounts. Refer to Replication privileges for details on these privileges.
If roles and databases are replicated to a target account (in the same or different replication or failover group), refreshing a secondary database synchronizes the privilege grants on the database and the objects in the database (schemas, tables, views, etc.) to existing roles in the target account (i.e. roles that have been replicated to the target account). Note that only privilege grants on objects supported by database replication are synchronized. For the list of supported objects, see Replicated database objects.
External tables are not currently supported for replication. As a result, privilege grants on external tables are also not replicated.
Future grants for objects¶If roles are replicated to the target account, future grants that are granted at the database or schema level are replicated to the target account. This also includes future grants on non-replication supported objects. For example, external table replication is not yet supported, however future grants on external tables are replicated. When you create an external table in a target account, the privileges granted on future external tables materialize as intended.
Object creation and ownership¶If new objects are created in a target account during a refresh from the source account, and roles are not replicated to the target account, the OWNERSHIP privilege for the new objects is granted to the ACCOUNTADMIN role.
If roles are replicated to the target account, the OWNERSHIP privilege is granted to the same role on the target account as the role with the OWNERSHIP privilege in the source account when roles are next replicated. The roles may be replicated at the same time the new objects are created in the target account if the objects and roles are in the same replication (or failover) group.
User who refreshes objects in a target account¶A user who executes the ALTER FAILOVER GROUP … REFRESH command to refresh objects in a target account from the source account must use a role with the REPLICATE privilege on the failover group. Snowflake protects this user in the target account by failing in the following scenarios:
If the user does not exist in the source account, the refresh operation fails.
If the user exists in the source account, but a role with the REPLICATE privilege was not granted to the user, the refresh operation fails.
As a best practice, Snowflake recommends scheduling automatic refreshes using the REPLICATION_SCHEDULE parameter. The schedule can be defined when creating a new replication or failover group with CREATE <object> or later (using ALTER <object>).
When you create a secondary replication or failover group, Snowflake automatically executes an initial refresh. The next refresh is scheduled based on when the prior refresh started and the scheduling interval, or the next valid time based on the cron expression. For example, if the refresh schedule interval is 10 minutes and the prior refresh operation (either a scheduled refresh or manually triggered refresh) starts at 12:01, the next refresh is scheduled for 12:11.
Snowflake ensures only one refresh is executed at any given time. If a refresh is still executing when the next refresh is scheduled, the next refresh is delayed to start when the currently executing refresh completes. For example, if a refresh is scheduled to execute 15 minutes after the hour, every hour, and the prior refresh completes at 12:16, the next refresh is scheduled to execute when the previously executing refresh is completed.
Note
Automatically scheduled refresh operations are executed using the role with the OWNERSHIP privilege on the replication or failover group. If a scheduled refresh operation fails due to insufficient privileges, grant the required privileges to the role with the OWNERSHIP privilege on the group.
Suspend and resume scheduled replication¶A secondary failover group cannot be promoted to the primary group while a refresh is executing. To fail over gracefully, suspend scheduled replication in the target account. After the failover is completed, resume the scheduled replication. For more information, see ALTER FAILOVER GROUP.
Replication to accounts on lower editions¶If either of the following conditions is true, Snowflake displays an error message:
A primary replication group with only database and/or share objects is in a Business Critical (or higher) account but one or more of the accounts approved for replication are on lower editions. Business Critical Edition is intended for Snowflake accounts with extremely sensitive data.
A primary replication or failover group with any object types is in a Business Critical (or higher) account and a signed business associate agreement is in place to store PHI data in the account per HIPAA and HITRUST CSF regulations. However, no such agreement is in place for one or more of the accounts enabled for replication, regardless if they are Business Critical (or higher) accounts.
This behavior is implemented in an effort to help prevent account administrators for Business Critical (or higher) accounts from inadvertently replicating sensitive data to accounts on lower editions.
An account administrator (a user with the ACCOUNTADMIN role) or a user with a role with the CREATE REPLICATION GROUP/CREATE FAILOVER GROUP or OWNERSHIP privilege can override this default behavior by including the IGNORE EDITION CHECK clause when executing the CREATE <object> or ALTER <object> statement. If IGNORE EDITION CHECK is set, the primary replication or failover group may be replicated to the specified accounts on lower Snowflake editions in these specific scenarios.
Note
Failover groups can only be created in a Business Critical Edition (or higher) account. Therefore failover groups can only be replicated to an account that is a Business Critical Edition (or higher) account.
Current limitations of replication¶Databases created from shares cannot be replicated.
Refresh operations fail if the primary database includes a stream with an unsupported source object. The operation also fails if the source object for any stream has been dropped.
Append-only streams are not supported on replicated source objects.
Note
Database replication does not work for task graphs if the graph is owned by a different role than the role that performs replication.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4