We went Edgemaxxing and FalkorDB mogged Joins

NIKITHA — Sun, 18 Oct 2026 15:43:48 +0000

Edgemaxxing is actually very good when it comes to performance. To explain this, we were developing Nodes Don't Lie for the WeHack Hackathon using Falkor DB. The service we were creating allowed users to compare different sets of scientific papers in order to see which ones refute and which ones support the others. When we were working on the data modelling for this system we encountered these issues and solutions.

Part 1: Edgemaxxing begins

Problama

Let's consider an example: "Lean mass increased by 0.37 kg."

The finding lends support to the hypothesis H2 (that creatine increases muscle gain).
In the case of another hypothesis, for example 'creatine harms the kidneys', it is not relevant.

You cannot select "Supports" by themselves. It only functions when it is used in conjunction with a hypothesis.

PS: Terms

They are relevant to the problems we're working on so it's useful to know, but the solution should also be applicable in other situations as well!

Word	Meaning	Example
Question	User input	"creatine on intelligence vs muscle gain"
Hypothesis	Verifiable claim from the question	H2: "Creatine increases muscle gain in adults"
Paper	A published article	Chen 2026 (a meta-analysis)
Study	Experiment from the paper	An RCT with 15 vegans
Finding	Measured result from a study	"Skeletal muscle mass: no change"
Concept	A topic or measurement	"lean mass"

The bad solution

Put 'stance: "supports"' on the finding node. The issue here is that the second hypothesis won't function because it also detects 'supports', which is incorrect. In that case, you'd have to copy the finding once for each hypothesis, and the copies would gradually move apart over time.

So what did we do?

We placed the stance on the edge between the finding and the hypothesis, that is, Edgemaxxing:

(It was found that "lean mass increased by 0.37 kg") -[:EVIDENCE_FOR {stance: "supports", weight: 0.67}]-> (H2)

What this implies is that there will be a single node and, if necessary, several outgoing edges each having a different stance for each hypothesis.

Whilst many databases are not capable of storing properties on an edge, FalkorDB is a property graph and therefore edges can hold data just as nodes can. It is because of this feature that the design can be achieved.

What is the situation in which it is used?

We are able to share papers and findings among all the questions. If a new question requires a paper that has already been read, then we can reuse it; all we have to do is add an 'EVIDENCE_FOR' edge to the Hypothesis and that's it ;3

Part 2: Edgemaxx the contradictions too

problama

It is possible for two findings to differ regarding one hypothesis but to agree on another.

The hypotheses H2,"lean mass ↑" (Naddafha 2026) and "skeletal muscle mass: no change" (Chen 2026) contradict one another.
With regard to the kidney hypothesis, the same two findings are of no significance, so there is no disagreement.

What we did

Another edge-maxing! A contradiction is an edge between two findings and it records which hypothesis it is associated with:

(Naddafha finding) -[:CONTRADICTS {hypothesis: "H2", reason: "different population",
                                   explained_by: "postmenopausal women vs all women"}]-> (Chen finding)

The query:

MERGE (a)-[e:CONTRADICTS {hypothesis:$k}]->(b)
Set e.reason to ..., e.severity to ..., and e.explained_by to ...

The command MERGE means that it will create something only if that thing does not already exist.

The index

If we for example wish to look at all the contradictions involving H2, the app requests "give me every CONTRADICTS edge where hypothesis = H2". In the absence of indexing, FalkorDB would have to examine every contradiction edge in the entire graph.

So we created an index on that edge property:

Create an index on the relationship r:CONTRADICTS between two nodes.

While most databases are capable only of indexing nodes or rows, FalkorDB can index edges as well, and it is precisely this feature that enables the fast lookup.

Part 3: Normalizemaxxing the nodes

problama

Suppose that Paper A uses the term "fat-free mass", Paper B uses "lean body mass", and Paper C uses "FFM"; these refer to the same measurement but are named differently. In that case, the app would fail to recognise these differences if it only matched words exactly, since they would be treated as distinct nodes.

What we did

There is a synonyms list associated with each Concept node.
When the Stance agent evaluates a finding, it determines whether the hypothesis can be measured in some other form (that is, in terms of true or false).
If the answer is yes, the programme includes a special edge running from the result of the search to the outcome concept of the hypothesis:

   (Finding: "FFM increased by 1.15 kg") -[:MEASURES {hypothesis: "H2"}]-> (Concept: "muscle gain")

The code also includes the exact wording of the finding among the synonyms of the concept so that it can be retrieved the next time.

This MEASURES edge also includes hypothesis, for exactly the same reason as in Part 2: "FFM counts as muscle gain" is true for H2 but might not be true for some other hypothesis. It also has an edge index, once again Edgemaxxing!!!!!

Why this matters

The graph improves its knowledge of names with time, and each question enhances the synonym lists for the following question.

Part 4: Contradiction camps using algo.WCC

What it does

Imagine the contradiction edges as strings tied between findings:

When A contradicts B and B contradicts C, then A, B and C are all linked together.
A group of linked findings makes up one "camp": it is one area in which the evidence is contradictory.

The standard algorithm for finding these groups is WCC (weakly connected components).

The relevant point is that FalkorDB includes graph algorithms as part of its system, which means that the application executes the command CALL algo.WCC(...) directly within the database; it therefore does not need to download the entire graph and run the algorithm using Python.

The query:

Invoke algo.WCC with the parameters {nodeLabels: ['Finding'], relationshipTypes: ['CONTRADICTS']}
YIELD node, componentId
MATCH (node)-[e:EVIDENCE_FOR]->(h:Hypothesis)<-[:ASKS]-(:Question {id:$q})
WITH h, componentId, count(DISTINCT node) AS findings, collect(DISTINCT e.stance) AS stances
WHERE findings > 1
Return h.statement as hypothesis, componentId as camp, findings, stances

In simple terms, you should locate the camps within all the findings, retain only those that are relevant to this question, and then display the size of each camp along with its positions.

A limitation is that WCC includes all the CONTRADICTS edges for each hypothesis; if a single finding has contradictions under two different hypotheses then those two groups can combine into a single group.

How it all fits together

Paper ─DESCRIBES→ Study ─FOUND→ Finding ─EVIDENCE_FOR {stance}→ Hypothesis
                                   │
                                   ├─MEASURES {hypothesis}→ Concept {synonyms}
                                   │
                                   └─CONTRADICTS {hypothesis, reason, explained_by}→ Finding

Parting Notes

The essential aspect of graph databases is edges. Making effective use of them can make your life easier (and quicker!!!).

DEV Community: NIKITHA

We went Edgemaxxing and FalkorDB mogged Joins

Part 1: Edgemaxxing begins

Problama

PS: Terms

The bad solution

So what did we do?

Part 2: Edgemaxx the contradictions too

problama

What we did

The index

Part 3: Normalizemaxxing the nodes

problama

What we did

Why this matters

Part 4: Contradiction camps using algo.WCC

What it does

How it all fits together

Parting Notes