n8n vs Make.com vs Zapier — welches Tool wann?

n8n, Make und Zapier lösen oberflächlich dasselbe Problem — und sind unter der Haube fundamental verschieden. Ein nüchterner Vergleich entlang Pricing, Komplexität, Self-Hosting, Integrationen und DSGVO, plus klare Empfehlungen pro Use-Case.

Drei Tools, drei Philosophien

Wenn ein Geschäftsprozess automatisiert werden soll, fällt fast immer einer dieser drei Namen: Zapier (seit 2011, mit Abstand die breiteste Integration), Make.com (ehemals Integromat, visuell-zentriert, EU-Hosting), n8n (Open Source, selbst-hostbar, code-fähig).

Oberflächlich tun sie dasselbe: Trigger empfangen, Daten transformieren, Aktionen auslösen. Unter der Haube sind sie aber so unterschiedlich, dass die Wahl massive Auswirkungen auf Wartbarkeit, Kosten und DSGVO-Story hat.

Wir setzen alle drei produktiv ein — die Frage ist nie „welches ist das beste?", sondern „welches passt zu diesem konkreten Use-Case?".

Pricing 2026 im Vergleich

Die Pricing-Modelle sind völlig verschieden, was direkte Vergleiche erschwert:

• Zapier rechnet nach „Tasks". Ein Task = eine Aktion. Ein Workflow mit Trigger → 3 Aktionen = 3 Tasks pro Ausführung. Professional-Plan startet bei 29 USD/Monat (750 Tasks), realistische Production-Pläne liegen bei 99–299 USD.
• Make rechnet nach „Operations". Eine Operation = ein Modul-Ausführung. Ähnlich wie Zapier-Tasks, aber Make zählt z.B. Filter-Schritte separat. Pro-Plan startet bei 16 USD/Monat (10.000 Ops), Teams 29 USD (10.000 Ops + Shared), Enterprise auf Anfrage. Operations sind deutlich günstiger als Zapier-Tasks.
• n8n Cloud rechnet nach „Workflow-Executions" — ein kompletter Workflow-Run = 1 Execution, egal wie viele Steps. Starter 24 EUR/Monat (5.000 Executions), Pro 60 EUR (20.000). Self-Hosted ist kostenlos (Community Edition) — man zahlt nur Server.

Konkretes Beispiel: ein Workflow mit 12 Steps, 1.000 Runs pro Monat. Zapier: 12.000 Tasks → Team-Plan 103 USD. Make: ca. 14.000 Ops → Pro-Plan 16 USD reicht. n8n Self-Hosted: 5 EUR Hetzner-VPS-Anteil.

Pro Run und Step ist n8n bei Eigen-Hosting fast immer um Größenordnungen günstiger — der Trade-Off ist Setup-Aufwand.

Workflow-Komplexität: wer kann was?

Hier liegt der größte praktische Unterschied:

Zapier — flach

Klassisches „wenn dies, dann das". Conditional Paths gibt's, aber Loops sind eingeschränkt und Code-Steps (JavaScript/Python) sind erst ab dem Pro-Plan verfügbar. Komplexe Datentransformationen muss man oft in einen externen Code-Step auslagern oder via Formatter mühsam zusammenklicken.

Make — visuell und mächtiger

Verschachtelte Loops, Aggregatoren, Router, Custom-Functions per JSONata. Visuell sehr stark, weil das Diagramm immer den ganzen Flow zeigt. Bei sehr großen Workflows (50+ Module) wird das Diagramm aber unübersichtlich. Code-Steps sind möglich, aber begrenzter als bei n8n.

n8n — Code-fähig

Pro Node kann man vollständigen JavaScript- oder Python-Code ausführen, npm-Pakete installieren (im Self-Hosted), eigene Datenstrukturen halten. Sub-Workflows, Conditional Branches, Loops, sogar parallele Executions sind native Funktionen. Wer mit Code arbeiten kann, kommt mit n8n um Größenordnungen weiter als mit den anderen beiden.

Konkret: ein Workflow, der eine Liste von Leads aus Apollo holt, jeweils via Claude klassifiziert, dann je nach Score in unterschiedliche Pipedrive-Stages packt und parallel Slack-Alerts versendet — in n8n eine Stunde, in Make zwei Stunden, in Zapier nur mit externer Logik (z.B. via Webhook auf ein eigenes Skript).

Self-Hosting: der n8n-Vorteil

Nur n8n erlaubt echtes Self-Hosting. Die Community Edition läuft Docker-basiert auf jedem Server — wir nutzen typischerweise einen CX22-Hetzner-VPS in Falkenstein (4 vCPU, 8 GB RAM, ~7 EUR/Monat), der locker mehrere zehntausend Executions pro Tag stemmt.

Self-Hosting hat drei massive Vorteile:

• DSGVO-Klarheit: Die Daten verlassen nie den eigenen Server. Kein Cross-Border-Transfer, kein US-Provider, kein Schrems-II-Drama.
• Keine Volumen-Limits: Wir haben Workflows mit 800.000 Executions pro Monat laufen — wäre auf Cloud-Plänen vierstellig im Monat.
• Custom-Code: Eigene npm-Pakete, eigene Binaries, sogar lokales Python für ML-Aufgaben. In Cloud-Plänen ist das gesperrt.

