make.com Performance & Operations-Optimierung: Bundle-Size, Filter, Aggregatoren (2026)

Warum Performance in Make.com gleich Geld bedeutet

Anders als bei n8n (self-hosted) oder einem eigenen Worker zahlst du in Make für jede ausgeführte Operation. Ein Szenario, das 10.000 Bundles pro Tag verarbeitet und pro Bundle 8 statt 4 Operationen braucht, kostet dich am Ende des Monats das Doppelte – ohne dass irgendjemand mehr Output bekommt.

Performance-Optimierung in Make ist deshalb keine kosmetische Übung, sondern direkt sichtbare Cost Engineering. Und sie verbessert nebenbei auch noch Laufzeit, Stabilität und Wartbarkeit.

Die fünf Hebel im Überblick

Hebel	Effekt auf Operations	Effekt auf Laufzeit	Aufwand
Filter früh setzen	⬇⬇⬇	⬇⬇	Niedrig
Bundle-Size reduzieren	⬇⬇	⬇⬇⬇	Mittel
Aggregator statt Loop	⬇⬇	⬇⬇	Mittel
Sub-Szenarien & Parallelisierung	⬇	⬇⬇⬇	Hoch
Caching via Data Stores	⬇⬇⬇	⬇⬇	Mittel

Im Rest des Artikels gehen wir jeden Hebel mit konkreten Patterns durch.

Hebel 1: Filter so früh wie möglich

Regel: Jeder Bundle, der nach Modul N nicht mehr gebraucht wird, hätte nach Modul 1 verworfen werden müssen.

Anti-Pattern

Trigger: List Items (500 Bundles)
  → Get additional data (500× API-Call)
    → Transform (500×)
      → Filter: only status = "active" (50 Bundles übrig)
        → Write to monday (50×)

Kosten: 500 + 500 + 500 + 50 = 1.550 Operationen für 50 sinnvolle Outputs.

Pattern

Trigger: List Items mit Server-Side-Filter "status=active" (50 Bundles)
  → Get additional data (50×)
    → Transform (50×)
      → Write to monday (50×)

Kosten: 50 + 50 + 50 + 50 = 200 Operationen. Faktor 7 Ersparnis.

Konkret heißt das

• Server-Side filtern wann immer die API es erlaubt (monday Items by Column Value, Airtable Filter Formula, HubSpot Search API mit Filter Group)
• Make-Filter direkt nach dem Trigger einsetzen, nicht erst vor dem letzten Modul
• Router mit Filter statt mehrerer paralleler Filter-Pfade – einmal entscheiden, dann splitten

Hebel 2: Bundle-Size aktiv kontrollieren

Jedes Modul transportiert ein Bundle. Je größer das Bundle, desto langsamer die Verarbeitung – besonders bei JSON-Parsing, Iteratoren und HTTP-Requests.

Pattern: Set Variable mit Whitelist

Direkt nach dem Trigger ein Set Multiple Variables-Modul, das nur die Felder weitergibt, die wirklich gebraucht werden:

{
  "id": {{1.id}},
  "email": {{1.contact.email}},
  "amount": {{1.deal.amount}}
}

Statt das komplette 50-Felder-Bundle weiterzuschleifen, arbeitet die Restkette mit einem schlanken 3-Felder-Objekt. Effekte:

• HTTP-Module sind messbar schneller
• Iterator/Aggregator-Speicher schrumpft drastisch
• Du dokumentierst implizit, welche Daten überhaupt verwendet werden

Anti-Pattern: "Pass through everything"

Nie das ganze {{1.}}-Bundle in einen HTTP-Body kippen, "weil das Backend sich schon das Richtige rauspickt". Das verschwendet Bandbreite, vergrößert Logs und macht Schema-Änderungen unsichtbar gefährlich.

Hebel 3: Aggregator statt Iterator + Loop

Iteratoren in Make multiplizieren die Operations-Zahl mit der Bundle-Anzahl. Bei großen Listen ist das tödlich. Aggregatoren rollen mehrere Bundles in eines zusammen – und damit auch deren API-Calls.

Anti-Pattern: 100× Einzel-Insert

Iterator (100 Bundles)
  → HTTP POST /api/items (100× ein Item)

Kosten: 100 Operationen + 100 API-Calls + Rate-Limit-Risiko.

Pattern: Array Aggregator → Bulk-Insert

Iterator (100 Bundles)
  → Array Aggregator (group all)
    → HTTP POST /api/items/bulk (1× 100 Items)

Kosten: 1 Operation für den Bulk-Call. Plus: viele APIs (monday, HubSpot, Notion, Airtable) liefern Bulk-Endpoints mit deutlich besserer Rate-Limit-Quote.

Wann welcher Aggregator?

Aggregator	Use Case
Array Aggregator	Mehrere Bundles → ein JSON-Array (Bulk-API-Calls)
Text Aggregator	Bundles → ein Text (Slack-Message, E-Mail-Body, Markdown-Report)
Numeric Aggregator	Summen, Durchschnitte, Zählungen
Table Aggregator	CSV/HTML-Tabellen für E-Mails oder Reports

Hebel 4: Sub-Szenarien & Parallelisierung

Sub-Szenarien sind in Make das, was Funktionen im Code sind: wiederverwendbare Bausteine mit klarem Interface (Input + Output). Sie bringen drei Performance-Vorteile:

1. Parallelisierung: Sub-Szenarien laufen asynchron in eigenen Workern
2. Granularität: Du kannst einzelne Sub-Szenarien gezielt skalieren oder neu deployen
3. Wartbarkeit: Bug-Fix an einer Stelle wirkt überall

