Introduction to Database Replication Across Multiple Accounts

This feature enables replicating databases between Snowflake accounts (within the same organization) and keeping the database objects and stored data synchronized. Database replication is supported across regions and across cloud platforms.

In this Topic:

What is a Primary Database?

Replication can be enabled for any existing permanent or transient database. Enabling replication designates the database as a primary database. Any number of databases in an account can be designated a primary database. Likewise, a primary database can be replicated to any number of accounts in your organization. This involves creating a secondary database as a replica of a specified primary database in each of the target accounts. These accounts are typically located in other regions, on the same or a different cloud platform (AWS or Microsoft Azure).

All DML/DDL operations are executed on the primary database. Each read-only, secondary database can be refreshed periodically with a snapshot of the primary database, replicating all data as well as DDL operations on database objects (i.e. schemas, tables, views, etc.).

Overview of Replication

This section provides a high-level overview of the objects and settings available for 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 Database Replication Considerations.

Object

Type or Feature

Replicated

Notes

Tables

Permanent tables

Transient tables

Temporary tables

Automatic Clustering of clustered tables

External tables

Creating or refreshing a secondary database is blocked if an external table exists in the primary database. . Planned for a future version of database replication.

Table constraints

Except if a foreign key in the database references a primary/unique key in another database. .

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

File formats

Stages

Stages

Planned for a future version of database replication.

Temporary stages

Pipes

Planned for a future version of database replication.

Stored procedures

Streams

Planned for a future version of database replication.

Tasks

Planned for a future version of database replication.

User-defined functions (UDF)

Other Objects in an Account

Currently, replication is supported for databases only. Other types of objects in an account cannot be replicated. This list includes:

  • Users

  • Roles

  • Warehouses

  • Resource monitors

  • Shares

Access Control

Privileges granted on database objects are not replicated to a secondary database.

Parameters

Account parameters are not replicated.

Object parameters are not replicated, with the following exception:

Parameter

Objects

DATA_RETENTION_TIME_IN_DAYS

schema, table

Database Replication and Encryption

When a database is replicated to another account (both during the initial replication and later, when a secondary database is refreshed), Snowflake encrypts the database files (i.e. the database object metadata and data sets) in-transit from the source account to the target account. Snowflake encrypts files for database replication operations using a random, unique key for each replication job.

In addition, if Tri-Secret Secure is enabled for the replication accounts (i.e. the source and target accounts), the files are encrypted using the public key for an encryption key pair that is protected by the account master key (AMK) for your target account. The extra level of security provided by Tri-Secret Secure protects the AMK, therefore this protection also applies to data files in transit.

Note that tri-secret guarantees are valid for data files in transit also. Revoking access to the customer-managed key (in the key management service for the cloud provider that hosts your Snowflake account) prevents Snowflake from decrypting any data files in transit.

For more information about data encryption in Snowflake, see Data Encryption.

Current Limitations of Replication

  • Refreshing a secondary database is blocked if an external table exists in the primary database.

  • Databases created from shares cannot be replicated.

Database Replication Billing

Charges based on database replication are divided into two categories: data transfer and compute resources. Both categories are billed on the target account (i.e. the account that stores the secondary database that is refreshed).

Data transfer

The initial database replication and subsequent synchronization operations transfer data between regions. Cloud providers charge for data transferred from one region to another within their own network.

The data transfer rate is determined by the location of the source account (i.e. the account that stores the primary database). For data transfer pricing, see the pricing page (on the Snowflake website).

For more information about data transfer billing, see Understanding Snowflake Data Transfer Billing.

Compute resources

Replication operations use Snowflake-provided compute resources to copy data between accounts across regions.

Note

  • The target account also incurs standard storage costs for the data in each secondary database in the account.

  • If the initial database replication or a subsequent refresh operation fails, the next attempt (if performed within 14 days) can reuse the data that was already copied; that is, the data is not copied again during the next attempt. For this reason, database replication charges are applied even if the initial database replication or a subsequent refresh operation fails.

Estimating and Controlling Costs

In general, monthly billing for database replication is proportional to:

  • Amount of table data in the primary database that changes as a result of data loading or DML operations.

  • Frequency of secondary database refreshes from primary databases.

You can control the cost of replication by carefully choosing which primary databases to replicate and their refresh frequency. You can stop incurring replication costs by ceasing database refresh operations.

Viewing Actual Costs

Users with the ACCOUNTADMIN role can use the Snowflake web interface or SQL to view the amount of replication data transferred (in bytes) for your Snowflake account within a specified date range.

To view the data transfer amounts for your account:

Web Interface

Click on Account Account tab » Billing & Usage. Replication utilization is shown as a special Snowflake-provided warehouse named Snowflake logo in blue (no text) REPLICATION. Click the Data Transfer button to view the data transfer costs. Note that the web interface does not break down data transfer costs for replication.

SQL

Query the REPLICATION_USAGE_HISTORY table function (in the Information Schema). This function returns replication usage activity within the last 14 days.