Skip to content

Why Graph Databases Can Use Much Less Power Than Distributed Rule Engines

A motivating question

Imagine two computer systems that both answer the same question:

“Given this data, what decision should the system make?”

Both systems are correct. Both meet the same functional requirements.
But one of them uses far less electricity to do the same work.

Why?

To understand this, we will compare two real architectural patterns and look at where energy is actually spent.

Two ways to make a decision

System A: In-memory graph with built-in rules

In this system:

  • All data lives in a single in-memory graph
  • Rules are encoded directly as graph traversals (often as decision trees)
  • A decision is made by walking the graph in memory
  • There are no network calls on the critical path

You can think of this as:

“The data and the rules live in the same place, and the system just follows links.”

System B: Distributed RDBMS with external rule engines

In this system:

  • Data is stored in relational databases
  • Rules are implemented in separate services
  • A single decision requires many network calls
  • On average, one decision makes about 10 network calls
  • Some decisions make 4–5 calls
  • Some make 10–20 calls
  • These services may be spread across multiple data centers
  • Networks are not perfectly reliable, so timeouts and retries happen

You can think of this as:

“To make one decision, the system has to ask many other systems for help.”

Where does the energy go?

A common misconception is that computers mostly use energy to “do math.”
In modern systems, this is not true.

Key idea

Moving data costs much more energy than computing on data.

Every time data moves: - It must be serialized - Sent over a network - Wait in queues - Be processed remotely - Sent back - Possibly retried if something fails

All of that uses energy — and eventually becomes heat.

A simple mental model

Let’s compare how much work each system does to make one decision.

System A (graph-based)

  • One request enters the system
  • The CPU follows pointers in memory
  • The decision is made locally
  • The result is returned

This is mostly: - Memory access - Local computation

System B (distributed rules)

  • One request enters the system
  • The system makes ~10 network calls
  • Each call involves:
  • Packaging data
  • Sending it across the network
  • Waiting for another system
  • Receiving and unpacking a response
  • Some calls are slower than others
  • Some calls may fail and be retried

This is mostly: - Waiting - Coordination - Data movement

Why waiting costs power

Servers do not turn off while waiting.

To meet performance goals (for example, “95% of decisions must finish in under 100 ms”), distributed systems must:

  • Keep extra servers powered on
  • Maintain headroom for slow or failed requests
  • Handle retries and timeouts

This means: - More machines running - More idle power being consumed - More heat being generated

A ballpark energy comparison

We can compare the two systems using a practical metric:

Energy per decision

Using simple, conservative assumptions:

  • System B averages 10 network calls per decision
  • Each call adds several milliseconds of delay
  • Calls are often sequential, not perfectly parallel
  • Some retries and tail-latency buffering are required

When engineers model this realistically, they usually find:

Expected power-efficiency gap

  • Conservative estimate: 3× less energy per decision
  • Reasonable midline estimate: 5× less energy per decision
  • Aggressive but plausible estimate: 10× less energy per decision

In other words:

A single-node in-memory graph system can often make the same decision using one-fifth (or less) of the energy of a distributed rule-engine system.

Why graphs help (intuitively)

Graphs help not because they are “faster at math,” but because they:

  • Co-locate data and rules
  • Reduce communication
  • Preserve locality
  • Avoid distributed coordination

A decision becomes:

“Walk the graph”

Instead of:

“Ask ten different systems, wait for replies, and hope none fail.”

Why this matters beyond electricity

Lower energy per decision usually means:

  • Lower power and cooling costs
  • Fewer servers required
  • More predictable latency
  • Less operational complexity
  • Better scalability under load

Energy efficiency is often a proxy for good system design.

Key takeaway

In modern systems, power is not mostly spent on thinking — it is spent on moving information and waiting for it.

By keeping both data and rules inside a single in-memory graph, graph databases can dramatically reduce data movement, coordination, and waste. For decision-heavy workloads, this often leads to 3×–10× better power efficiency, with about 5× being a reasonable planning estimate.

Reflection question

If moving data is so expensive, what kinds of applications benefit most from graph-based designs?

Think about: - Recommendation systems - Fraud detection - Process monitoring - Knowledge graphs - AI decision pipelines