Snowflake Catalog

Explanation (Core Concepts)

What is a Snowflake Catalog?

A Snowflake catalog registers a Snowflake account as a governed, relational catalog inside an xStore. Once registered, xDP can browse the account's schemas, tables, and columns, apply governance policies, and let linked xCompute engines query it — all from the central Data Catalog.

Under the hood, the catalog is created in the xStore's Apache Gravitino metastore using the snowflake provider. It connects to Snowflake over JDBC; xDP always injects the Snowflake JDBC driver (net.snowflake.client.jdbc.SnowflakeDriver), so you only supply the connection URL, database, warehouse, and credentials.

This guide is written for the Data Steward / Catalog Manager who onboards external data sources into the catalog. It assumes a running xStore (here, <xstore-name>) with at least one metalake (<metalake-name>).

The steps and screenshots in this guide use placeholders, not real object names — substitute your own values wherever you see one:

Key Concepts

Concepts specific to Snowflake:

• A warehouse is required. Every query runs on a Snowflake warehouse, so the catalog identity needs USAGE on it.
• Backend authentication — PASSWORD vs KEYPAIR:
• PASSWORD — a Snowflake username and password.
• KEYPAIR — RSA key-pair auth: a private key (optionally with a passphrase) plus the username.

Tutorial (Getting Started)

This tutorial onboards a Snowflake catalog named snowflake_catalog into the <metalake-name> metalake on <xstore-name>, using password authentication, then browses its schemas and tables.

Prerequisites

• A running xStore cluster with status RUNNING.
• At least one metalake in that xStore (this tutorial uses <metalake-name>).
• A reachable Snowflake account, plus the target database and warehouse names.
• Snowflake credentials — either a username/password (PASSWORD) or an RSA key pair (KEYPAIR).
• Administrative permissions on the xDP platform.

Minimum Snowflake permissions

Grant these to the Snowflake role used by the catalog (and, because Spark/Trino/Jupyter queries run as the per-user identity, to the role the querying users map to). These are datasource-side grants; xCentral/Ranger policies apply on top.

• Read-only (onboard + browse + query):USAGE ON WAREHOUSE <wh>, USAGE ON DATABASE <db>, USAGE ON SCHEMA <db>.<schema>, and SELECT ON ALL TABLES IN SCHEMA <db>.<schema>.
• Read-write (write from engines): the above plusCREATE SCHEMA ON DATABASE <db>, CREATE TABLE ON SCHEMA <db>.<schema>, and INSERT, UPDATE, DELETE ON TABLES.

Run this on Snowflake before onboarding (replace the <...> placeholders). Reference: Snowflake — GRANT <privileges>.

-- Run as ACCOUNTADMIN (or a role with MANAGE GRANTS)
CREATE ROLE IF NOT EXISTS xdp_catalog_role;
-- Read-only
GRANT USAGE ON WAREHOUSE <warehouse> TO ROLE xdp_catalog_role;
GRANT USAGE ON DATABASE <db> TO ROLE xdp_catalog_role;
GRANT USAGE ON SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
GRANT SELECT ON ALL TABLES IN SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
GRANT SELECT ON FUTURE TABLES IN SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
-- Read-write (add)
GRANT CREATE SCHEMA ON DATABASE <db> TO ROLE xdp_catalog_role;
GRANT CREATE TABLE ON SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
GRANT INSERT, UPDATE, DELETE ON FUTURE TABLES IN SCHEMA <db>.<schema> TO ROLE xdp_catalog_role;
GRANT ROLE xdp_catalog_role TO USER <catalog_user>;

Step 1 — Open the Data Catalog and choose the metalake

1. Open Data catalog from the left sidebar and select your xStore (<xstore-name>) from the Select xStore dropdown.
2. The catalog lists the xStore's metalakes. Click <metalake-name> to open it.

1. In the metalake, click Add Catalog. The 6-step Create Catalog wizard opens (Catalog Type → Provider → Basic Information → Identity → Backend → Review).

