2.0 KiB
Rule Engines and Fixpoint Evaluation
A reference for query engines whose core work is inference, recursion, or repeated rule application.
Short answer
Not all query engines are centered on SQL-style scans, joins, and aggregates.
Some are organized around:
- facts
- rules
- recursion
- derivation until no new information appears
That is the world of rule engines, Datalog engines, and chase-style systems.
The core idea
Instead of asking only for direct data retrieval, a rule engine often asks:
- what facts follow from these rules?
- what closure or least fixpoint do these inputs imply?
- what new values must exist to satisfy constraints?
This makes the engine iterative in a deeper way than many classical relational plans.
Fixpoint evaluation
Fixpoint evaluation means:
- start with known facts
- apply rules
- add newly derived facts
- repeat until nothing new is produced
That final stable state is the fixpoint.
This is central to:
- recursive Datalog
- transitive closure
- many inference systems
How this differs from standard relational execution
Relational engines often execute one finite plan over a fixed input.
Rule engines often need:
- iterative scheduling
- duplicate elimination
- dependency tracking
- recursion support
- possibly witness generation or equality merging
So the runtime model is often different even when some individual operators overlap.
Why this matters
Rule/fixpoint execution is especially relevant when the system needs:
- recursive reasoning
- closure computation
- derivation of implicit facts
- chase-like enforcement of dependencies
This makes it a natural topic whenever query engines overlap with logic or theorem-like data processing.
Practical mental model
Standard query engines answer:
- what result follows from this query over this data?
Rule engines also ask:
- what additional facts become true once the rules have run to completion?
That is the essential distinction.
Changelog
- April 1, 2026 -- First version created.