Adding up the iPaaS bill for one mid-size brewer

Price it honestly and a mid-size brewer's route-to-market integration layer lands between roughly $250k and $600k a year before a single order moves: a middleware licence, per-connector fees, and message-metering overages, stacked. The line items are documented; the surprises live in payload size and connection count. The cheaper path is to own the event bus and pay for engineering time you already fund, not per-connection and per-message rent.

What are you actually paying for?

Every integration-platform-as-a-service bill is really three meters running at once, and it helps to name them before adding them up.

• Capacity or connection count. Reviewers report a four-vCore production tier of MuleSoft at roughly $210k a year as of mid-2025. Boomi meters differently, at about $17k per connection, and a real route-to-market landscape needs twelve to fifteen of them.
• Connectors. The premium adapters that talk to SAP, EDI networks, telematics and loyalty are their own line items, documented at $10k-$15k each as of mid-2025. This is where the catalogue quietly becomes the bill.
• Messages. SAP Cloud Platform Integration counts messages, not payloads, and rounds up. A single 2MB order or catalogue file is billed as nine charged messages, so a fat EDI batch costs nine times what its file count suggests.

What does the worked example add up to?

Take a deliberately ordinary mid-size brewer: order capture, a stock and warehouse system, loyalty, returnables tracking, delivery and telematics, analytics, the SAP financial core, and a handful of distributor EDI feeds. That is comfortably thirteen integration points, not an ambitious number. Here is what the same landscape costs depending on how your vendor meters it, using the documented figures above and framing them as of August 2025.

Now layer in the part vendors do not print on the licence. Forrester's composite study of a $7.5B organisation put the MuleSoft licence alone near $600k a year, with first-year total cost of ownership running two to three times the subscription once implementation, connectors and platform engineering are counted. Apply even the low end of that multiplier to the $354k subtotal and the first year clears $700k. The sticker was never the number.

Where do the overages hide?

In three places, all of them structural rather than negotiable.

Payload size. Message metering punishes exactly the traffic a brewer generates most: nightly order batches, full catalogue syncs, EDI from large distributors. When a 2MB file counts as nine messages, volume forecasting stops being arithmetic and starts being a bet. Consumption meters have a habit of landing well over plan; we have written before about consumption pricing that arrives 40-60% over budget, and message counting is the same trap in a different unit.

Connection sprawl. Per-connection pricing assumes connections are rare. In route-to-market they multiply: every new distributor, every new depot, every acquired brand adds spokes. The connector catalogue is where the ecosystem tax bites hardest, because each premium adapter is priced as though it were strategic when most of them are moving a CSV.

What the money does not buy. None of this spend improves the thing your reps actually touch. A six-figure integration bill sits happily underneath a field app your drivers rate at 1.9 stars. Integration budget and field reliability are separate concerns, and the vendor selling you the first rarely owns the second.

How to fix it: put the traffic on a bus you own

The escape is not a cheaper iPaaS. It is removing the meters entirely by making integration a property of a platform you control. Concretely:

1. Count what you are actually metered on. Inventory every real integration point and measure the payload sizes flowing through them. Most brewers find twelve to fifteen connections and a handful of fat batch files: a small, knowable surface, not the sprawling estate the pricing model implies.
2. Publish domain events once, to one bus. Emit order.placed, stock.moved, returnable.scanned and delivery.completed to a single event bus you own. Consumers subscribe. There is no per-connection contract because there are no point-to-point connections to count.
3. Keep SAP as a system of record, not a hub. One adapter posts financial events to the SAP core and reads master data back. The financial core stays exactly where it is; it simply stops being the switchboard every module routes through.
4. Treat connectors as code, not catalogue items. A REST or EDI adapter is a few hundred lines you write, version and test like anything else, not a $12k line item. When a distributor changes their format, you edit code; you do not raise a licence request.
5. Meter yourself on engineering time. The honest cost of integration on an owned bus is the days your engineers spend building and maintaining adapters, capacity you already fund. It does not scale with message volume or connection count, which is the entire point.

The trade is real and worth stating plainly: you take on the operational burden of running a bus rather than paying someone to run it for you. For a team of twenty AI-augmented engineers on one event bus, that is a job we already do; for a two-person integration team, buying the meter may still be the right call. Owning the event-bus architecture only pays off if you are prepared to own its uptime.

The pricing models are drifting further toward consumption, not away from it, which means the gap between metered integration and owned integration widens at every renewal. The brewers who spend the least on plumbing over the next few years will be the ones treating the event bus as core infrastructure now, while the connection count is still small enough to move. The bill compounds; the decision to stop feeding it does too.