$17k per connection and the batch that fails whole

Boomi's list economics and runtime model punish the workload a beverage distributor actually runs. Enterprise connectors are priced near $17,016 per connection per year as of April 2026, so 5 to 15 endpoints is a documented 500%-plus jump. Each Atom runs as a single JVM with no native auto-scaling, and when a mapper fails mid-transform the whole batch fails, not the offending record. High connection counts plus all-or-nothing batches is expensive and brittle.

What does a Boomi connection actually cost?

Boomi licenses by connection, and in route-to-market the connection count does not stay small. A single brewer's distribution stack touches the SAP financial core, an order-capture front end, a warehouse or 3PL system, delivery telematics, a tax engine, a promotions engine, loyalty, returnables, and often a separate endpoint per region or distribution centre. Each of those is a connection with a line-item price, and the per-unit number is not trivial.

One published pricing breakdown puts enterprise connectors at roughly $17,016 per connection per year as of April 2026 and describes a move from 5 to 15 connections as a 500%-plus increase — about $47K climbing past $283K. Data transfer beyond plan is billed at $117 per gigabyte with no grace period, and a separate vendor tracker records enterprise pricing rising 26.07% year over year. None of those are usage you fully control; they are a function of how many systems you connect and how much data moves between them.

The failure mode here is not a single big invoice; it is compounding. Every new outlet channel, every acquired distributor, every SAP module you expose adds connections, and connection-priced integration scales with your topology rather than your revenue. We made the same argument about usage-metered iPaaS in how recipe task pricing compounds at 7,000 tasks a day: the unit looks small in the demo and the bill looks structural by year three.

Why does one bad record fail the entire batch?

The economics would be tolerable if the runtime were forgiving. It is not. Boomi's own high-volume guidance and third-party reviews describe map-level failures as all-or-nothing:

When the Boomi mapper fails during a transformation, the entire batch fails — not just the specific record.

In an order-to-cash context that is exactly the wrong granularity. A nightly settlement run for a large brewer can carry millions of order lines across thousands of outlets. One malformed line — an unknown SKU from a newly onboarded distributor, an empty tax field, a returnable deposit that does not resolve — can sink the whole transform. Instead of quarantining one record and letting the other 999,999 flow, you reprocess the batch, and you do it inside a maintenance window that does not grow to accommodate reruns. Reconciliation then becomes a manual hunt for the one row that poisoned the set. This is documented behaviour, not an edge case; the high-volume troubleshooting notes and the reviewers who tested it both describe it.

Why does the runtime need hand-tuning?

Scaling out of the problem is not straightforward either, because of how the runtime is built:

Boomi uses a single JVM process per Atom with no native auto-scaling.

A single JVM has a heap ceiling. When batch volume climbs — month-end, a promotional peak, a national holiday order surge — the Atom does not spread the load across new processes; it fills up. The community-documented remedy is to hand-edit atom.vmoptions to raise the heap and restart, which is a vertical, manual, reactive fix. Threads on the Boomi community return to recurring OutOfMemory errors and vmoptions edits often enough that it reads as routine operations work rather than incident response. You are effectively paying enterprise connector prices for a runtime that still needs an engineer to tune JVM flags before peak.

Where does this bite a beverage distributor?

Put the three together against a real route-to-market load. You have a wide topology, so you are near the top of the connection-pricing curve. Your volume is spiky — the biggest days of the year are promotional peaks and seasonal surges — so you are most likely to hit the JVM ceiling exactly when it costs the most. And your batches are all-or-nothing, so the night one distributor sends a bad file is the night the settlement run fails whole and someone edits vmoptions at 2 a.m. to get it through. The costs are correlated by design: the conditions that spike your spend are the conditions that break your batches.

The harder part is that little of this is visible before you sign. Per-connection list prices, overage rates and JVM behaviour surface in community forums and independent reviews rather than in a tidy datasheet — the same evaluation gap we described in the software your industry runs on has no reviews. It is also why "it's just an iPaaS, it'll plug in" rarely survives contact with a real distribution estate, a pattern we picked apart in the plug-and-play retail suite that isn't.

So what is the fix direction?

The structural answer is to stop treating integration as a per-connection tax on a fragile single process. An event-driven backbone with per-record error handling — dead-letter the one bad order line, keep the stream flowing, and scale consumers horizontally instead of resizing one JVM — turns an all-or-nothing batch into a self-healing pipeline and decouples cost from connection count. That is the shape of the one-event-bus architecture we build, and it is a different economic and operational model, not a tuning tweak.

None of this makes Boomi a bad tool; it makes it a poorly matched one for high-volume, high-connection route-to-market. As distribution estates keep widening — more direct-to-outlet channels, more returnable and traceability data on every pallet — the connection count and the nightly line count only go up. The integration layer a brewer picks in 2026 should get cheaper per event as it grows and should never let one malformed line decide whether the region gets invoiced. Those are the two questions worth asking any iPaaS before the connectors start multiplying.