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:

Placeholder	Stands for
`<xstore-name>`	Your xStore cluster
`<metalake-name>`	The metalake the catalog is created in
`<account>` / `<region>`	Your Snowflake account identifier and region
`<database>`	The Snowflake database to catalog
`<warehouse>`	The Snowflake warehouse used for queries
`<schema_1>` …	Schemas discovered inside that database
`<table_1>` …	Tables discovered inside a schema
`<user>`	The Snowflake account the catalog connects as

Info
Important: A Snowflake catalog is a relational catalog and lives inside a metalake on an xStore. Create the xStore and metalake first; this guide adds a catalog to an existing metalake.

Key Concepts

Info
New to xStore catalogs? See xStore Catalog Relational — Core Concepts for the shared model — metalakes, catalog types, the provider list, identity/run-as, the create-catalog wizard, browsing, and what you can do with a catalog.

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 plus CREATE 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

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

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.

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

Add custom connection properties

In the Backend step, scroll to Additional Properties.
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

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

Let an xCompute engine query the catalog

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

Reference

Create Catalog wizard steps

Step	Name	What it configures
1	Catalog Type	Relational (Snowflake) or Fileset.
2	Provider	The relational engine — select Snowflake.
3	Basic Information	Catalog name and optional comment (metalake is fixed).
4	Identity	Which identity owns the credentials (default: System User → `xstore-system-user`).
5	Backend	JDBC URL, database, warehouse, authentication, and custom properties.
6	Review	Confirm the summary and derived properties, then create.

Backend fields

Field	Required	Description
JDBC URL	Yes	Snowflake JDBC URL, e.g. `jdbc:snowflake://<account>.<region>.aws.snowflakecomputing.com`.
JDBC Database	Yes	Target Snowflake database (e.g. `<database>`).
Warehouse	No	Snowflake warehouse used for queries (e.g. `<warehouse>`).
Authentication Type	Yes	`PASSWORD` or `KEYPAIR`.
JDBC User	Yes	Snowflake username (both auth types).
JDBC Password	PASSWORD only	Snowflake password.
Private Key	KEYPAIR only	RSA private key for key-pair auth.
Private Key Passphrase	KEYPAIR (optional)	Passphrase if the private key is encrypted.
Additional Properties	No	Custom key-value pairs merged into catalog properties.

Authentication types

Auth Type	Credentials	Notes
PASSWORD	JDBC User + JDBC Password	Standard Snowflake user/password.
KEYPAIR	JDBC User + Private Key (+ Passphrase)	RSA key-pair authentication.

Derived backend properties

xDP generates these Gravitino properties for a Snowflake catalog:

Property	Value (example)
`jdbc-url`	`jdbc:snowflake://<account>.<region>.aws.snowflakecomputing.com`
`jdbc-database`	`<database>`
`warehouse`	`<warehouse>`
`jdbc-driver`	`net.snowflake.client.jdbc.SnowflakeDriver` (always set)
`jdbc-user`	the Snowflake username
`jdbc-password`	the Snowflake password (stored as a secret; masked in the UI)

Best Practices

Info
Tip: Use a dedicated, least-privilege Snowflake user (or service key pair) scoped to the database and warehouse you intend to expose.

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.

Last updated on

Was this page helpful?