Make hat optional EU-Hosting (Datacenter in Prag), das DSGVO-rechtlich akzeptabel ist. Zapier sitzt komplett in den USA — für sensible Daten (Personalakten, Gesundheitsdaten, Kommunikation mit Endkunden) ist das mindestens diskussionswürdig.

Integrations-Breadth: hier gewinnt Zapier

Zapier hat bei der Anzahl Apps mit Vorsprung die Nase vorn — über 7.000 Apps mit fertigen Connectoren. Für jedes obskure SaaS-Tool gibt's wahrscheinlich eine Zapier-Integration.

Make liegt bei ca. 2.000 Apps. n8n bei ca. 1.000 (Stand 2026), wachsend.

Allerdings: Was n8n nicht als fertigen Node hat, lässt sich in 5 Minuten via HTTP Request Node bauen — sofern die App eine REST-API hat. Was bei Zapier oder Make ein Show-Stopper wäre, ist bei n8n eine Standard-Übung. Wir bauen regelmäßig Custom-Nodes für exotische APIs (DATEV, Personio, Lexware), wo es weder bei Zapier noch bei Make einen vorgefertigten Connector gibt.

Anders herum: für Teams ohne Tech-Skills, die einfach „Slack → Notion → Google Sheets" verbinden wollen, ist Zapiers App-Library schwer schlagbar.

Performance bei großen Volumen

Bei hohen Volumen (5.000+ Executions/Tag) zeigen sich die echten Unterschiede:

• Zapier wird teuer und langsam — Tasks queuen, Latenzen steigen, manche Apps haben harte Rate-Limits, die nicht überschrieben werden können.
• Make hält Performance besser, aber Operations werden trotzdem zur Kostenfalle.
• n8n Self-Hosted skaliert vertikal (mehr CPU/RAM) und horizontal (Worker-Nodes via Queue Mode). Wir haben Setups mit 5 Worker-Nodes und Redis-Queue, die 100k+ Executions pro Tag verarbeiten — ohne erkennbare Latenz.

Außerdem: bei Workflows, die größere Datenmengen handhaben (z.B. „lese 50.000 Zeilen aus Postgres, verarbeite, schreibe zurück"), kommen Zapier und Make schnell an Memory-Limits. n8n verarbeitet das in Streams, ohne dass der Workflow crasht.

DSGVO-Implikationen

Für deutsche Mittelständler und Agenturen, die mit Kundendaten arbeiten, ist DSGVO oft das Killer-Kriterium.

• n8n Self-Hosted: volle Kontrolle. Daten verlassen die eigene Infrastruktur nicht. Einfach im VVT zu dokumentieren.
• n8n Cloud (EU-Region): AVV mit n8n GmbH (Berlin) verfügbar, akzeptabel.
• Make: EU-Hosting wählbar, AVV-Vorlage existiert. Make Cloud (Tschechien) ist eine EU-Verarbeitung — okay.
• Zapier: US-Hosting (auch mit US-Cloud-Plänen). AVV existiert, aber Daten landen außerhalb der EU. Für viele Use-Cases tolerabel (Schrems-II-Adäquanzbeschluss), für sensible Daten kritisch.

Wer Personalakten, Gesundheitsdaten oder vergleichbar sensible Kategorien verarbeitet, sollte Zapier vermeiden — nicht weil es technisch unsicher wäre, sondern weil die Compliance-Argumentation aufwendig ist.

Empfehlungen pro Use-Case

Wir wählen so:

Use Zapier wenn …

• der Workflow simpel ist (2–4 Steps) und schnell live muss
• das Team aus Nicht-Technikern besteht, die später selbst nachpflegen sollen
• eine exotische App eingebunden werden muss, die nur Zapier connected
• DSGVO-Sensitivität niedrig ist (interne Tools, Marketing-Aggregation)

Use Make wenn …

• der Workflow visuell verständlich bleiben soll (für Team-Übergaben)
• EU-Hosting ein hartes Kriterium ist, aber Self-Hosting overkill wäre
• Standard-Integrationen reichen (HubSpot, Slack, Airtable, Google Workspace)
• mittlere Volumina (1k–50k Ops/Monat) erwartet werden

Use n8n wenn …

• Workflows komplexer sind (10+ Steps, Loops, Conditionals)
• Custom Code Teil der Logik ist (Claude API calls, eigene Datenstrukturen, ML-Steps)
• DSGVO-Klarheit kritisch ist (Self-Hosted)
• große Volumen erwartet werden (10k+ Executions/Tag)
• Tech-Skills im Team verfügbar sind (oder bei einer Boutique wie uns auslagerbar)

In gemischten Setups sieht das oft so aus: Zapier oder Make für die Marketing-Trivial-Flows, die das Marketing-Team selbst baut — n8n für die operative Schicht, in der CRM, Billing, Reporting und AI-Klassifikation zusammenlaufen. Die beiden Welten reden über Webhooks miteinander und haben jeweils den richtigen Job.

Die Frage ist nie „welches Tool ist das beste?". Die Frage ist „welches ist für diesen Workflow das billigste, schnellste und wartbarste?". Drei Antworten, je nach Workflow.