Degree Centrality

Compute in-degree, out-degree, and total degree for all nodes

Category: centrality

Syntax

SELECT * FROM graph_degree(table_name)

Description

Degree centrality is the simplest and most computationally efficient centrality measure. It counts the number of edges incident to each node, split into in-degree (edges arriving at the node), out-degree (edges leaving the node), and total degree (the sum of both). In directed graphs, in-degree and out-degree reveal different structural roles: high in-degree indicates popularity or authority, while high out-degree indicates activity or hub behavior. The function loads edge data from a registered Delta table into a Compressed Sparse Row (CSR) representation. The degree counts are derived directly from the CSR offset arrays, making the computation a single linear scan over the graph structure. Column names for source and target are auto-detected from standard conventions (src/source/src_id, dst/target/dst_id). The time complexity is O(V + E), where V is the vertex count and E is the edge count. This makes degree centrality the fastest graph algorithm available and suitable as a first-pass filter before running more expensive algorithms such as PageRank or betweenness centrality. It is practical for graphs of any size that fit in memory. GPU acceleration is not available for degree centrality because the computation is already memory-bandwidth-bound on the CPU and completes in negligible time. The graph cache (256 MB default budget, LRU eviction, 10-minute idle timeout) retains the CSR topology, so repeated degree queries on the same table skip the graph loading phase entirely.

Parameters

Name	Type	Description
`table_name`		Specify the name of the registered Delta table containing edge data. The table must include source and target columns (auto-detected as src/source/src_id and dst/target/dst_id). Weight columns are ignored for degree computation.

Examples

CREATE TABLE follow_edges AS
SELECT * FROM VALUES
  (1, 2, 1.0),
  (1, 3, 1.0),
  (2, 3, 1.0),
  (3, 1, 1.0),
  (4, 1, 1.0),
  (4, 2, 1.0)
AS t(src, dst, weight);

SELECT * FROM graph_degree('follow_edges');

SELECT node_id, out_degree
FROM graph_degree('follow_edges')
ORDER BY out_degree DESC
LIMIT 5;

SELECT node_id, in_degree
FROM graph_degree('follow_edges')
ORDER BY in_degree DESC
LIMIT 5;

SELECT node_id
FROM graph_degree('follow_edges')
WHERE total_degree = 0;

SELECT
  d.node_id,
  d.in_degree,
  d.out_degree,
  p.score AS pagerank
FROM graph_degree('follow_edges') d
JOIN graph_pagerank('follow_edges') p
  ON d.node_id = p.node_id
ORDER BY p.score DESC;

Pitfalls

Degree counts are unweighted. Edge weights in the source table are ignored, so a node with many low-weight edges and a node with few high-weight edges receive the same total_degree. Use weighted sums in a GROUP BY over the edge table directly if a weighted degree is required.
Parallel edges are counted as separate edges. If the underlying table contains duplicate (src, dst) rows, each duplicate increments the degree. Deduplicate the edge table before invocation when the intent is a simple graph.
Self-loops increment both in_degree and out_degree by one, producing a total_degree of 2 for a single self-edge. This matches the multigraph convention but can surprise users expecting loops to count once.
In undirected graphs loaded as two directed rows (one per direction), in_degree and out_degree are symmetric and total_degree equals 2 * |incident edges|. Divide by two or use only one direction in the source table if the true undirected degree is required.
GPU acceleration is not available. The ON GPU execution hint is silently ignored because the algorithm is already a linear scan over CSR offsets and is rarely the bottleneck.