Pattern: Fan-Out mit Sub-Szenarien

Hauptszenario:
  Trigger → Iterator (1.000 Bundles)
    → Make a call: "process-single-item" Sub-Szenario (async)

Sub-Szenario "process-single-item":
  Trigger: Webhook
    → Enrich → Validate → Write

Statt seriell 1.000 Bundles im Hauptszenario abzuarbeiten, feuert das Hauptszenario 1.000 Webhook-Calls und ist nach Sekunden fertig. Die Sub-Szenarien laufen parallel mit deinem Operations-Plan-Limit.

⚠️ Vorsicht bei Rate-Limits der Ziel-API. Parallelisierung verschiebt das Bottleneck oft vom Make-Worker zur Ziel-API. Plane Throttling über Sleep-Module oder Queue-Patterns ein.

Anti-Pattern: Monster-Szenario

Ein einziges Szenario mit 40 Modulen, drei Routern und zwei verschachtelten Iteratoren ist:

• Schwer zu testen
• Schwer zu monitoren
• Bei einem einzigen Fehler komplett am Boden

Faustregel: Wenn ein Szenario mehr als 15–20 Module hat, gehört es aufgeteilt.

Hebel 5: Caching via Data Stores

Wiederholte API-Calls für selten ändernde Daten sind reines Operations-Verbrennen. Make Data Stores eignen sich als günstiger Cache.

Pattern: Lookup-Cache für Stammdaten

1. Search Data Store: key = customer_id
2. Router:
   - Branch A: Wenn gefunden → Bundle hat Daten, weiter
   - Branch B: Wenn nicht → API-Call → Add to Data Store → weiter

Erster Call eines customer_id kostet einen API-Call. Alle weiteren – bis zum TTL-Ablauf – sind ein einzelner Data-Store-Read. Bei 1.000 Bundles mit nur 50 unique Customers spart das 950 API-Calls pro Lauf.

TTL & Invalidierung

Data Stores haben kein natives TTL. Bau dir das:

• Speichere cached_at als Feld
• Filter beim Lookup: cached_at > now() - 24h
• Periodisches Cleanup-Szenario, das alte Records löscht

Performance-Anti-Patterns auf einen Blick

❌ Filter ganz am Ende statt am Anfang – multipliziert Operationen 5–20×

❌ HTTP-Module ohne Timeout – ein hängendes API kann ein ganzes Szenario blockieren und die Operations bis zum Timeout verbrennen

❌ Iterator → einzelne Inserts – statt Array Aggregator → Bulk-Insert

❌ Volle Bundles durch alle Module schleifen – statt Set Variable mit Whitelist

❌ "Run scenario every minute" für Polling – statt Webhook oder Trigger-Modul

❌ Wiederholte API-Calls für gleiche Stammdaten – statt Data-Store-Cache

❌ Ein Mega-Szenario – statt sauber geschnittene Sub-Szenarien

Mess- und Optimierungs-Workflow

Ohne Messung ist Optimierung Glücksspiel. So gehst du strukturiert vor:

1. Baseline messen

• Operations pro Lauf: aus Make-History
• Laufzeit: Differenz started_at / finished_at
• Bundle-Anzahl pro Modul: in Run-Detail sichtbar

2. Hotspots identifizieren

Sortiere die Module nach Operations-Verbrauch. Oft sind 80 % der Operationen in 20 % der Module – meistens HTTP-Calls in Loops oder fehlende frühe Filter.

3. Eine Änderung pro Iteration

Optimiere immer eine Variable, miss erneut, vergleiche. Sonst weißt du nicht, welcher Hebel was gebracht hat.

4. Operations-Budget definieren

Lege pro kritischem Szenario ein Operations-Budget pro Bundle fest (z.B. "Max 8 Ops pro Lead"). Sobald ein Lauf signifikant darüber liegt, ist das ein Alarm-Signal – meistens hat sich an der API-Antwort oder den Eingangsdaten etwas geändert.

Ergänzend: Wie du Operations und Laufzeit kontinuierlich überwachst, zeigt unser Monitoring & Observability Guide.

Praxis-Checkliste für Performance-Reviews

• Filter sitzen direkt nach Trigger oder Datenquelle
• Server-Side-Filter genutzt, wo API es erlaubt
• Set Variable mit Whitelist nach dem Trigger
• Iteratoren laufen über Aggregatoren in Bulk-Calls
• Bulk-Endpoints der Ziel-APIs genutzt
• Sub-Szenarien für wiederverwendete Logik
• Lange Loops parallelisiert via Sub-Szenario-Webhooks
• Wiederholte Lookups gecacht via Data Stores
• HTTP-Module haben Timeout & Error-Routes
• Operations-Budget pro Szenario dokumentiert
• Monitoring auf Operations-Trend aktiv

Verwandte Guides

• make.com Automatisierung – Der ultimative Guide
• Error Handling & Retry-Strategien
• Monitoring & Observability für make.com
• Security & Secrets-Management in make.com
• Make Module Migrator: monday.com V1 zu V2
• n8n Best Practices Guide

Wir tunen produktive Make-Setups

Als make.com Certified Partner machen wir Performance-Audits für Teams mit hohen Operations-Volumen. Typisches Ergebnis: 40–70 % Operations-Ersparnis bei gleichzeitig schnellerer und stabilerer Ausführung.

→ Performance-Audit anfragen