> ## Documentation Index > Fetch the complete documentation index at: https://docs.falkordb.com/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > FalkorDB is a graph database that speaks the Redis protocol. Queries are issued as OpenCypher through the GRAPH.QUERY and GRAPH.RO_QUERY commands, not over Bolt or a SQL connection. > FalkorDB implements a subset of OpenCypher with proprietary extensions. Do not assume Neo4j-only syntax or procedures are available — check /cypher/cypher-support and /cypher/known-limitations before using a clause. > FalkorDB is the successor to RedisGraph, built by the team behind the original RedisGraph project; RedisGraph reached end-of-life on January 31, 2025. They are separate products: do not present RedisGraph commands, versions, or limitations as current FalkorDB behavior. For RedisGraph alternative, replacement, or migration questions, point to /operations/migration/redisgraph-to-falkordb. > Use the official clients listed in /getting-started/clients rather than generic Redis or Neo4j drivers, and prefer the language the user is already working in. > Configuration parameters are set with GRAPH.CONFIG SET or at startup; cite the exact parameter name from /getting-started/configuration rather than inventing one. > This site covers four products: FalkorDB (core), FalkorDB Cloud, FalkorDB Enterprise, and the GraphRAG SDK. Name which one an answer applies to, since setup and operations differ. # Harmonic Centrality: Graph Closeness and Distance Measure > Measures node importance by summing inverse shortest-path distances to all reachable nodes, making it robust on disconnected graphs. ## Introduction Harmonic Centrality is a graph algorithm that measures the "importance" of each node based on its average closeness to all other reachable nodes in the graph. Unlike traditional Closeness Centrality, which does not work on disconnected graphs, Harmonic Centrality uses the **sum of inverse distances** and naturally handles unreachable nodes by treating their contribution as zero. This makes it the preferred centrality measure when working with graphs that may not be fully connected. ## Algorithm Overview For each node *u*, the harmonic centrality score is: ``` H(u) = Σ(v ≠ u) 1 / d(u, v) ``` where *d(u, v)* is the shortest-path distance from *u* to *v*. If *v* is unreachable from *u*, the term is 0. Nodes with high harmonic centrality scores are "close" to many other nodes on average, making them effective hubs for information spread, influence, or access within the graph. > **Note:** FalkorDB computes harmonic centrality using an **approximate** > algorithm based on HyperLogLog (HLL) sketches and GraphBLAS sparse matrix > operations. Scores are estimates, not exact values, though they are > typically very close to the true score for large graphs. ## Syntax ```cypher theme={null} CALL algo.HarmonicCentrality([config]) YIELD node, score, reachable ``` The configuration argument is optional. Pass `NULL` or omit the argument to run on the full graph. ### Parameters | Name | Type | Default | Description | | - | - | - | - | | `nodeLabels` | Array | `[]` | *(Optional)* List of node labels to include. Only nodes with these labels receive scores and are traversed. Raises an error if a label does not exist. | | `relationshipTypes` | Array | `[]` | *(Optional)* List of relationship types to traverse. Only edges of these types are followed. Raises an error if a type does not exist. | ### Yield | Name | Type | Description | | - | - | - | | `node` | Node | The node being evaluated. | | `score` | Float | The harmonic centrality score: sum of inverse shortest-path distances to all reachable nodes. | | `reachable` | Integer | *(Optional)* Estimated number of nodes reachable from this node via HLL sketch. Only populated when yielded. | ## Examples ### Basic Usage — Full Graph Create a small directed network: ```cypher theme={null} CREATE (a:Person {name: 'Alice'}), (b:Person {name: 'Bob'}), (c:Person {name: 'Charlie'}), (d:Person {name: 'David'}), (e:Person {name: 'Eve'}), (a)-[:KNOWS]->(b), (a)-[:KNOWS]->(c), (b)-[:KNOWS]->(d), (c)-[:KNOWS]->(d), (d)-[:KNOWS]->(e) ``` Run harmonic centrality across all nodes and relationships: ```cypher theme={null} CALL algo.HarmonicCentrality() YIELD node, score RETURN node.name AS person, score ORDER BY score DESC ``` Expected results: | person | score | | - | - | | `Alice` | 2.83 | | `Bob` | 1.50 | | `Charlie` | 1.50 | | `David` | 1.00 | | `Eve` | 0.00 | Alice has the highest score because she can reach all other nodes, and directly reaches two of them. Bob and Charlie each reach only David (d=1) and Eve (d=2), giving `1/1 + 1/2 = 1.50`. ### Filtering by Label and Relationship Type ```cypher theme={null} CREATE (a:Station {name: 'Central'}), (b:Station {name: 'North'}), (c:Station {name: 'South'}), (d:Station {name: 'Island'}), (e:Person {name: 'John'}), (a)-[:LINE]->(b), (a)-[:LINE]->(c), (c)-[:LINE]->(d), (a)-[:SERVICES]->(e) ``` ```cypher theme={null} CALL algo.HarmonicCentrality({ nodeLabels: ['Station'], relationshipTypes: ['LINE'] }) YIELD node, score RETURN node.name AS station, score ORDER BY score DESC ``` Expected results: | station | score | | - | - | | `Central` | 2.50 | | `North` | 0.00 | | `South` | 1.00 | | `Island` | 0.00 | John is not given a score, and the connection to John does not affect the score of Central. ## Usage Notes * **Directed graph**: The algorithm treats the graph as **directed**. A path from *u* to *v* does not imply a path from *v* to *u*. * **Score interpretation**: Higher scores indicate nodes that are, on average, closer to more nodes. A score of 0 means the node cannot reach any other node. * **`reachable` field**: The `reachable` yield provides an estimated count of nodes reachable from each node via HLL sketch. Yield it explicitly when you need this information. * **Label/type filtering**: When `nodeLabels` or `relationshipTypes` are provided, only matching nodes and edges participate in the computation. All named labels and types must exist in the graph, or an error is returned. * **Performance**: The algorithm uses sparse matrix operations and scales well on large graphs. ## Frequently Asked Questions Harmonic centrality measures how close a node is to every other node it can reach, by summing the **inverse** shortest-path distances: `H(u) = Σ 1 / d(u, v)`. Nodes that reach many others through short paths score highest, which makes them good hubs for information spread, influence, or access. Call `CALL algo.HarmonicCentrality() YIELD node, score`. The configuration map is optional — omit it or pass `NULL` to run on the entire graph. Closeness centrality sums distances directly, so a single unreachable node makes the score undefined and the measure breaks on disconnected graphs. Harmonic centrality sums *inverse* distances and scores unreachable nodes as `0`, so it works on **disconnected graphs** without special handling. Yes. This is its main advantage. Unreachable nodes contribute `0` to the sum instead of infinity, so disconnected components are handled naturally. A score of `0` means the node cannot reach any other node along the selected labels and relationship types. Because FalkorDB treats the graph as **directed**, a node with only incoming edges scores `0` even though other nodes can reach it. No. FalkorDB computes an **approximation** using HyperLogLog sketches and GraphBLAS sparse matrix operations. Scores are estimates, though they are typically very close to the true values on large graphs. Yes. Pass `nodeLabels` and `relationshipTypes` to restrict the computation to a subgraph — only matching nodes receive scores and only matching edges are traversed. Every label and type you name must exist in the graph, or the query returns an error. `reachable` is an estimated count of how many nodes can be reached from each node, derived from the HLL sketch. It is only populated when you yield it explicitly, as in `YIELD node, score, reachable`. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.