Snowflake is quick to configure, especially with our fully automated Snowflake Worksheet commands. Please note that the process detailed in this document will not work without an active, billing-enabled Snowflake account. If you have not done so, please make sure you have updated your billing information in Snowflake.
Getting Started
There are a few key connection details that are needed to configure Snowflake as a destination properly:
Account
Warehouse
Database
Schema
User
Password
Please note all of these details, as they will be needed during the Openbridge Snowflake data destination registration process.
Understanding Snowflake Connection Details
As we detail below, configuring key Snowflake connection details is mostly automated. However, specific aspects of Snowflake are required for us to connect and deliver data properly.
Account: The name of your Snowflake account. The account name would be those items in bold:
<account>.
snowflakecomputing.com
<account>.<region_id>.
snowflakecomputing.com
<account>.<region_id>.azure.
snowflakecomputing.com
For example, If your Snowflake address is
https://hzc88038.us-east-1.snowflakecomputing.com
then your account name is hzc88038.us-east-1. If you are on Azure, your address would be https://hzc88038.us-east-1.azure.snowflakecomputing.com
, and the account name is hzc88038.us-east-1. azure
For reference, see this:
Lastly, only reference the account name, not the full hostname or protocol (HTTPS://).
Snowflake User Interface
Here is an example of where to find some of the information in the Snowflake interface:
Note the link and copy icons on the far right of the screenshot above. The link icon will reveal the specifics we detailed earlier. The link will be https://y7rfdew.us-east-2.aws.snowflakecomputing.com
. This means the identifier you will need to use in the Openbridge destination setup will be y7rfdew.us-east-2.aws
.
Note: For more background on account identifiers, see the Snowflake docs: https://docs.snowflake.com/en/user-guide/admin-account-identifier
Verify Snowflake Network Policies
Your Snowflake account may restrict external access. If this is the case, you need to CREATE or ALTER your Snowflake Network Policy to allow us to connect successfully. This means our IP addresses must be added to a network policy's Allowed IP List for a connection to be successful. This can be done in the Snowflake web interface or via SQL command in the Snowflake Worksheet.
Below is an example of commands you would run in the Worksheet:
/*
If you want to use a network policy or modify an exsiting one, uncomment the one (create or alter) that aligns with your needs.
Our IP addresses are 52.2.68.68/32, 52.54.227.22/32
*/
--create network policy openbridge_ip_whitelist ALLOWED_IP_LIST = ('52.2.68.68/32', '52.54.227.22/32');
--alter network policy <your_current_network_policy_name> SET {[ALLOWED_IP_LIST] = ('52.2.68.68/32', '52.54.227.22/32')]};
Here is an example of creating the policy assuming the correct permissions:
-- Use the ACCOUNTADMIN role to ensure sufficient privileges
USE ROLE ACCOUNTADMIN;
create network policy openbridge_ip_whitelist ALLOWED_IP_LIST = ('52.2.68.68/32', '52.54.227.22/32');
Network Rule + Policy Configuration
You can also use a network rule and policy combination:
CREATE OR REPLACE NETWORK RULE openbridge_ip_rule
TYPE = IPV4
MODE = INGRESS
VALUE_LIST = (
'52.2.68.68/32',
'52.54.227.22/32'
);
You then link the rule to a policy:
CREATE OR REPLACE NETWORK POLICY openbridge_access_policy
ALLOWED_NETWORK_RULE_LIST = ('openbridge_ip_rule');
Verify Network Settings
You can verify settings by reviewing your setup. Here is an example:
-- Check allowed IPs
DESC NETWORK POLICY openbridge_access_policy;
-- Verify account-level enforcement
SHOW PARAMETERS LIKE 'network_policy' IN ACCOUNT;
These commands are present in the automated SQL command setup command. You would uncomment the most appropriate (CREATE or ALTER) for your use case. For more information on network policies, see Snowflake network policies documentation.
Automating Snowflake Configuration
With the definitions done, we can now configure Snowflake. The process will use an automated Snowflake Worksheet approach.
The following inputs are needed by Openbridge to register Snowflake as a destination:
Warehouse: We recommend creating a new warehouse dedicated to Openbridge. Our automated config process defaults to an X-Small warehouse to avoid conflicts. You can always scale this upwards as needed.
Database: Enter the name of the database you created.
Schema: Enter the name of the database you created.
Username: Enter the Snowflake database user's username.
Password: Enter the password for the Snowflake database user.
In the steps below, we detail how to get these configured and ready.
Step 1: Log into your Snowflake account using a web browser or a SQL client
If you log in via a web browser, click the Worksheet icon at the top. Please ensure the session role is set to ACCOUNTADMIN to complete this process.
Step 2: Prepare your automated commands
Your Snowflake environment will use the automated setup SQL command below. You will need to make a few edits.
First, change the commands' username, password, and any other variables as needed. They will be:
openbridge_role = 'OPENBRIDGE_ROLE';
openbridge_username = 'changeme';
openbridge_password = 'changeme';
openbridge_warehouse = 'OPENBRIDGE_WAREHOUSE';
openbridge_database = 'OPENBRIDGE_DATABASE';
openbridge_schema = 'OPENBRIDGE_SCHEMA';
Note these details, as you will need to enter them into the Openbridge destination registration process. See below
Step 3: Run The Automation Script
Here is the script to paste into your Snowflake WORKSHEET space. However, before you begin one note on Snowflake data storage.
Note: When creating a schema, you have two options. Tables will have what is called Continuous Data Protection (CDP) enabled by default. CDP does have an impact on storage costs, based on the total amount of data stored and the length of time the data is stored.
"For some larger, high-churn dimension tables, the storage costs associated with CDP can be significant. When multiple updates are made to a table, all of the impacted micro-partitions are re-created and then they transition through the CDP storage life-cycle."
The second option is to use TRANSIENT
tables. Transient tables have no Fail-safe and have a Time Travel retention period of only 0 or 1 day. A TRANSIENT
table is still permanent, it simply does not have the CDP feature enabled.
If you want to leverage TRANSIENT
tables, simply uncomment that line in the worksheet below.
See Data storage considerations
Don't forget to change the items from Step 2!
-- Set variables (Replace placeholders with your actual values)
SET openbridge_role = 'YOUR_OPENBRIDGE_ROLE'; -- e.g., 'BUXZZ_ROLE'
SET openbridge_username = 'YOUR_OPENBRIDGE_USER'; -- e.g., 'BUXZZ_USER'
SET openbridge_password = 'YOUR_PASSWORD'; -- e.g., '12BUXZZ!@'
SET openbridge_warehouse = 'YOUR_OPENBRIDGE_WAREHOUSE';-- e.g., 'BUXZZ_WAREHOUSE'
SET openbridge_database = 'YOUR_OPENBRIDGE_DATABASE'; -- e.g., 'BUXZZ_DATABASE'
SET openbridge_schema = 'YOUR_OPENBRIDGE_SCHEMA'; -- e.g., 'BUXZZ_SCHEMA'
SET openbridge_namespace = $openbridge_database || '.' || $openbridge_schema;
-- Use the ACCOUNTADMIN role to ensure sufficient privileges
USE ROLE ACCOUNTADMIN;
-- Step 1: Setup
-- Create the Openbridge role if it doesn't exist
CREATE ROLE IF NOT EXISTS IDENTIFIER($openbridge_role);
-- Create the Openbridge user if it doesn't exist
CREATE USER IF NOT EXISTS IDENTIFIER($openbridge_username)
PASSWORD = $openbridge_password
DEFAULT_ROLE = $openbridge_role
DEFAULT_WAREHOUSE = $openbridge_warehouse
DEFAULT_NAMESPACE = $openbridge_namespace; -- Use pre-built namespace
-- Grant the role to the user
GRANT ROLE IDENTIFIER($openbridge_role) TO USER IDENTIFIER($openbridge_username);
-- Assign the current user's name to a variable
SET current_username = CURRENT_USER();
-- Grant the role to your current user (for testing purposes)
GRANT ROLE IDENTIFIER($openbridge_role) TO USER IDENTIFIER($current_username);
-- Create the warehouse if it doesn't exist
CREATE WAREHOUSE IF NOT EXISTS IDENTIFIER($openbridge_warehouse)
WAREHOUSE_SIZE = 'XSMALL'
WAREHOUSE_TYPE = 'STANDARD'
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE;
-- Grant usage on the warehouse to the role
GRANT USAGE ON WAREHOUSE IDENTIFIER($openbridge_warehouse) TO ROLE IDENTIFIER($openbridge_role);
-- Create the database if it doesn't exist
CREATE DATABASE IF NOT EXISTS IDENTIFIER($openbridge_database);
-- Grant usage on the database to the role (without CREATE SCHEMA privilege)
GRANT USAGE ON DATABASE IDENTIFIER($openbridge_database) TO ROLE IDENTIFIER($openbridge_role);
-- Use the new database
USE DATABASE IDENTIFIER($openbridge_database);
-- Schema Creation Options:
-- Option 1: Standard Schema (Use when CDP/Data History is needed)
CREATE SCHEMA IF NOT EXISTS IDENTIFIER($openbridge_schema);
-- Option 2: TRANSIENT Schema (Use when CDP/Data History is NOT needed - reduces storage costs)
-- CREATE TRANSIENT SCHEMA IF NOT EXISTS IDENTIFIER($openbridge_schema);
-- Grant privileges on the schema to the role
GRANT USAGE ON SCHEMA IDENTIFIER($openbridge_schema) TO ROLE IDENTIFIER($openbridge_role);
GRANT CREATE TABLE, CREATE VIEW, CREATE STAGE, CREATE FILE FORMAT ON SCHEMA IDENTIFIER($openbridge_schema) TO ROLE IDENTIFIER($openbridge_role);
-- Step 2: Switch to the Openbridge role for testing
USE ROLE IDENTIFIER($openbridge_role);
-- Set the context to use the Openbridge warehouse, database, and schema
USE WAREHOUSE IDENTIFIER($openbridge_warehouse);
USE DATABASE IDENTIFIER($openbridge_database);
USE SCHEMA IDENTIFIER($openbridge_schema);
-- Step 3: Test Operations
-- Test 1: Create a table
CREATE OR REPLACE TABLE test_table (
id INT AUTOINCREMENT PRIMARY KEY,
name STRING,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP()
);
-- Test 2: Insert data into the table
INSERT INTO test_table (name) VALUES
('Alice'),
('Bob'),
('Charlie');
-- Test 3: Query data from the table
SELECT * FROM test_table;
-- Test 4: Update data in the table
UPDATE test_table
SET name = 'Alice Updated'
WHERE name = 'Alice';
-- Test 5: Delete data from the table
DELETE FROM test_table
WHERE name = 'Bob';
-- Test 6: Drop the table
DROP TABLE test_table;
Step 3: RUN your Snowflake Worksheet
With your edits in place, you can paste the content into the Snowflake Worksheet.
We suggest you review the Warehouse, Database, Schema... (see B) to ensure they are present and align with your configuration.
Select "Run All" when you start your worksheet run (see A). You should see a "success" output from Snowflake. If not, check your inputs in the script.
Snowflake is ready to receive data!
If all looks good, you have now configured a Snowflake destination. You should see an "Statement executed successfully"
in your worksheet. If you reload the page, see your database and schema:
Openbridge Interface: Register Your new Snowflake Destination
With your Snowflake environment ready, complete the entry of the from your setup to register the destination:
Alert: If you change anything in Snowflake after registering a destination with Openbridge, such as a schema or database name, this will cause a connection failure, as neither Snowflake nor Openbridge can reconcile the different configuration states.