Can n8n replace enterprise middleware?

In late 2025 SAP took a strategic stake in n8n, roughly USD 60M. The plan is to embed n8n natively inside Joule Studio, with general availability targeted for Q3 2026. Since then my feed has been full of people discussing the same question: does this replace traditional middleware?

I got curious, so I put together a throw-away instance and built something of typical complexity: an endpoint that calls an external API (the Spanish Meteorological Agency forecast for Granada), applies some logic, and returns a message that depends on how hot/cold tomorrow is going to be. In Integration Suite this would be an iflow with one call, some logic and a mapping.

There is a lot to like. There are also some gaps, which I will discuss later.

Getting it running

Again, this is a throwaway test instance, so I did not want a full Postgres database sitting next to it. If you set no database variables at all, n8n falls back to SQLite inside its data directory. Good enough. This is my toy setup:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      # Timezone used by Schedule/Cron nodes and by the container itself
      - GENERIC_TIMEZONE=Europe/Madrid
      - TZ=Europe/Madrid
      # Task runners (still required on n8n 1.x)
      - N8N_RUNNERS_ENABLED=true
      # Silences the "permissions" warning; the config file is chmod 0600 on start
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      # Local-only test instance: served over plain HTTP on localhost
      - N8N_SECURE_COOKIE=false
      # No database vars on purpose -> n8n defaults to SQLite inside ./data
    volumes:
      # Everything (SQLite DB, encryption key, logs) lives on a single directory
      - ./data:/home/node/.n8n

Save as whatever.yaml, navigate to the relevant directory, docker compose up -d, open localhost:5678, and that’s pretty much it. You can go from nothing to a working editor in about two minutes. For a production instance you would want Postgres, queue mode, and some custom n8n variables fine-tuned to your particular scenario. But for getting an approximate idea this is fine.

The scenario

So everything is set up, so I built a single workflow (the tendency to call them iflows is very strong). A webhook, something that resembles a REST API. It ended up as a bunch of nodes: a Webhook trigger, an HTTP Request to get the weather forecast, an XML node to turn the response into JSON, a Split Out to get one item per day, a Filter for tomorrow only, a Set to shape the fields, a Switch that branches on temperature into four different pieces of advice, an If on whether it is going to rain, and a Respond to Webhook at the end.

The finished n8n workflow on the editor canvas: a webhook trigger feeding an HTTP request to AEMET, XML conversion, a filter for tomorrow, and a switch branching into four temperature-based messages before responding.

The screenshots are in Spanish, as you can see. I built this for myself and only decided afterwards that it was worth writing up.

Calling it from Bruno returns a 200 OK with the advice for tomorrow (with a max. temperature of 38 Celsius, so the advice is “Be careful”):

Bruno showing a 200 OK response from the n8n webhook, with the generated weather advice in the body.

What is good

It is light. It runs on your own infrastructure, Docker or Kubernetes, with SQLite or Postgres behind it, and you have an instance in minutes. There is no tenant provisioning and nobody to wait for. Need more RAM? Tweak your container setup. Need to allow bigger payloads? Set a container variable to up the limit. Nice.

Development and testing are quick in a way that is hard to overstate. You see the real data at every node as you build, with no deployment step in between. This was a nice surprise. (I don’t want to drag SAP around the mud, though; developing in Integration Suite is quite agile, as you can change-deploy-review in seconds for most purposes. The main difference is that n8n does not even require you to deploy anything).

In Integration Suite XML reigns and JSON is a bit harder to work with. I wrote about it here. Even if you can use JSON schemas, the support for XML is still vastly superior. Nevertheless, most of the APIs I deal with these days are JSON, which is exactly what n8n does perfectly: it is much better adapted to REST. As Javascript is the standard language, parsing JSON messages is completely native and removes a whole category of small annoyances.

Something I did not expect, and appreciated: almost everything I know from building iflows carried over. The shapes are the same. A Switch is a Router, a Set is a Content Modifier, Split Out is a Splitter, and the trigger-then-pipeline structure is the one you already draw on a whiteboard for Cloud Integration. The vocabulary changes and the syntax for referencing fields changes, but the way you decompose a problem does not. I was productive in an afternoon, and I think most integration developers would be.

The thing I keep coming back to, though, is that every process is a JSON document. That makes the cost of putting an agent to work on your integrations close to zero. A model reads these workflows and writes them without trouble, and it can inspect your installation to see which version of each component you are running. Integration Suite artefacts are a zipped pile of XML and property files, machine-readable in principle, but nothing like as tractable in practice. Whenever I got stuck I could direct Claude to the .json file that represents the process and it could support me instantly.

