n8n vs Make: Detaillierter Vergleich der Workflow-Tools (2026)

n8n und Make (vormals Integromat) sind 2026 die beiden ernsthaften Wahl-Optionen, wenn DACH-Mittelständler sich von Zapier emanzipieren wollen. Beide haben ihre Anhänger, beide haben ihre Schwächen — und die meisten Vergleiche im Netz lesen sich wie Marketing-Material des einen oder anderen Lagers.

Diese Notiz ist anders. Wir betreiben beide Tools in Engagements und sind zu einer klaren Empfehlung pro Anwendungsfall gekommen. Hier die ehrliche Sicht.

TL;DR — wann was

Wenn Sie keine Zeit für 13 Minuten haben:

• Wählen Sie n8n, wenn Self-Hosting wichtig ist (DSGVO), Code-Flexibilität gefragt ist, oder Sie KI-Workflows bauen wollen.
• Wählen Sie Make, wenn die Workflows visuell verständlich bleiben sollen, das Team nicht-technisch ist und Cloud-Hosting akzeptabel ist.
• Wählen Sie keinen von beiden, wenn Ihre eigentlichen Probleme strukturell sind — dazu am Ende mehr.

Direkt-Vergleich der wichtigsten Features

Pricing im Detail

Der Preisvergleich ist trickreich, weil die Modelle unterschiedlich sind. Wir rechnen drei typische Mittelstands-Szenarien durch:

Szenario A: 5 Workflows, je 100 Executions/Tag = 15.000/Monat

Ergebnis: Self-Hosted n8n ist ~3× günstiger als die Cloud-Versionen.

Szenario B: 30 Workflows, mittlere Komplexität = 80.000 Operations/Monat

Ergebnis: ab mittlerem Volumen wird Make günstiger als n8n Cloud, n8n Self-Hosted bleibt unschlagbar.

Szenario C: Konzern-Setup, 200 Workflows = 500.000+ Operations/Monat

Ergebnis: Self-Hosting bleibt der absolute Preis-King, auch im Konzern-Maßstab.

Performance & Skalierbarkeit

Aus Engagements:

n8n verarbeitet auf einer mittelgroßen Cloud-VM (4 vCPU, 8 GB RAM) komfortabel ~50.000 Executions/Tag bei mittlerer Komplexität. Bei sehr großen Datenmengen (z. B. 100k Records pro Workflow) wird der Memory-Bedarf zum Engpass — dann braucht es horizontales Skalieren via Worker-Mode.

Make skaliert in der Cloud bis quasi beliebig, aber mit Operations-Pricing. Bei großen Daten-Loops zählt jede Iteration als Operation — was schnell teuer wird. Die Lösung: Iteratoren auf Aggregator-Pattern reduzieren oder direkt zu Code-First-Tools wechseln.

Beispiel-Workflow: Lead-Qualifikation mit beiden Tools

Hier ein typischer Workflow, den wir in beiden Tools mehrfach gebaut haben:

01 · Start

Form-Submit auf Website

02 · System

Webhook empfangen

n8n / Make

03 · KI

Lead-Score berechnen

GPT-4 + Heuristik

04 · Entscheidung

Score ≥ 80?

05 · System

Hot-Lead in CRM

HubSpot

Ja

06 · System

Nurturing-Sequenz

Mailchimp

Nein

07 · Ende

Slack ans Sales-Team

In n8n würde dies als ein einziger Workflow mit ~7 Knoten umgesetzt, der OpenAI-Knoten ist nativ vorhanden, der freie JavaScript-Knoten für die Score-Logik ist mächtig.

In Make würde es als „Scenario“ mit denselben Schritten umgesetzt, das Score-Function-Module hat eingeschränktes JavaScript, dafür ist die visuelle Darstellung auf einen Blick klarer.

DSGVO & Datenhoheit

Hier hat n8n den klarsten Vorteil. Wir empfehlen in 80 % der Engagements n8n self-hosted, weil:

• Daten bleiben physisch im eigenen Rechenzentrum oder in einer eigenen Cloud-Instanz (z. B. Hetzner Falkenstein)
• Keine Verarbeitung auf Server in Drittländern
• Kein Auftragsverarbeitungsvertrag mit dem Tool-Hersteller nötig
• Ihr DSB hat einen entspannten Tag

Make bietet EU-Hosting (Prag, Tschechien) und ist damit DSGVO-vertraglich akzeptabel — aber Sie geben die Daten an einen Dritten weiter. Für viele DSBs ist das eine Diskussion, für andere ein Showstopper.

Lernkurve & Onboarding

n8n: technische Einstiegshürde höher. Wer noch nie mit Webhooks oder JSON gearbeitet hat, hat einen schweren ersten Tag. Sobald die ersten 3-4 Workflows laufen, beschleunigt es deutlich. Setup-Zeit für ein neues Team: 2-4 Wochen bis produktiv.

Make: sehr flacher Einstieg. Auch nicht-technische Nutzer kommen mit Drag-and-Drop schnell zu funktionierenden Scenarios. Der Schritt zu komplexen Aggregator/Iterator-Mustern ist anspruchsvoller, aber niemand muss bis dahin. Setup-Zeit: 1-2 Wochen.

Wenn Sie ein Citizen-Developer-Programm aufbauen wollen (Business-User automatisieren selbst), hat Make einen klaren Vorteil. Wenn Sie ein Operations-Engineering-Team haben, ist n8n stärker.

