Die falsche Frage stellen
Ich sitze mit einem CTO zusammen und er fragt: "Sollen wir n8n oder Make nehmen?" Das ist die falsche Frage. Die richtige Frage ist: "Welche Anforderungen habe ich, und welche Tools erfüllen sie am besten?"
Der richtige Tech-Stack für KI-Automatisierung ist nicht eine Meinung. Er ist ein Engineering-Decision, basierend auf Anforderungen, Team-Kapazität und Kosten. In diesem Post gebe ich dir die Frameworks, um den Stack für dein Projekt zu wählen.
Automatisierungs-Plattformen: n8n vs Make vs Zapier
Zapier: Der Low-Code Standard
Zapier ist das sichere Spiel. Es funktioniert, es hat einen riesigen Connector-Marktplatz, und es braucht fast keine technische Expertise. Ein Product-Manager kann Workflows aufbauen. Die Anbindung an 7000+ Apps ist out-of-the-box.
Wann Zapier die richtige Wahl ist:
- Dein Tech-Team ist klein oder non-existent
- Du brauchst Standard-Integrationen (Salesforce, HubSpot, Slack, etc.)
- Der Workflow ist relativ linear und nicht hochkomplex
- Du zahlst pro Task/Ausführung und hast vorhersehbare Volumina
Wann Zapier die falsche Wahl ist:
- Du brauchst benutzerdefinierte Logic oder API-Anfragen
- Die Latenz muss unter 2 Sekunden sein
- Du hast hochvariable Volumina und brauchst Kostenoptimierung
- Dein Workflow braucht Kontexten oder State-Management über mehrere Schritte
Make (früher Integromat): Der Mittelweg
Make bietet mehr Flexibilität als Zapier, ist aber immer noch No-Code/Low-Code. Du kannst komplexere Workflows mit Bedingungen, Loops und Error-Handling bauen. Die Preisstruktur ist fairer für hohe Volumina (Pay-for-Operations, nicht Executions).
Wann Make die richtige Wahl ist:
- Du brauchst mehr Kontrollfluss als Zapier anbietet
- Du hast hohe Transaktionsvolumina und brauchst bessere Kosteneffizienz
- Dein Team kann basales Low-Code-Scripting, aber hat keine Backend-Developers
- Du willst Webhooks, Datenbereinigung und etwas komplexere Logik
Wann Make die falsche Wahl ist:
- Du brauchst wirklich benutzerdefinierte Business-Logic oder Algorithms
- Dein Workflow braucht Machine-Learning-Integration oder Advanced-Analytics
- Deine Infrastruktur ist Self-Hosted und Compliance-Anforderungen sind hoch
n8n: Der vollständig programmierbare Stack
n8n ist Open-Source und selbst-gehostet. Du hast vollständige Kontrolle. Du kannst JavaScript schreiben. Du kannst komplexe Logik bauen. Die Community ist aktiv und die API ist exzellent dokumentiert.
Wann n8n die richtige Wahl ist:
- Du hast Backend-Engineers, die Node.js/JavaScript kennen
- Du brauchst Self-Hosting aus Compliance- oder Datenschutzgründen
- Deine Workflows sind hochkomplex und brauchen benutzerdefinierte Code
- Du willst keine Vendor-Lock-in und brauchst Portabilität
- Dein Volumen ist so hoch, dass Make/Zapier Kosten prohibitiv werden
Wann n8n die falsche Wahl ist:
- Du hast kein Engineering-Team, das Deployments und Upgrades verwalten kann
- Du brauchst schnelle Connector-Updates und willst die Maintenance nicht tragen
- Dein Projekt ist klein und eine SaaS-Lösung ist einfacher
LLM-Anbieter: OpenAI vs Anthropic vs Open Source
OpenAI: Der Produktionsstandard
OpenAI (GPT-4) hat die höchste all-around Competence. Das Modell ist gut bei Reasoning, Code-Generation, und General-Purpose-Tasks. Die API ist stabil und hat massive Scale.
Wann OpenAI die richtige Wahl ist:
- Du brauchst General-Purpose-NLP (Text-Zusammenfassung, Kategorisierung, QA)
- Dein Use-Case braucht Versatilität über verschiedene Tasks
- Du hast Budget und willst die sicherste Wahl
- Du brauchst Vision-Capabilities (Bildverarbeitung)
Kosten: Ca. 0,03 USD pro 1000 Input-Tokens, 0,06 USD per 1000 Output-Tokens (GPT-4).
Anthropic Claude: Die spezialisierte Alternative
Anthropic Claude ist in spezifischen Bereichen besser als GPT-4: Langer-Text-Understanding, logisches Reasoning, und expliziter Sicherheits-Alignment. Das Modell hat ein 200k-Context-Fenster nativ, was bedeutet, du kannst ganze Dokumente in einem Prompt einbinden.
Wann Claude die richtige Wahl ist:
- Du brauchst Long-Context-Processing (ganze Verträge, lange Artikel analysieren)
- Dein Use-Case braucht konsistentes, strukturiertes Output
- Du brauchst hohe Qualität bei Reasoning-Tasks und wenig Halluzination
- Du willst explizit bessere Sicherheit und Bias-Vermeidung
Kosten: Ca. 0,003 USD pro 1000 Input-Tokens, 0,015 USD per 1000 Output-Tokens (Claude 3 Sonnet).
Open-Source-Modelle: Der kostengünstige Weg
Modelle wie Llama 2 (Meta), Mistral 7B, oder Phi (Microsoft) können selbst-gehostet werden. Du zahlst für Compute, nicht für API-Aufrufe. Wenn dein Volumen massiv ist (100M+ Tokens täglich), kann das günstiger sein.
Wann Open-Source die richtige Wahl ist:
- Dein Volumen ist extrem hoch und API-Kosten wären prohibitiv
- Du brauchst Data-Privacy und kannst nicht mit externen APIs arbeiten
- Du hast ein spezialisiertes Use-Case und willst Fine-Tuning
- Du hast die Infrastruktur und Engineers, um selbst-gehostete Modelle zu betreiben
Achtung: Open-Source-Modelle sind heute 10-20% schlechter in Qualität als proprietäre Modelle, haben mehr Halluzination und brauchen mehr Tuning.
Vector Databases: Supabase vs Pinecone vs PostgreSQL pgvector
Wenn du Retrieval-Augmented-Generation (RAG) brauchst, brauchst du eine Vector-DB.
Pinecone: Der vollständig verwaltete Service
Pinecone ist einfach. Du uploadst Embeddings, machst Similarity-Searches. Keine Selbst-Verwaltung. Aber teuer bei großen Mengen.
Wann Pinecone:
- Kleine bis mittlere Mengen (unter 10M Embeddings)
- Du brauchst nicht viel DevOps-Überhead
Supabase (PostgreSQL mit pgvector): Der Mittelweg
Supabase ist PostgreSQL mit pgvector-Extension. Das ist günstig, skalierbar und relativ einfach zu verwalten. Du kriegst auch normale SQL-Funktionalität.
Wann Supabase:
- Du brauchst Hybrid-Suche (Vector + SQL)
- Mittlere bis große Mengen (10M+ Embeddings)
- Du willst gutes Preis-Leistungs-Verhältnis
Self-Hosted PostgreSQL pgvector: Der günstige Weg
Wenn du die Infrastruktur selbst hostest, ist pgvector kostenlos. Du kontrollierst alles. Aber DevOps-Verantwortung liegt bei dir.
Das gesamte Bild: Ein Entscheidungsfluss
Hier ist die konkrete Decision-Tree:
Für Automatisierungs-Plattformen:
Hast du Backend-Engineers? JA -> n8n. NEIN -> Ist dein Workflow komplex? JA -> Make. NEIN -> Zapier.
Für LLMs:
Brauchst du Long-Context oder Spezial-Reasoning? JA -> Claude. NEIN -> Brauchst du Volumen-Kostenoptimierung? JA -> Open Source (mit DevOps). NEIN -> OpenAI.
Für Vector Databases:
Self-Hosted Infrastructure? JA -> pgvector. NEIN -> Brauchst du Hybrid-Search? JA -> Supabase. NEIN -> Kleine Mengen? -> Pinecone.
Die Realität
Die meisten produktiven Setups sind Hybride. Du kannst Zapier für Standard-Integrationen haben, n8n für komplexe Workflows, und Claude API für LLM-Tasks. Das ist nicht Overkill, das ist Pragmatismus.
Die teuerste Wahl ist die falsche Wahl. Wähle basierend auf deinen Anforderungen, nicht auf Hype.
