> n8n vs Python custom: quando conviene l'uno o l'altro per automatizzare processi

Chi lavora su automazione sa che questa domanda arriva sempre: "Ma non è più veloce usare n8n invece di scrivere Python?" oppure "Il cliente chiede un'automazione: faccio un workflow in n8n o mi scrivo uno script?". La risposta vera è "dipende", ma non nel senso vago. Dipende da cose concrete e misurabili.

# Il trade-off reale

n8n è uno strumento di workflow automation: trascini nodi, connetti le cose, clicchi, finito. Python è un linguaggio: scrivi codice, gestisci dipendenze, testi, deployi. Sembrano opposti, ma il trade-off è tra velocità iniziale e flessibilità a lungo termine.

n8n vince su:

• Tempo di setup iniziale (ore, non giorni).
• Manutenzione se il flusso non cambia mai.
• Visibilità del flusso: chiunque apre n8n e vede cosa succede.
• Costi infrastrutturali bassi se usi il cloud di n8n.
• Zero dipendenze da installare.

Python custom vince su:

• Logica complessa: cicli, condizioni annidate, calcoli.
• Integrazione profonda con librerie specifiche (pandas, scikit-learn, custom logic).
• Portabilità: gira ovunque Python sia disponibile.
• Controllo totale su errori, retry, timeout, logging.
• Scalabilità: un container Docker vs limiti di n8n cloud.
• Costi a lungo termine: se già gestisci server, Python aggiunge poco.

# Quando scegliere n8n

n8n è la scelta giusta quando il flusso è lineare e stabile. Intendo: dati entrano da qui, si trasformano, escono di là, fine. Non cambia mai. Nessun algoritmo complesso.

Esempi reali:

• Leggere email, estrarre allegati, salvarli su Google Drive, mandare notifica Slack.
• Ogni mattina: query al DB, trasforma i risultati, invia report via email.
• Webhook riceve ordine → aggiorna CRM → avvia email automazione → log su Airtable.
• Sincronizzazione bidirezionale tra due app: Form → Zapier-style trigger → destination.

In questi casi, n8n è più veloce da costruire (1-3 ore), più facile da debuggare visualmente, e il cliente può persino modificarlo da solo se le richieste sono piccole.

Costo tipico: n8n cloud parte da ~20 euro/mese (piano base), o self-hosted gratis se hai già un server. Tempo sviluppo: 2-8 ore per un flusso medio.

# Quando scegliere Python custom

Python è necessario quando il flusso ha complessità che n8n non gestisce bene:

• Logica condizionale profonda: "Se il valore è tra A e B, fai X; se tra B e C, fai Y; ma se è assente, query il DB, e se il DB torna null, chiama l'API di fallback". n8n diventa un spaghetto di nodi.
• Elaborazione dati: manipolazione complessa, aggregazioni, trasformazioni non lineari. pandas rende questo banale.
• Machine learning o AI: se il flusso include un modello, preprocessing, LLM calls con prompt engineering, Python è l'unico ambiente decente.
• Scalabilità e throughput: n8n cloud ha limiti di execution, task parallelism. Python su Kubernetes o ECS no.
• Sicurezza e audit: in contesti regulated, il codice versioned su Git, review board, audit trail è uno standard; n8n cloud è meno auditable.
• Integrazioni custom profonde: un'API non documentata, endpoint stranieri, logica di retry peculiare. Python ti dà il totale controllo.

Esempi:

• Sistema di scoring clienti: ricevi dati, elabori con logica custom, aggreghi da 3 fonti, chiami un modello, scrivi il risultato solo se passa una soglia.
• Pipeline RAG: documenti → chunking → embedding → query vettoriale → LLM → response → log. n8n non è adatto.
• ETL aziendale: dati da 5 DB diversi, normalizzazione complessa, deduplicazione, validazione. Meglio Python + dbt.

Costo tipico: 40-160 ore di sviluppo (1-4 settimane), hosting €5-50/mese su VPS o cloud. Manutenzione ongoing.

# La tabella decisionale

Fattore	n8n	Python
Tempo setup	Ore	Giorni/settimane
Complessità logica	Bassa-media	Arbitraria
Costo infrastruttura/mese	20-200€ (cloud)	0€ (se server exist) a 50€
Curva di apprendimento	1-2 giorni	Dipende dalla base
Scalabilità	Media (limiti cloud)	Alta
Debuggabilità	Visuale, facile	Log, traceback, più duro
Manutenzione	Bassa se stabile	Media-alta
Cambiamenti futuri	Facili se piccoli	Più strutturati, testing

# L'errore più comune

# L'approccio ibrido (la vera risposta)

In pratica, nella mia esperienza, spesso la soluzione migliore è né l'uno né l'altro puro:

• n8n per l'orchestrazione: gestisce il flusso principale, i webhook, le notifiche.
• Python come nodo custom in n8n: n8n ha un nodo "Execute code" (JavaScript) e puoi anche triggerare script Python esterni via HTTP o webhook. Per la logica complessa, chiami il tuo microservizio Python da dentro n8n.

Questo combina il meglio: velocità iniziale di n8n, flessibilità di Python dove serve.

Quando questa ibrida NON conviene: se il 70%+ della logica è Python, allora fai tutto in Python. Se è solo un 5% di logica edge case, allora l'ibrido aggiunge overhead.

# Chi mi contatta per automazione

Le domande giuste che mi pongo con un cliente sono:

1. Quanto è stabile il flusso? (Cambia ogni settimana? Ogni anno?)
2. Quanto è complessa la logica? (Click-click flusso, o calcoli sofisticati?)
3. Quanti dati? (Centinaia di record/giorno o milioni?)
4. Qual è il team che lo manterrà? (Non-tech che sa n8n, o engineer Python?)
5. Compliance/audit richiesti? (Se sì, probabilmente Python versioned su Git.)

Le risposte determinano lo strumento, non il contrario.

# Quando NON automatizzare

Ultimo punto, brutalmente onesto: a volte la risposta è "non fare nulla". Se un processo manuale è stabile, tocca pochissimi record al mese, e il costo di automazione è alto (sia n8n che Python), lasciale le cose come stanno. L'automazione ha senso quando il guadagno (tempo risparmiato, errori ridotti, latenza) supera il costo (setup + manutenzione).