Run Neo4j Graph Analytics algorithms (PageRank, Louvain, WCC, Dijkstra, KNN, Node2Vec, FastRP, GraphSAGE) directly inside Snowflake without moving data. Use when running graph algorithms against Snowflake tables via the Neo4j Snowflake Native App ("GDS Snowflake", "graph algorithms in Snowflake", "N

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: 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 CAST s — never SELECT col without one for a property column. Create views that reshape your tables into the node/relationship format: 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): Source type Action Whole number numerics ( INT , INTEGER , BIGINT , SMALLINT , TINYINT , BYTEINT , NUMBER(p,0) ) CAST(col AS BIGINT) AS col Fractional numerics ( FLOAT , DOUBLE , REAL , DECIMAL(p,s 0) , NUMBER(p,s 0) ) CAST(col AS DOUBLE) AS col ARRAY of numbers keep as ARRAY (except GraphSAGE — see below). Not allowed on relationship views. VECTOR(FLOAT, n) keep as is. Not allowed on relationship views. BOOLEAN drop by default . Opt in only: IFF(col, 1, 0)::BIGINT AS col DATE , TIME , TIMESTAMP drop by default . Opt in only: DATE PART('EPOCH SECOND', col)::BIGINT AS col (tell the user the unit) VARCHAR , CHAR , TEXT , STRING drop — can't be a graph property. To read results by name, join output back to the source table on the key (see Step 4) VARIANT , OBJECT , GEOGRAPHY , GEOMETRY , BINARY drop — not supported as graph properties 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: 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; . 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 . NATURAL — directed flow and ranking: PageRank, Article Rank, Dijkstra and the other pathfinding algorithms, Max Flow. Node Similarity expects a bipartite graph (two disjoint node sets) projected NATURAL ; use REVERSE to compare the other node set instead. KNN ignores relationships entirely — similarity comes from node properties, so orientation has no effect on it (and K Means likewise uses only node properties). Compute pools (first CALL argument) Pool Use CPU X64 XS Default — dev / small graphs CPU X64 S/M/L Progressively larger HIGHMEM X64 S/M/L Large graphs, lower CPU need GPU NV XS , GPU NV S , GPU GCP NV L4 1 24G GraphSAGE / GPU work (availability varies by region) Prefer CPU X64 XS unless the user asks otherwise or GraphSAGE makes a GPU pool appropriate. See [Estimating Jobs](https://neo4j.com/docs/snowflake graph analytics/current/jobs/estimation/). Result table naming Name output tables result <algotag <short description , underscores only, no spaces/special chars (e.g. result louvain customer segments ). When writing multiple node labels, use a distinct table per label. Step 4 — Inspect & Look Up Names What the algorithm produces depends on its type — check the algorithm's write config: Node property results (centrality, community detection, k means, embeddings, FastPath) — a table keyed by NODEID . Relationship results (Node Similarity, KNN, Dijkstra & other pathfinding, Max Flow) — a table keyed by SOURCENODEID / TARGETNODEID . BFS and other heterogeneous writes also add SOURCELABEL / TARGETLABEL , with the node IDs stored as strings. A model (GraphSAGE training) — no output table; it writes to the model catalog. Use the model later for prediction, which then produces a node property table. VARCHAR labels were dropped during projection, so join the result back to the source table on the key column(s) to get readable names. For node property results, join on NODEID : For relationship results, join the source table twice — once on SOURCENODEID and once on TARGETNODEID . Available Algorithms Procedure = Neo4j Graph Analytics.graph.<name . Names below are exact. For complete algorithm compute/write parameter reference, see [references/algorithms.md](references/algorithms.md). Community Detection Algorithm Procedure Use case Weakly Connected Components wcc Find disconnected subgraphs Louvain louvain Community detection (modularity) Leiden leiden Community detection, more stable than Louvain Label Propagation label propagation Fast community detection by label spreading K Means kmeans Cluster nodes by node properties Triangle Count triangle count Local clustering / dense subgraphs Centrality Algorithm Procedure Use case PageRank page rank Rank nodes by influence Article Rank article rank PageRank variant, discounts high degree neighbours Betweenness betweenness Find bridge nodes Degree degree Count direct connections Pathfinding Algorithm Procedure Use case Dijkstra Source Target dijkstra Shortest path(s) from source to target(s) or pairs Dijkstra Single Source dijkstra single source Shortest paths from one node to all others Delta Stepping SSSP delta stepping Parallel single source shortest paths Breadth First Search bfs BFS traversal from a source Yen's K Shortest Paths yens Top K shortest loopless paths Max Flow max flow Maximum flow with capacities Min Cost Max Flow max flow min cost Max flow minimising total cost FastPath fastpath Fast approximate shortest paths Similarity Algorithm Procedure Use case Node Similarity node similarity Similar nodes by shared neighbours Filtered Node Similarity node similarity filtered Node similarity with source/target filters KNN knn K most similar nodes Filtered KNN knn filtered KNN with source/target filters Node Embeddings Algorithm Procedure Use case FastRP fast rp Fast node embeddings Node2Vec node2vec Random walk node embeddings HashGNN hashgnn GNN inspired embeddings without training GraphSAGE (Graph ML) Algorithm Procedure Use case Node Classification — train gs nc train Train supervised node label model Node Classification — predict gs nc predict Predict labels with a trained model Unsupervised embeddings — train gs unsup train Train unsupervised embedding model Unsupervised embeddings — predict gs unsup predict Infer embeddings with a trained model Model catalog (GraphSAGE) show models , model exists , drop model . Algorithm Specific Notes GraphSAGE Projected node tables used by GraphSAGE must not contain ARRAY property columns — use VECTOR(FLOAT, n) for multi valued numeric features. ( ARRAY is fine for non GraphSAGE algorithms.) Feature columns must be non NULL and finite — filter, impute, or exclude nullable feature columns in the view. For gs nc train , the targetProperty is a label (not a feature) and may be NULL. Before running, list the node properties GraphSAGE will use per node table: all non NODEID columns; for gs nc train exclude the targetProperty . Training ( gs nc train , gs unsup train ) can be slow and may use a GPU pool ( GPU NV S ). Show the exact CALL and get explicit confirmation before running training. Dijkstra Source Target ( dijkstra ) Provide one of: single pair: sourceNode + sourceNodeTable , targetNode + targetNodeTable ; one source, many targets: sourceNode + sourceNodeTable , targetNodes (list) + targetNodesTable ; many p

neo4j-snowflake-graph-analytics-skill