Neo4j Snowflake Graph Analytics Skill

Snowflake Native App — graph algorithm power inside Snowflake. Data stays in Snowflake; project into a graph, run algorithms via SQL CALL, results written back to Snowflake tables.

Docs: https://neo4j.com/docs/snowflake-graph-analytics/current/

When to Use

• Running graph algorithms / GDS in Snowflake
• Data already lives in Snowflake tables
• On-demand / pipeline workloads — ephemeral sessions, pay per session-minute
• Full isolation from the live database during analytics

When NOT to Use

• Aura Pro with embedded GDS plugin → neo4j-gds-skill
• Aura Graph Analytics → neo4j-aura-graph-analytics-skill
• Self-managed Neo4j with embedded GDS plugin → neo4j-gds-skill
• Writing Cypher queries → neo4j-cypher-skill

The End-to-End Flow

This is the flow that works. Don't jump straight to a CALL — most failures come from skipping the data-preparation step.

1. Explore the source data — inspect table DDLs to learn columns and types.
2. Prepare projection views — create node/relationship views that expose the required key columns and cast every property to a supported type (see the strict rules below). This is the step that matters most.
3. Project → Compute → Write — run the algorithm with a single CALL, assembling the project, compute, and write config.
4. Inspect & look up names — join numeric results back to the source table to get human-readable labels.

Step 1 — Explore the Source Data

Look at the table definitions before designing the graph:

SELECT GET_DDL('TABLE', 'MY_DATABASE.MY_SCHEMA.MY_TABLE');
-- or inspect columns/types:
SELECT COLUMN_NAME, DATA_TYPE
FROM MY_DATABASE.INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'MY_SCHEMA' AND TABLE_NAME = 'MY_TABLE';

Decide which tables are nodes and which represent relationships (edges) between them.

Step 2 — Prepare Projection Views (the important part)

The graph engine is strict about column names and types. Snowflake views inherit the source column type by default, so you MUST add explicit CASTs — never SELECT col without one for a property column.

Create views that reshape your tables into the node/relationship format:

CREATE OR REPLACE VIEW MY_DATABASE.MY_SCHEMA.MY_NODES_VW AS
SELECT ... FROM MY_DATABASE.MY_SCHEMA.MY_TABLE;

Node views

• Key column: expose the primary key as NODEID. It must be BIGINT or STRING. Always alias and cast explicitly: SOURCE_COL::BIGINT AS NODEID or SOURCE_COL::STRING AS NODEID.
• Allowed node property types (exactly): BIGINT, DOUBLE, ARRAY, VECTOR(FLOAT, n). Anything else must be cast to one of these or dropped.
• Composite keys: concatenate parts with '++'.
• Naming: <table>_NODES_VW.

Source-type → view-type casting rules

Apply these when projecting columns from your tables (keep the original column name unless renaming):

Lowest-common-denominator policy: by default include only safe columns (numeric → BIGINT/DOUBLE, ARRAY, VECTOR). Booleans and time-like columns require explicit opt-in. When you drop columns, briefly tell the user which and why, so they can ask for them back.

Relationship views

• Key columns: expose SOURCENODEID and TARGETNODEID, cast with the same rules as NODEID (SOURCE_COL::BIGINT AS SOURCENODEID, etc.). Every value must match an existing NODEID in a node view.
• Allowed relationship property types (narrower): BIGINT, DOUBLE, INT only. No `ARRAY`, no `VECTOR`. (The docs describe relationship properties as FLOAT; the engine accepts these whole/fractional numeric casts and treats them as weights — keep them numeric.)
• Naming: <table>_RELATIONSHIPS_VW.

Example node + relationship views:

CREATE OR REPLACE VIEW MY_DATABASE.MY_SCHEMA.USER_NODES_VW AS
SELECT user_id::BIGINT AS NODEID,
       CAST(age AS BIGINT)        AS age,
       CAST(balance AS DOUBLE)    AS balance
FROM MY_DATABASE.MY_SCHEMA.USERS;

CREATE OR REPLACE VIEW MY_DATABASE.MY_SCHEMA.TRANSFERS_RELATIONSHIPS_VW AS
SELECT from_user::BIGINT AS SOURCENODEID,
       to_user::BIGINT   AS TARGETNODEID,
       CAST(amount AS DOUBLE) AS amount
FROM MY_DATABASE.MY_SCHEMA.TRANSFERS;

The required logical column names are nodeId / sourceNodeId / targetNodeId — Snowflake folds unquoted identifiers to uppercase, so NODEID etc. match. Casting explicitly is what matters.

Step 3 — Project → Compute → Write

Every run is a single CALL whose first argument is the compute pool and second is a JSON config with three parts. Note JSON uses single quotes in Snowflake SQL.

App name: Neo4j_Graph_Analytics is only the default installation name. If the app was installed under a different name, replace it everywhere — in the procedure call (<APP>.graph.<algo>), the preview.* / admin.* calls, the USE DATABASE <APP> statement, and the privilege grants below. Check with SHOW APPLICATIONS;.

USE ROLE MY_CONSUMER_ROLE;

CALL Neo4j_Graph_Analytics.graph.wcc('CPU_X64_XS', {
    'defaultTablePrefix': 'MY_DATABASE.MY_SCHEMA',
    'project': {
        'nodeTables': ['USER_NODES_VW'],
        'relationshipTables': {
            'TRANSFERS_RELATIONSHIPS_VW': {
                'sourceTable': 'USER_NODES_VW',
                'targetTable': 'USER_NODES_VW',
                'orientation': 'NATURAL'
            }
        }
    },
    'compute': { 'consecutiveIds': true },
    'write': [{
        'nodeLabel': 'USER_NODES_VW',
        'outputTable': 'result_wcc_user_communities'
    }]
});

SELECT * FROM MY_DATABASE.MY_SCHEMA.result_wcc_user_communities;

Config parts

• `defaultTablePrefix` — set to the database + schema where your views and output tables live (DB.SCHEMA); lets you reference them by short name.
• `project` — nodeTables (array; each maps to a label) and relationshipTables (map; each key maps to a type, with sourceTable/targetTable/orientation).
• `compute` — algorithm parameters. Omit any parameter whose value would be null.
• `write` — a list of write targets. nodeLabel (or sourceLabel/targetLabel) is the table/view name of the nodes being written. For relationship results use relationshipType.

Orientation

Set orientation per relationship table in relationshipTables:

• NATURAL (default) — directed, source → target (as stored in the table).
• UNDIRECTED — treated as bidirectional (each relationship is included in both directions).
• REVERSE — direction flipped, target → source.

Choose based on the algorithm:

• `UNDIRECTED` — community detection that treats edges symmetrically: WCC, Louvain, Leiden, Label Propagation. Triangle Count requires `UNDIRECTED`.