Wann Code-Flexibilität wirklich wichtig wird

n8n's freier JavaScript- und Python-Knoten ist nicht nur ein „nice-to-have“. Drei Szenarien, in denen er den Ausschlag gibt:

1. KI-Prompt-Engineering: dynamische Prompts, Conditional Logic basierend auf vorherigen Antworten, Token-Counting, Retry-Logik bei Rate-Limits — alles im Code-Knoten viel sauberer als in GUI-Schritten.

2. Datenverarbeitung mit Bibliotheken: in n8n's Code-Knoten haben Sie Zugriff auf npm-Packages. Brauchen Sie cron-parser, jspdf, csv-stringify? Direkt einbinden. Make hat das nicht.

3. Komplexe Transformationen: Daten aus 4 Quellen joinen, deduplizieren, scoren — in einem Code-Knoten 40 Zeilen, in Make 12 GUI-Schritte mit Iteratoren.

Wer regelmäßig Code-Knoten braucht, wählt n8n. Wer das nie braucht, kann ohne Bedauern Make wählen.

Visualisierung & Debugging

Hier sticht Make heraus. Die visuelle Workflow-Darstellung ist objektiv schöner und intuitiver. Bubbles, klare Kanten, Live-Animation der Daten beim Test-Lauf. Es macht Spaß damit zu arbeiten.

n8n hat in 2025 visuell deutlich aufgeholt — die neue Canvas-Engine ist viel besser als noch vor einem Jahr. Aber Make bleibt vorne.

Beim Debugging: Make zeigt nach jedem Module die Daten als JSON-Tree, was sehr nützlich ist. n8n zeigt das auch, aber etwas weniger elegant.

Wann beide Tools nicht das richtige sind

In ehrlich geführten Engagements landen wir oft an dem Punkt, an dem die Frage „n8n oder Make?“ eigentlich falsch ist. Drei Anzeichen:

1. Sie brauchen lange laufende, regelbasierte Geschäftsprozesse mit Genehmigungen, Eskalationen, Wiedervorlagen. Das ist BPMN-Territorium — wählen Sie Camunda oder eine andere BPMN-Engine.

2. Sie haben Daten-Pipelines mit Hunderttausenden Records pro Lauf, ETL/ELT-Charakter. Das ist Apache Airflow, Dagster oder Prefect. n8n und Make sind nicht dafür gemacht.

3. Ihre 50 Workflows sind unkoordinierte Inseln — niemand weiß, was wo läuft, und einer der Workflows hat eine Race-Condition mit einem anderen, die niemand sieht. Hier hilft kein Tool, hier hilft Operating Architecture.

Empfehlung pro Use-Case

Migration zwischen den Tools

Wir haben mehrfach Migrationen begleitet. Beobachtungen:

Zapier → Make: sehr einfach. Konzepte sehr ähnlich, oft 1:1-Umsetzung möglich.

Zapier → n8n: mittlerer Aufwand. Konzeptionell ähnlich, aber n8n verlangt mehr technisches Verständnis. Lohnt fast immer wegen Kosten und Datenhoheit.

Make → n8n: moderater Aufwand. Aggregator/Iterator-Logik in Make ist anders als in n8n — manche Workflows müssen umgedacht werden, nicht nur umgebaut.

Faustregel: rechnen Sie mit 1-2 Tagen Migrationsaufwand pro mittlerem Workflow. Bei 20 Workflows also 4-8 Wochen kalendarische Zeit, parallel betrieben.

Was wir aus 30 Setups gelernt haben

Die Wahl des Tools ist erfahrungsgemäß die letzte und am wenigsten wichtige Entscheidung. Was vorher entschieden werden muss:

1. Welche Workflows sollen automatisiert werden? Nicht alles, was automatisierbar ist, sollte automatisiert werden. Klare Priorisierung nach Häufigkeit × Schmerz × Stabilität des Inputs.

2. Wer pflegt die Workflows langfristig? Ohne klare Eigentümerschaft erodieren auch die besten Setups. Eine Person mit Mandat, nicht ein Team mit Verantwortung.

3. Wo werden Workflows dokumentiert? Ein Workflow im Tool ist keine Dokumentation. Es braucht ein Verzeichnis: was läuft wo, welcher Input/Output, welche Abhängigkeiten.

4. Wie wird gemessen, ob die Automatisierung wirkt? Workflow-Logs sind keine KPIs. Wenn nach 6 Monaten niemand sagen kann, wie viele Stunden eingespart wurden, war es Spielzeug.

Die Antworten auf diese vier Fragen sind wichtiger als das Tool. Sie sind Operating-Architecture-Themen.

Fazit

n8n und Make sind beide gute Tools. Die Wahl hängt an drei Achsen:

• Self-Hosting nötig? → n8n
• Citizen-Developer / Nicht-Tech-Team? → Make
• KI-Workflows / Code-Flexibilität gefragt? → n8n

Aber: das Tool ist selten das eigentliche Problem. Wenn Ihr Team mit Workflow-Wildwuchs kämpft, hilft kein Tool-Wechsel. Es hilft eine Disziplin, die Workflows als Teil einer Architektur versteht.

Mehr dazu in unserer Standortbestimmung zu Operating Architecture — oder direkt in 30 Min: Erstgespräch buchen.