neo4j-snowflake-graph-analytics-skill

Name: neo4j-snowflake-graph-analytics-skill
Author: neo4j-contrib

281installs33forks

How to install neo4j-snowflake-graph-analytics-skill?

neo4j-contrib/neo4j-skills/neo4j-snowflake-graph-analytics-skill

$npx -y skills add neo4j-contrib/neo4j-skills --skill neo4j-snowflake-graph-analytics-skill

Installs into the current project.

Summary

Run Neo4j Graph Analytics algorithms (PageRank, Louvain, WCC, Dijkstra, KNN,

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	Docs: https://neo4j.com/docs/snowflake-graph-analytics/current/
4
5	---
6
7	## When to Use
8	- Running graph algorithms / GDS in Snowflake
9	- Data already lives in Snowflake tables
10	- On-demand / pipeline workloads — ephemeral sessions, pay per session-minute
11	- Full isolation from the live database during analytics
12
13	## When NOT to Use
14	- Aura Pro with embedded GDS plugin → `neo4j-gds-skill`
15	- Aura Graph Analytics → `neo4j-aura-graph-analytics-skill`
16	- Self-managed Neo4j with embedded GDS plugin → `neo4j-gds-skill`
17	- Writing Cypher queries → `neo4j-cypher-skill`
18
19	---
20
21	## The End-to-End Flow
22
23	This is the flow that works. Don't jump straight to a `CALL` — most failures come from skipping the data-preparation step.
24
25	1. Explore the source data — inspect table DDLs to learn columns and types.
26	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.
27	3. Project → Compute → Write — run the algorithm with a single `CALL`, assembling the `project`, `compute`, and `write` config.
28	4. Inspect & look up names — join numeric results back to the source table to get human-readable labels.
29
30	---
31
32	## Step 1 — Explore the Source Data
33
34	Look at the table definitions before designing the graph:
35
36	```sql
37	SELECT GET_DDL('TABLE', 'MY_DATABASE.MY_SCHEMA.MY_TABLE');
38	-- or inspect columns/types:
39	SELECT COLUMN_NAME, DATA_TYPE
40	FROM MY_DATABASE.INFORMATION_SCHEMA.COLUMNS
41	WHERE TABLE_SCHEMA = 'MY_SCHEMA' AND TABLE_NAME = 'MY_TABLE';
42	```
43
44	Decide which tables are nodes and which represent relationships (edges) between them.
45
46	---
47
48	## Step 2 — Prepare Projection Views (the important part)
49
50	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.
51
52	Create views that reshape your tables into the node/relationship format:
53
54	```sql
55	CREATE OR REPLACE VIEW MY_DATABASE.MY_SCHEMA.MY_NODES_VW AS
56	SELECT ... FROM MY_DATABASE.MY_SCHEMA.MY_TABLE;
57	```
58
59	### Node views
60
61	- Key column: expose the primary key as `NODEID`. It must be `BIGINT` or `STRING`. Always alias and cast explicitly:
62	`SOURCE_COL::BIGINT AS NODEID` or `SOURCE_COL::STRING AS NODEID`.
63	- Allowed node property types (exactly): `BIGINT`, `DOUBLE`, `ARRAY`, `VECTOR(FLOAT, n)`. Anything else must be cast to one of these or dropped.
64	- Composite keys: concatenate parts with `'++'`.
65	- Naming: `<table>_NODES_VW`.
66
67	### Source-type → view-type casting rules
68
69	Apply these when projecting columns from your tables (keep the original column name unless renaming):
70
71	\| Source type \| Action \|
72	\|---\|---\|
73	\| Whole-number numerics (`INT`, `INTEGER`, `BIGINT`, `SMALLINT`, `TINYINT`, `BYTEINT`, `NUMBER(p,0)`) \| `CAST(col AS BIGINT) AS col` \|
74	\| Fractional numerics (`FLOAT`, `DOUBLE`, `REAL`, `DECIMAL(p,s>0)`, `NUMBER(p,s>0)`) \| `CAST(col AS DOUBLE) AS col` \|
75	\| `ARRAY` of numbers \| keep as `ARRAY` (except GraphSAGE — see below). Not allowed on relationship views. \|
76	\| `VECTOR(FLOAT, n)` \| keep as-is. Not allowed on relationship views. \|
77	\| `BOOLEAN` \| drop by default. Opt-in only: `IFF(col, 1, 0)::BIGINT AS col` \|
78	\| `DATE`, `TIME`, `TIMESTAMP` \| drop by default*. Opt-in only: `DATE_PART('EPOCH_SECOND', col)::BIGINT AS col` (tell the user the unit) \|
79	\| `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) \|
80	\| `VARIANT`, `OBJECT`, `GEOGRAPHY`, `GEOMETRY`, `BINARY` \| drop — not supported as graph properties \|
81
82	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.
83
84	### Relationsh

People who liked this also viewed

6 picks

Type

azure-storageAzure Storage Services including Blob Storage, File Shares, Queue Storage, Table Storage, and Data Lake. Answers questions about storage access tiers (hot, cool, cold, archive), when to use each tier,SkillsJul 2026471k1.3k
supabase-postgres-best-practicesPostgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.SkillsJul 2026302k2.4k
supabaseUse when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, SkillsJul 2026179k2.4k
convex-quickstartCreates or adds Convex to an app. Use for new Convex projects, npm create convex@latest, frontend setup, env vars, or the first npx convex dev run.SkillsJul 202690k39
convex-performance-auditAudits Convex performance for reads, subscriptions, write contention, and function limits. Use for slow features, insights findings, OCC conflicts, or read amplification.SkillsJul 202689k39
convex-setup-authSets up Convex auth, identity mapping, and access control. Use for login, auth providers, users tables, protected functions, or roles in a Convex app.SkillsJul 202689k39

neo4j-snowflake-graph-analytics-skill

281installs33forks

View on GitHub

How to install neo4j-snowflake-graph-analytics-skill?

neo4j-contrib/neo4j-skills/neo4j-snowflake-graph-analytics-skill

$npx -y skills add neo4j-contrib/neo4j-skills --skill neo4j-snowflake-graph-analytics-skill

Installs into the current project.

Summary

Run Neo4j Graph Analytics algorithms (PageRank, Louvain, WCC, Dijkstra, KNN,

Files · 1

View on GitHub

SKILL.md

1	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.
2
3	Docs: https://neo4j.com/docs/snowflake-graph-analytics/current/
4
5	---
6
7	## When to Use
8	- Running graph algorithms / GDS in Snowflake
9	- Data already lives in Snowflake tables
10	- On-demand / pipeline workloads — ephemeral sessions, pay per session-minute
11	- Full isolation from the live database during analytics
12
13	## When NOT to Use
14	- Aura Pro with embedded GDS plugin → `neo4j-gds-skill`
15	- Aura Graph Analytics → `neo4j-aura-graph-analytics-skill`
16	- Self-managed Neo4j with embedded GDS plugin → `neo4j-gds-skill`
17	- Writing Cypher queries → `neo4j-cypher-skill`
18
19	---
20
21	## The End-to-End Flow
22
23	This is the flow that works. Don't jump straight to a `CALL` — most failures come from skipping the data-preparation step.
24
25	1. Explore the source data — inspect table DDLs to learn columns and types.
26	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.
27	3. Project → Compute → Write — run the algorithm with a single `CALL`, assembling the `project`, `compute`, and `write` config.
28	4. Inspect & look up names — join numeric results back to the source table to get human-readable labels.
29
30	---
31
32	## Step 1 — Explore the Source Data
33
34	Look at the table definitions before designing the graph:
35
36	```sql
37	SELECT GET_DDL('TABLE', 'MY_DATABASE.MY_SCHEMA.MY_TABLE');
38	-- or inspect columns/types:
39	SELECT COLUMN_NAME, DATA_TYPE
40	FROM MY_DATABASE.INFORMATION_SCHEMA.COLUMNS
41	WHERE TABLE_SCHEMA = 'MY_SCHEMA' AND TABLE_NAME = 'MY_TABLE';
42	```
43
44	Decide which tables are nodes and which represent relationships (edges) between them.
45
46	---
47
48	## Step 2 — Prepare Projection Views (the important part)
49
50	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.
51
52	Create views that reshape your tables into the node/relationship format:
53
54	```sql
55	CREATE OR REPLACE VIEW MY_DATABASE.MY_SCHEMA.MY_NODES_VW AS
56	SELECT ... FROM MY_DATABASE.MY_SCHEMA.MY_TABLE;
57	```
58
59	### Node views
60
61	- Key column: expose the primary key as `NODEID`. It must be `BIGINT` or `STRING`. Always alias and cast explicitly:
62	`SOURCE_COL::BIGINT AS NODEID` or `SOURCE_COL::STRING AS NODEID`.
63	- Allowed node property types (exactly): `BIGINT`, `DOUBLE`, `ARRAY`, `VECTOR(FLOAT, n)`. Anything else must be cast to one of these or dropped.
64	- Composite keys: concatenate parts with `'++'`.
65	- Naming: `<table>_NODES_VW`.
66
67	### Source-type → view-type casting rules
68
69	Apply these when projecting columns from your tables (keep the original column name unless renaming):
70
71	\| Source type \| Action \|
72	\|---\|---\|
73	\| Whole-number numerics (`INT`, `INTEGER`, `BIGINT`, `SMALLINT`, `TINYINT`, `BYTEINT`, `NUMBER(p,0)`) \| `CAST(col AS BIGINT) AS col` \|
74	\| Fractional numerics (`FLOAT`, `DOUBLE`, `REAL`, `DECIMAL(p,s>0)`, `NUMBER(p,s>0)`) \| `CAST(col AS DOUBLE) AS col` \|
75	\| `ARRAY` of numbers \| keep as `ARRAY` (except GraphSAGE — see below). Not allowed on relationship views. \|
76	\| `VECTOR(FLOAT, n)` \| keep as-is. Not allowed on relationship views. \|
77	\| `BOOLEAN` \| drop by default. Opt-in only: `IFF(col, 1, 0)::BIGINT AS col` \|
78	\| `DATE`, `TIME`, `TIMESTAMP` \| drop by default*. Opt-in only: `DATE_PART('EPOCH_SECOND', col)::BIGINT AS col` (tell the user the unit) \|
79	\| `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) \|
80	\| `VARIANT`, `OBJECT`, `GEOGRAPHY`, `GEOMETRY`, `BINARY` \| drop — not supported as graph properties \|
81
82	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.
83
84	### Relationsh

People who liked this also viewed

6 picks

Type