The billing axis is different too. Integration Suite charges per processed message, counted in 250 KB blocks, while n8n charges per workflow execution. A 100 MB file is 400 messages in Integration Suite and a single execution in n8n. If your work is file-shaped rather than transaction-shaped, that compounds fast.

For small automations, moving files around, mocking, or putting an API in front of an internal database, it fits very well.

What it costs

n8n publishes its prices. As of today:

Plan	Price	Executions	Hosting
Community	Free	Unlimited	Self-hosted
Starter	20 €/mo	2,500/mo	Cloud only
Pro	50 €/mo	10,000/mo	Cloud only
Business	667 €/mo	40,000/mo	Self-hosted available
Enterprise	Custom	Custom	Self-hosted or cloud

Prices are billed annually. The community licence covers the basics, and for a homelab or a small internal tool it is genuinely all you need. But the moment you want something that survives an architecture review, meaning SSO, SAML, LDAP, user roles, environments and version control with Git, you are on Business. That is 667 €/mo for 40,000 executions, which for a productive tenant runs out sooner than you would like.

SAP publishes list prices too:

Edition	Price	Messages included	What it adds
Starter	USD 1,728/mo	50,000/mo	Capped at 10 custom iflows per global account
Standard	USD 5,339/mo	10,000/mo	API Management, B2B libraries, Open Connectors, Integration Advisor
Enhanced	USD 7,688/mo	500,000/mo	Everything in Standard, plus Alert Notification, Transport Management, Document AI, advanced event mesh

Extra messages are USD 7.00/mo per block of 10,000. Contracts run 3 to 36 months with auto-renewal.

So n8n Business lands at roughly half an Integration Suite starter tenant. The currencies differ, so treat that as an order of magnitude rather than a precise figure, but it is a much smaller gap than the one people seem to assume when they call n8n the cheap option.

The starter edition is worth a closer look, because its shape says something. It includes 50,000 messages a month, five times what Standard includes, plus the certified adapters, IDOC and RFC among them. What it caps is custom development: ten custom integration flows per global account, and buying more tenants does not raise that ceiling. SAP’s entry tier is built for running prebuilt content. The long tail of bespoke integrations is exactly the space it does not cover, and exactly the space n8n could be walking into.

On metering, SAP’s wording is unambiguous: if a message is larger than 250 KB, “any amount in excess of 250 kilobytes will be charged as one additional message for each 250 kilobytes or portion thereof”. A ~2 MB message is ~9 messages. I already wrote about how a badly configured retry mechanism in Integration Suite can soon become a billing problem.

The marginal cost is small. At USD 7 per 10,000, those 400 messages from a 100 MB file come to about 28 cents. What bites is the ceiling: move 125 files of that size in a month and a starter tenant’s entire allowance is gone. In n8n the same 125 files are 125 executions out of 40,000, and you would never notice.

What is missing

Price is the least of it, because the rest is simply absent.

There are no certified SAP adapters. No EDI, no IDoc, no RFC. You end up rebuilding on OData or REST, which works right up until somebody asks for an EDIFACT message with a proper acknowledgement.

Delivery guarantees are the bigger gap. Integration Suite gives you queues, reprocessing, per-message monitoring and correlated executions. Proving that an order was delivered once and only once, with an audit trail to show for it, is expensive to do in n8n. You can build the machinery yourself, but that machinery is most of what you are paying enterprise middleware for in the first place.

Message-level security has no equivalent at all: no keystore, no certificate handling, no signing or encryption of payloads. There is a credential store instead, and in fairness it is more flexible than SAP’s. It solves a different problem, though.

Then there is memory. n8n loads all items into memory rather than streaming them, so a large file or a batch of a few million records will take down the worker or push you into tuning the container’s payload limits. Mitigations exist: setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem moves binary payloads to disk on a single instance. That is, you move blobs out of memory without actually streaming. (The n8n user base has been demanding streaming for years, especially because talking to an LLM without streaming is excruciatingly slow).

So, does it replace middleware?

I do not think n8n is here to replace the enterprise-ready middleware we already know, and my impression is that it is not trying to. It is very powerful for a different problem: the long tail of small integrations that never justified a licence in a paid middleware. There it is hard to beat. In the enterprise integration core, with its certifications, delivery guarantees and governance, it is not in the same league.

That is also why folding it into Joule makes sense to me. Agent orchestration is a different job from moving a purchase order, and n8n is a much better fit for it than anything SAP had lying around.