Leiden

SQL function: cugraph_leiden

Official cuGraph reference: C API

Find modularity-based communities with refinement steps that improve the internal connectedness of the partitions.

Signature

cugraph_leiden(table_name [, src_col, dst_col [, weight_col [, options_json]]])

Relation inputs

The first positional argument names a registered edge table or view (the edges role). Parenthesized relation subqueries are not accepted; metadata validation uses the same registered name.

Vertex ID types

The edges relation declares the accepted vertex-ID domains. Numeric calls preserve the existing numeric schema. When logical string support is declared, Utf8, LargeUtf8, and Utf8View endpoint columns share one logical domain; their vertex-identity outputs are canonicalized to Utf8.

Domain	Accepted endpoint inputs	Output contract
Numeric edge endpoints	Int32, Int64	The numeric output schema is used for numeric calls.
Logical string edge endpoints	Utf8, LargeUtf8, Utf8View	Vertex identity columns are canonicalized to Utf8; scores, distances, counts, coordinates, and opaque labels remain numeric.

The native mapping type is Int64. Call-specific output schemas come from gpu_validate_call.

Logical string side-input limitations:

• edge ID columns and edge-ID predicate side inputs are not supported for logical string graphs

Scalar arguments & JSON options

Positional scalar arguments

src_col and dst_col name the edge endpoint columns; both are optional and default to src and dst.

Argument	Type	Required	Default	Notes
weight_col	Utf8|null	no		accepted as an edge-column binding; native algorithm execution does not consume weights; semantic effect: none for this algorithm

JSON options

Option	Type	Default	Constraints	Description
max_level	UInt32	100	min 1
resolution	Float64	1	> 0
seed	UInt64	0
theta	Float64	1	> 0

Graph construction options

This function builds an undirected graph by default (directed=false); all other graph construction options follow the shared defaults documented in Graph Construction Options.

Output schema

Column	Type	Nullable	Description
vertex	Int64|Utf8	no	Vertex assigned to a Leiden community.
partition	Int64	no	Community identifier assigned by Leiden.

These are generic descriptor schemas; validate the call to get the concrete, table-specific output schema.

Examples

This example runs on the citation network demo dataset.

Where Leiden disagrees with Louvain

Leiden takes the same call shape as cugraph_louvain but adds a refinement phase that guarantees well-connected communities, splitting clusters Louvain merges. Joining the two partitions on vertex shows exactly where. The views are the Louvain example's 2010s AI subgraph:

CREATE OR REPLACE VIEW ai_nodes AS
SELECT paper_id FROM papers
WHERE year >= 2010 AND primary_fos IN (
  'Deep learning', 'Artificial neural network', 'Convolutional neural network',
  'Recurrent neural network', 'Natural language processing',
  'Reinforcement learning', 'Image segmentation', 'Feature extraction',
  'Object detection', 'Speech recognition');

CREATE OR REPLACE VIEW ai_edges AS
SELECT e.src, e.dst
FROM citation_edges e
JOIN ai_nodes a ON a.paper_id = e.src
JOIN ai_nodes b ON b.paper_id = e.dst;

WITH lv AS (
  SELECT vertex, "partition" AS louvain_c FROM cugraph_louvain('ai_edges', 'src', 'dst')),
ld AS (
  SELECT vertex, "partition" AS leiden_c FROM cugraph_leiden('ai_edges', 'src', 'dst')),
joint AS (
  SELECT lv.louvain_c, ld.leiden_c, COUNT(*) AS n
  FROM lv JOIN ld ON ld.vertex = lv.vertex
  GROUP BY lv.louvain_c, ld.leiden_c)
SELECT louvain_c,
       SUM(n) AS members,
       COUNT(*) FILTER (WHERE n >= 50) AS leiden_parts
FROM joint
GROUP BY louvain_c
HAVING SUM(n) > 2500
ORDER BY leiden_parts DESC, members DESC;

louvain_c	members	leiden_parts
0	10,684	8
1	6,707	7
3	5,118	3
2	3,960	3

Louvain's 10,684-paper computer-vision community shatters into eight Leiden communities of 50+ members; overall the same graph yields 1,960 Louvain communities versus 2,670 for Leiden. When a Louvain community is only held together by a few incidental citations, Leiden's refinement phase is what separates it — the guarantee that every returned community is internally connected is the reason to prefer Leiden as the default. Both runs are deterministic here (seed defaults to 0), which is why the community ids in this table are stable across sessions.

Limitations & lifecycle

No algorithm-specific limitations.

Validate before running

Dry-run validation checks registered relation metadata, column presence, static dtypes, and options only; it does not scan edge data, construct a graph, or prove source-vertex existence:

SELECT * FROM gpu_validate_call(
  'cugraph_leiden',
  '{"schema_version":1,"relations":{"edges":{"table":"target_edges"}},"options":{"src_col":"src","dst_col":"dst"}}'
);

See GPU Function Catalog API for the full gpu_validate_call contract.