Skip to main content

    Camunda 7-class performance, measured rather than asserted.

    One identical invoice-approval process, deployed unchanged on Camunda 7, on Fluxnova and on Camunda 8, run on Amazon EKS in June 2026. Zero failures on every engine at every volume. The interesting result is not which one won.

    Preliminary results showing relative behavior on the documented workload. This is not a certified production benchmark, and it is our process on our infrastructure — your models are not our models. Full method and environment specifications are below and available in full on request.

    The result

    Two engines in one class. One in another.

    Fluxnova and Camunda 7 completed a thousand workflows within a few seconds of each other. Camunda 8 took about fifteen times as long on the same process, because it is a different architecture rather than a slower one.

    1,000 workflows · all three enginesCamunda 7v7.24.016.7sFluxnovav2.0.021.3sCamunda 8v8.8.0315sBoth volumes · the two embedded enginesCamunda 7300 workflows6.7sFluxnova300 workflows6.0sCamunda 71,000 workflows16.7sFluxnova1,000 workflows21.3s
    Seconds, and lower is better. The upper panel is a linear scale to 350 seconds and the detail panel below it a linear scale to 25 — and that difference is the finding: Camunda 8 takes about fifteen times the embedded engines on this workload, which is its architecture rather than a fault. No axis is broken and neither scale is logarithmic. Every value is printed beside its bar and repeated in the table below.
    Full results

    Every number, at both volumes.

    Throughput is completed instances divided by total wall-clock time. Both volumes ran on the same driver, the same process definition and the same out-of-the-box configuration.

    Engine300 workflows1,000 workflowsFailures
    Camunda 7 v7.24.06.7s · 45/s16.7s · 60/sNone
    Fluxnova v2.0.06.0s · 50/s21.3s · 47/sNone
    Camunda 8 v8.8.0104s · 3/s315s · 3/sNone

    Every run completed every instance. The difference between these engines is fit for this workload, not reliability.

    What we read from it

    The honest reading of four numbers.

    01Same performance class
    Roughly seventeen to twenty-one seconds for a thousand workflows, at about fifty a second.

    That is the number that matters if you are deciding whether to move off Camunda 7 Community Edition. It says the move does not cost you throughput.

    02Variance, not a winner
    Each engine edged ahead at a different volume — Fluxnova at 300, Camunda 7 at a thousand.

    We read that as normal benchmark variance rather than a meaningful advantage for either. Anyone presenting one of those two runs on its own is selecting a result.

    03Camunda 8 is a tradeoff
    A distributed stack carries higher per-workflow overhead for a stateful workload, and buys horizontal scale and resilience.

    Some organizations need exactly that. The question this benchmark cannot answer for you is whether those properties are worth the overhead on your own processes.

    04Zero failures, anywhere
    Every instance completed, on all three engines, at both volumes.

    No engine here is unreliable. If a benchmark of this shape had produced failures, that would have been the story instead.

    One benchmark on one process is evidence about that process. It is a reason to run your own, not a substitute for having done so.

    Why the gap is what it is

    An architectural difference, stated without a verdict.

    The three engines are not three implementations of one design, and the numbers above are mostly a picture of that.

    Camunda 7 and Fluxnova. Service tasks run as in-process logic against PostgreSQL. The engine and the work sit in the same process, which is why a stateful workload of this shape completes in seconds.
    Camunda 8. Every task is an external job, served by gRPC workers through the Zeebe gateway into Elasticsearch. That distribution is what delivers horizontal scale and operational resilience, and it is also what adds the per-workflow overhead visible above.

    “Organizations can migrate from Camunda 7 to Fluxnova without sacrificing performance, compatibility, or operational simplicity. For organizations evaluating their post-Camunda 7 strategy, Fluxnova delivers Camunda 7-class performance and a compelling open-source alternative to costly platform migrations.”

    Ryan Johnston, Founder, Summit58 · an iTmethods partner

    What the benchmark did not measure

    This ran on 2.0.0. 3.0 changed what runs inside a process.

    These figures were produced in June 2026 against Fluxnova v2.0.0, and they are a throughput measurement of a deterministic invoice process. Version 3.0 shipped in July with MCP integration and agentic adhoc subprocesses, which means an agent can now invoke a process and determine its own steps at runtime. That is a change in what the engine can do, not in how fast it does it, and this benchmark says nothing about it.

    Why we have not re-run it on 3.0
    A throughput number for a deterministic process would not change much, and a throughput number for an agentic one would mean very little without saying what the agent was allowed to do. The question that matters for 3.0 is governance rather than speed, and it is answered on the product page rather than here.
    Where that question goes. An adhoc subprocess does not declare its steps in advance, so the record of what ran stops being the same thing as a record of what was authorized. Reign Gateway sits on the model path and is available today; Reign Assurance turns requirements into checks and is in co-design development rather than shipping. What 3.0 changed → · How the boundary works →
    Method

    How it was run, so you can take it apart.

    Published so you can judge how far it carries to your own models. A benchmark whose method is not stated is an assertion with a number attached.

    WhatHow
    The processOne identical BPMN invoice-approval definition, deployed unchanged to each engine. No per-engine tuning of the model.
    The environmentAmazon EKS, us-east-1. Out-of-the-box configuration on every engine, so none of them is tuned and none is handicapped.
    The driver300 and 1,000 instances started across ten concurrent threads, measuring wall-clock time until every instance completes. Throughput is completed instances divided by that total.
    The versionsCamunda 7 v7.24.0, Fluxnova v2.0.0, Camunda 8 v8.8.0. Run June 2026.
    What it is notNot a certified production benchmark, not tuned for peak on any engine, and not a projection for your estate. Full environment specifications on request.
    Run it yourself

    Our numbers are a reason to get your own.

    We provision a dedicated Managed Fluxnova environment for your team for thirty days, at no charge and with no commitment. Bring this invoice benchmark or bring your own BPMN models.

    01Claim the environment
    Tell us what your Camunda estate looks like and we hand you the keys.
    02Run your own tests
    Your models or ours. You set the volumes and you watch the numbers land.
    03Keep the results
    The full data, plus an engineering readout of what it means for your migration path and effort.

    Your models, your volumes, your data — and the results are yours to keep whether or not the conversation goes anywhere. What the environment includes →

    SOC 2 Type II on Reign Ops FINOS member
    Camunda is a registered trademark of Camunda Services GmbH; iTmethods is not affiliated with or endorsed by Camunda. Fluxnova is a project of the Fintech Open Source Foundation, licensed under Apache 2.0. This benchmark was conducted independently by iTmethods in June 2026.
    Next step

    Bring us the process you would want measured.

    The edition you are on, roughly how many process definitions are in production, and what is forcing the move. We will come back with what the migration actually involves, and what we would want to measure first on your own models rather than ours.

    Request an environment

    Tell us what you want to test.

    We will provision a dedicated Managed Fluxnova environment and come back to you with access details and the next steps.

    Or contact us directly at reign@itmethods.com.