Step 2 — Catalog Type

Choose what kind of data this catalog manages. Snowflake is a database, so select Relational and click Next.

Step 3 — Provider

Pick Snowflake from the list of relational providers, then click Next.

Step 4 — Basic Information

Give the catalog a name and (optionally) a comment. The Metalake is fixed to the one you opened.

• Catalog Name:snowflake_catalog
• Comment:Snowflake relational catalog (demo)

Click Next.

Step 5 — Identity

Choose which identity owns the credentials this catalog uses for authentication. The default System User (which runs as xstore-system-user) is used here. Click Next.

Step 6 — Backend (connection + authentication)

Enter the Snowflake connection settings:

• JDBC URL:jdbc:snowflake://<account>.<region>.aws.snowflakecomputing.com
• JDBC Database:DATABASE_NAME
• Warehouse:WAREHOUSE_NAME

Then choose a Backend Authentication type. xDP supports both:

PASSWORD — supply the Snowflake JDBC User and JDBC Password. This tutorial uses password auth with user <user>.

KEYPAIR — instead of a password, supply the JDBC User, an RSA Private Key, and an optional Private Key Passphrase.

Optionally add custom key-value pairs under Additional Properties, then click Next.

Step 7 — Review & Create

Review the summary and the derived Backend properties. Note that xDP automatically sets jdbc-driver = net.snowflake.client.jdbc.SnowflakeDriver, and the jdbc-password is masked. Click Create Catalog.

The catalog is created and appears in the metalake's Catalogs table as a snowflake / relational catalog with status In use.

Step 8 — Browse schemas

Click the snowflake_catalog to open it. The detail view shows the catalog's metadata (Provider snowflake, Type relational, Auth type PASSWORD, Run-as xstore-system-user), its connection Properties, and the Schemas discovered in the account.

Step 9 — Browse tables

Click a schema (for example <schema_1>) to list its Tables — here <table_1>.

Click a table to see its column-level detail (this table has 10 columns).

How-to Guides

Onboard with key-pair authentication

1. In the Backend step, select KEYPAIR instead of PASSWORD.
2. Enter the JDBC User, paste/upload the RSA Private Key, and provide the Private Key Passphrase if your key is encrypted.
3. Complete the wizard as in the tutorial. xDP stores the private key as a credential file for the catalog.

Add custom connection properties

1. In the Backend step, scroll to Additional Properties.
2. Enter a Property Key and Value and add it. These are merged into the catalog's Gravitino properties alongside the standard jdbc-* keys.

Edit or delete a Snowflake catalog

1. Open the catalog detail view.
2. Use Edit catalog to change connection settings (URL, database, warehouse, credentials, properties), or More actions to delete it.
3. For schema-level changes, use New schema / Edit schema from the catalog and schema views.

Let an xCompute engine query the catalog

1. Open the catalog and select the Linked compute tab.
2. Link an xCompute cluster so its engines (Spark, Trino) can query the Snowflake catalog's tables.

Reference

Create Catalog wizard steps

Backend fields

Authentication types

Derived backend properties

xDP generates these Gravitino properties for a Snowflake catalog:

Best Practices

• Prefer key-pair auth for production. RSA key-pair authentication avoids long-lived passwords and integrates better with secret rotation.
• Scope the warehouse and database. Point the catalog at a specific warehouse and database so catalog browsing and queries use predictable, cost-controlled compute.
• Use a least-privilege Snowflake role. Grant the connecting user only the access needed to read the schemas you want to catalog.
• Name catalogs by source. A clear catalog name (e.g. snowflake_catalog) makes governance and cross-engine queries easier to reason about.
• Protect credentials. Never share the JDBC password or private key; xDP stores them as secrets and masks them in the UI.

What's Next

• Apply governance policies to the catalog from the linked xCentral.
• Link an xCompute cluster so Spark or Trino can query the Snowflake tables.
• Onboard more catalogs (Hive, PostgreSQL, Iceberg, Unity Catalog) into the same metalake to unify discovery and governance.