Comparison
Drools vs ArboRule: a library you operate, or a platform that operates it.
Drools has the best inference engine in this comparison and the least product around it. Since Drools 8 that gap is wider than most people evaluating it realise.
The short answer
Choose Drools when
- You need real inference. PHREAK is a lazy, goal-oriented evolution of Rete with layered memory, and nothing else in this comparison chains rules over an accumulating fact set the way it does.
- Facts interact over time. Truth maintenance retracts derived facts when their premises stop holding, and stream mode gives you sliding windows and temporal operators for monitoring, diagnostics and compliance.
- It has to be in-process, in Java. Drools embeds in your JVM with no network hop and no vendor between you and the decision.
- The licence is the requirement. Apache 2.0, now a sub-project of Apache KIE, with rule artifacts shipped as ordinary Maven-versioned JARs.
- Your rule authors are Java engineers. DRL is expressive and spreadsheet decision tables still compile, and neither needs a product to sit around them.
Choose ArboRule when
- A non-engineer owns the policy. Business Central is retired, and with it the guided editors and web workbench — current Drools authoring is DRL, spreadsheets and Maven.
- You need a decision record you can query. Drools gives you event listeners and a file audit log to wire up yourself; there is no persisted, searchable decision store.
- The decision has to call out. In Drools the host application fetches the facts and inserts them into working memory; there is no HTTP construct in the rule language.
- Someone has to review some of them. Human tasks live in jBPM, a separate component, and since Business Central's retirement there is no shipped task interface at all.
- You do not want to be the platform team. Rules as versioned JARs, a scanner watching a Maven repository, a KIE session lifecycle and an audit pipeline are all yours to build and operate.
Side by side
Every row links to where it came from.
Claims about Drools are taken from Drools’s own documentation, pricing and repositories — never from a review site, and never from us. Follow the link in the left column to check any of them.
| Criterion | Drools | ArboRule |
|---|---|---|
| What it isdocs.drools.org — getting started read 2026-07-30 | different model An embeddable Java library — a rule engine, DMN engine and complex event processing engine — under Apache 2.0, needing JDK 11 or later and Maven. Not a server and not a product. | A hosted platform. The editor, the runtime, the history, the review queue and the billing are one system. |
| Project statuskie.apache.org read 2026-07-30 | different model drools.org now redirects to kie.apache.org. Drools is a sub-project of Apache KIE, which states it is undergoing incubation at the Apache Software Foundation. Red Hat has transferred Process Automation Manager and Decision Manager to IBM, and 7.13 was Red Hat's last release. | A commercial product with one vendor behind it, and the risk profile that implies in the other direction. |
| Pricingaccess.redhat.com — Decision Manager read 2026-07-30 | different model The library is free under Apache 2.0. No commercial price is published — the Red Hat Decision Manager product page carries a description and no subscription tiers. | US$ 500 a month on the Startup plan, including 50,000 decisions across Sandbox and Live. Priced by decision, not by seat. Building and testing is free up to 10,000 decisions a period. |
| Authoringdocs.drools.org — migration guide read 2026-07-30 | different model DRL and spreadsheet decision tables survive and are maintained, compiled through the decision-tables module. The business-user authoring layer does not: Business Central is retired and no longer a component of Drools 8, taking the guided editors and guided decision tables with it. The DMN editor is the only graphical authoring left in the current docs. | A visual canvas with 22 node types. Rule, Decision Table, Scorecard and 2D Matrix are grid editors a policy owner can work in; operand fields also accept Python, and the Code node is Python only. |
| Where it runsdocs.drools.org — KIE read 2026-07-30 | different model In your JVM. Rules load from the classpath or as KJARs into a container at runtime. KIE Server is retired and no longer a component of Drools 8, and the current documentation has no container deployment chapter. | Hosted only. There is no self-hosted, on-premises or bring-your-own-cloud option, and no published certification — the controls are an append-only audit log, role-based access, scoped API keys, configurable retention and SSO/SCIM. |
| Versioningdocs.drools.org — KIE read 2026-07-30 | different model Maven. Rules ship as KJARs versioned by group, artifact and version, with fixed versions, snapshots or ranges. A scanner can watch a repository and upgrade automatically, though the docs warn against using it with snapshots in production. | A version is DRAFT, PUBLISHED or ARCHIVED. Published versions are immutable — you duplicate to a new draft — and publishing can require an approved review. There is no one-click rollback: you move traffic back. |
| Staged rolloutdocs.drools.org — KIE read 2026-07-30 | not in the product Not documented. Which version runs is a build-and-deploy concern, handled by whatever ships your application. | Integer traffic weights across published versions, summing to 100, sticky per grouping_id so an application keeps the version it started on. No shadow mode: a challenger serves real traffic or none. |
| Decision historydocs.drools.org — KIE read 2026-07-30 | not in the product No persisted, queryable decision store. What exists is an event system — agenda and runtime listeners — and a file logger that writes an audit log for later inspection in a viewer. Recording, retaining and searching decisions is yours to build. | Every run stores its input, output, the version that produced it and a node-by-node trace, including each external call's URL, status and latency and each model's SHA-256. Queryable at GET /history/api/v1/decisions. Retention is per-workspace, five years by default. |
| External datadocs.drools.org — working memory read 2026-07-30 | not in the product The host application fetches and inserts. Facts are evaluated only once inserted into the session, and globals exist so rules can reach application services you hand them. There is no native HTTP construct in the rule language. | 28 packaged providers, six databases, and any HTTPS/JSON API through a Custom Connection. You bring your own credentials for each: the platform orchestrates the calls, it does not resell the data. |
| Human reviewkie.apache.org — jBPM read 2026-07-30 | not in the product Not in Drools. Human tasks live in jBPM, a separate Apache KIE component that can be combined with Drools, and since Business Central's retirement no task interface ships in the distribution. | A Manual Review node suspends the decision and puts it in a reviewer queue; Case nodes record work without blocking the run. Case queues carry SLA policies pinned onto each case at creation, with business-hours clocks and escalation rungs. |
| Modelsdocs.drools.org — PMML read 2026-07-30 | different model PMML, through the trusty PMML module, invoked from DMN business knowledge model nodes — regression, tree and random-forest style models. The docs state the JPMML libraries are not directly supported. No LLM execution inside a rule is documented. | ONNX models up to 32 MB, immutable once uploaded and re-verified by SHA-256 at scoring time, executed in-process. One graph input, CPU only. AI and Agent nodes call OpenAI, Anthropic or Google models inside the decision, on your own API key. No key, no AI. |
Drools is better at the thing it is for
It is worth being unambiguous about this before the rest of the page. For chained reasoning over an accumulating set of facts, Drools is the best engine here and it is not close.
PHREAK evolved from Rete and is lazy and goal-oriented, with three layers of contextual memory. Truth maintenance means a fact derived by a rule is automatically retracted when the conditions that produced it stop holding — which is genuinely hard to reimplement and which nothing else in this comparison offers. Stream mode adds sliding windows and temporal operators for reasoning about events over time.
If your problem is diagnostics, logistics, monitoring or compliance reasoning where hundreds of facts interact and conclusions depend on other conclusions, that is Drools' home ground. A flow-shaped decision engine, ours included, expresses that badly.
Most credit and fraud policies are not inference problems. They are a sequence of lookups and cut-offs, which is why the engine is rarely the part that hurts.
What Drools 8 removed, and why it matters
Anyone evaluating Drools on the strength of a memory from a few years ago should read the migration guide first, because two things people assume are part of the product are gone.
Business Central is retired and no longer a component of Drools 8. That was the web workbench — guided editors, guided decision tables, the place a business analyst could look at a rule. With it goes the answer to "how does a non-engineer change a threshold". The remaining answer is a spreadsheet compiled at build time, or DRL.
KIE Server is retired too. That was the standard way to run rules as a service. Current documentation covers loading rules from the classpath or as KJARs into a container inside your own application, and has no container deployment chapter at all.
Both removals are defensible for a library that has refocused on being a library. They do mean that "Drools" in 2026 is a smaller thing than "Drools" in 2019, and a comparison that ignores that is comparing against something that no longer ships.
The part nobody budgets for
Choosing Drools is choosing to build a decision platform, and the engine is the part that is already done.
You will need somewhere the rules live and are reviewed; a build that turns them into versioned artifacts; a deployment that gets those artifacts to the right places; a way to know which version made a given decision; a store that records decisions and the data behind them, and keeps them long enough to answer a dispute; a queue for the cases a human has to look at; and a way to test a change against what actually happened before it carries traffic.
None of that is exotic and every one of them is achievable. Teams do it, and for some the control is worth it. But it is a standing engineering commitment rather than a one-off, and it is the honest comparison — not engine against engine, but engine plus a team against a hosted product.
Questions
Is Drools still maintained?
Yes, but its home moved. drools.org redirects to kie.apache.org, and Drools is now a sub-project of Apache KIE, which states it is undergoing incubation at the Apache Software Foundation. Separately, Red Hat has transferred Process Automation Manager and Decision Manager to IBM, with 7.13 as Red Hat's last release — so the commercial distribution and the open-source project have taken different paths.
Can a business user edit Drools rules?
Much less easily than in the past. Business Central — the web workbench with guided editors and guided decision tables — is retired and no longer a component of Drools 8. What remains is DRL, spreadsheet decision tables compiled at build time, and the DMN editor. A spreadsheet is genuinely usable by a non-engineer; the deploy pipeline behind it is not.
Does Drools keep a record of each decision?
Not as a queryable store. It exposes a comprehensive event system — agenda and runtime listeners — and a logger that writes an audit file for later inspection in a viewer. Turning that into a decision history you can search by customer or by date, with retention you can defend to a regulator, is an application you write around the engine.
Last verified July 30, 2026 against Drools’s public documentation. Products change and pages move; if something here is out of date, tell us at hello@arborule.com and we will correct it.