Comparison
We compare by category of tool, not against named products. A vendor who names a competitor also picks the criteria; we would rather give you the criteria and let you name the product.
This page contains no performance figure, in any column — neither ours nor anyone else’s. The numbers that decide an integration are the ones measured on your traffic, in your installation, with your real messages. We produce them together, during evaluation.
A classic on-premise ESB suite
Where we fit
An integration is a text file, with a visual editor in VS Code, published as a compiled artifact — mistakes are refused at publication rather than discovered at runtime. An installation is the binary and a state directory: it scales by starting the binary again against the same directory, coordinated by file locks, with no orchestrator, no consensus service and no cluster with operators of its own.
Where the suite is better
A ready-made connector ecosystem far wider than ours. Graphical schema-mapping tools. Automatic failover between nodes, with cluster administration tooling around it. A market of specialists you can hire.
Cloud iPaaS
Where we fit
The platform runs where you put it, with the data staying there. The contract is commercial, and what runs is a binary you control. The gate is closed by default and runs before the message body.
Where iPaaS is better
Nothing to operate: no boot, no backups, no migrations. A large catalogue of connectors to commercial services. Scale you buy rather than build.
Hand-written integration code
Where we fit
Deduplication, correlation with a mandatory deadline, retry with its own write-ahead log and the response contract belong to the platform and are not rewritten per integration. The measured unit is the delivery, and its verdict is a column, not a team convention.
Where the code is better
It has no language limits: what is not in our flow language — rejoining after a parallel branch, writing a file, schema-driven coercion — is written in code. Debugging with the tools the team already has. No licence to buy.
A message broker plus your own code
Where we fit
Translation, guards and routing are declared in the flow and refused at publication when wrong. The same gate and the same delivery bracket on all four inbound doors, so delivery accounting does not change from door to door.
Where the broker is better
Delivery and ordering guarantees we do not have: we deliver at least once, with no prioritisation and no reordering. Ecosystem, familiar operations, and real horizontal scale.
Limits worth knowing
Collected from the four sections above, so you have them in one place when you evaluate:
- The adapters are the ones named on the protocols page: HTTP/REST, SOAP 1.1 and 1.2, gRPC, JMS over STOMP, and files on disk. Anything outside that list is called as an HTTP service from the flow rather than bought as a connector.
- No automatic failover between engines: the cron scheduler is elected at boot, so when the engine holding the election stops, the schedules resume at the next restart.
- Rate limits are counted per engine: a ceiling of r requests per second is configured for the engine, not for the installation.
- At-least-once delivery, with no prioritisation and no reordering: a consumer that needs strict order gets it from the message key, not from the queue.
- The generated WSDL is document/literal with
xsd:anyType— right for loosely-typed clients; a contract typed against the message schema is not generated. - A commercial licence, with no source code and no public download: evaluation runs on an installation provided under contract.
What an honest evaluation looks like
Take the list of limits, set it beside the project’s requirements, and cut what does not fit. If something remains, the conversation is worth having; if nothing remains, you have saved a month.