---
title: degree_centrality
url: https://nexyron.tech/docs/cypher/procedures/algorithms/centrality/degree-centrality
description: Centrality procedures rank nodes by structural importance. They are useful for influence, dependency, bottleneck, and exposure analysis, but each metric encodes a different meaning
---

# degree_centrality

## Generic Description

Score nodes by edge counts.

Simple example:

```cypher
CALL nexyron.degree_centrality()
```

Centrality procedures rank nodes by structural importance. They are useful for influence, dependency, bottleneck, and exposure analysis, but each metric encodes a different meaning of importance.

## Consumer-Level Explanation

Use `degree_centrality` when score nodes by edge counts is the graph-analysis or operational question you actually need to answer. Keep the call explicit because its `YIELD` columns, row grain, and required runtime state determine how the rest of the Cypher pipeline can safely compose it. Do not treat centrality scores as interchangeable: degree measures direct volume, PageRank and eigenvector-style scores reward endorsement by important neighbors, betweenness finds bridge nodes, and closeness/harmonic scores emphasize reachability.

## Conceptual Explanation

`degree_centrality` should be read as one named procedure contract in the broader Nexyron Cypher surface. The procedure call is not only a syntax hook: it defines what runtime state, projection, registry entry, or graph algorithm is being asked to operate, and it determines which output columns downstream `YIELD`, `WITH`, and `RETURN` stages can safely use.

## More Detailed Explanation

This is the simplest centrality family and differs from PageRank-like metrics by ignoring recursive importance

In practical queries, start by deciding the row grain you want after the call: one row per node, one row per path, one row per registry object, one row per artifact, or one row per summary. Then keep that grain explicit with `YIELD` and named projections. That is the difference between a useful planner-facing example and a vague call that downstream tooling cannot safely compose. For contract-driven procedures, the executable examples on these pages intentionally inspect procedure metadata unless the required named artifacts are created in the same example.

## How It Differs From Nearby Algorithms

This is the simplest centrality family and differs from PageRank-like metrics by ignoring recursive importance.

## Advanced Example

This example yields named columns from `degree_centrality` and returns a bounded result shape that downstream planner tooling can compose without guessing column names or row grain.

```cypher
CALL nexyron.degree_centrality() YIELD node_id, in_degree, out_degree, total_degree
RETURN node_id, in_degree, out_degree, total_degree
LIMIT 10
```

## Real Use Cases

-   quick hub detection
-   cheap baseline ranking
-   sanity-checking richer centrality measures
-   compare algorithm output with domain labels or time windows before operationalizing it
-   feed graph-analytic scores into ranked reports, feature contracts, or investigation queues only after checking the modeling assumptions

## Real Limitations And Tradeoffs

-   degree can overvalue noisy high-volume nodes
-   it does not tell you whether the neighbors matter
-   algorithm output reflects the projected graph, not an abstract real-world network outside the data model
-   nearby algorithms can answer different questions even when their output columns look similar