Vuoi trasformare fogli, CRM e fonti web in insight azionabili senza riscrivere script ogni settimana? Collegare n8n a un database relazionale ti permette di costruire pipeline ETL/ELT robuste per reporting, enrichment e sincronizzazioni bidirezionali. Con mysql n8n e l’equivalente per PostgreSQL puoi orchestrare import da CSV/Google Sheets, upsert transazionali, dedup e job schedulati con osservabilità. In questa guida pratica vedrai come scegliere l’architettura giusta, configurare i nodi database, scrivere query sicure con parametri dinamici, gestire batching e paginazione, e – quando serve – migrare n8n da SQLite a un database esterno per scalare in produzione. Troverai snippet pronti all’uso, configurazioni esatte dei nodi e best practice per sicurezza (SSL/TLS, least privilege), resilienza (retry/backoff) e controllo costi (rate limit, caching dei delta). Obiettivo: un blueprint chiaro per integrare dati in modo affidabile, con tempi e risultati prevedibili.
[IMG: Panoramica workflow n8n con Google Sheets → Code (normalize) → Split In Batches → MySQL/PostgreSQL → Slack report]
Perché collegare n8n a PostgreSQL o MySQL: casi d’uso e architetture
Collegare n8n a un RDBMS apre tre macro‑scenari per marketer e ops:
- Integrazioni ETL/ELT e reporting: centralizza dati da Google Sheets, CRM, piattaforme adv e strumenti di support in tabelle normalizzate per BI e dashboard.
- Sincronizzazioni bidirezionali: allinea anagrafiche e attributi (consenso, segmenti) tra sorgenti diverse, con operazioni CRUD e upsert nei database.
- Automazioni su eventi: scatta azioni quando arrivano nuovi record (lead, ordini, ticket), arricchisci e scrivi in output su PostgreSQL/MySQL.
Pattern architetturali tipici:
- Staging → Master: carica dati grezzi in tabelle staging, normalizza e consolida in tabelle master con idempotenza e dedup.
- Hub & Spoke: il DB funge da “hub” per orchestrare arrivi/uscite (CRM, sheet, email marketing), con job schedulati che leggono/scrivono.
- Event‑driven: usa trigger in ingresso (webhook, cron) per aggiornare il DB e scatenare flussi downstream (es. alert Slack se threshold superati).
Benefici pratici per i team marketing:
- Meno copia‑incolla, più consistenza: il database diventa la “fonte di verità” con storicizzazione e tracciabilità.
- Query ad‑hoc: rispondi a domande operative velocemente (KPI per campagna, segmenti) con data freschi e certificati.
- Scalabilità: con batching e pianificazione, i job restano affidabili anche con volumi crescenti.
Parole chiave da mettere a terra: integrazione di n8n con PostgreSQL, integrazione di n8n con MySQL, importare CSV o Google Sheets in un database con n8n, sincronizzazione dati tra CRM e database.
Configurare le connessioni nei workflow: nodi, credenziali e sicurezza
In n8n, l’accesso ai database avviene tramite nodi specifici e credenziali salvate in modo sicuro. I nodi di riferimento:
- nodo MySQL in n8n: type “n8n-nodes-base.mySql”
- nodo PostgreSQL in n8n: type “n8n-nodes-base.postgres”
Ogni nodo referenzia una credenziale pre‑configurata:
- MySQL credentials: campo credentials “mySql” con il nome della credenziale (es. “My MySQL DB”)
- PostgreSQL credentials: campo credentials “postgreSql” con il nome della credenziale (es. “Your PostgreSQL DB”)
Esempio: MySQL “Execute Query” con parametro dinamico
{
"name": "MySQL Query",
"type": "n8n-nodes-base.mySql",
"typeVersion": 2,
"parameters": {
"operation": "executeQuery",
"query": "SELECT * FROM users WHERE id = {{ $json[\"user_id\"] }}"
},
"credentials": {
"mySql": { "name": "My MySQL DB" }
}
}
Esempio: PostgreSQL “Execute Query” con parametro dinamico
{
"name": "PostgreSQL Query",
"type": "n8n-nodes-base.postgres",
"typeVersion": 2,
"parameters": {
"operation": "executeQuery",
"query": "SELECT * FROM users WHERE id = {{ $json[\"user_id\"] }}"
},
"credentials": {
"postgreSql": { "name": "Your PostgreSQL DB" }
}
}
Sicurezza:
- Utenti con privilegi minimi: crea un utente DB con permessi strettamente necessari (SELECT/INSERT/UPDATE su schemi/tabelle target).
- SSL/TLS: abilita SSL lato server e usa connessioni cifrate quando possibile. Se il provider lo richiede, configura i certificati/CA nelle credenziali o nell’infrastruttura di rete.
- Requisiti di rete: metti in allowlist gli IP di uscita di n8n o posiziona n8n e DB nella stessa VPC.
[IMG: Schermata credenziali n8n con connessione MySQL e Postgres configurate]
Query sicure e performanti: CRUD, upsert e parametrizzazione
Con i nodi database puoi eseguire query personalizzate (Execute Query) e coprire operazioni CRUD e upsert. Le espressioni di n8n permettono di passare valori dinamici da item precedenti.
Linee guida per query parametrizzate in n8n:
- Evita di concatenare stringhe con input non sanificati: preferisci espressioni su id/valori convalidati (regex/whitelist).
- Prevenzione SQL injection nelle automazioni: valida sempre gli input provenienti da sistemi esterni (email, form, webhooks).
Esempi pratici (eseguiti via Execute Query):
SELECT con parametro
SELECT id, email, created_at
FROM users
WHERE email = {{ $json["email"] }};
INSERT
INSERT INTO users (name, email, source)
VALUES ({{ $json["name"] }}, {{ $json["email"] }}, 'campaign-2025');
UPDATE
UPDATE users
SET last_seen_at = NOW()
WHERE id = {{ $json["id"] }};
DELETE
DELETE FROM users
WHERE id = {{ $json["id"] }};
Upsert (PostgreSQL)
INSERT INTO users (id, name, email)
VALUES ({{ $json["id"] }}, {{ $json["name"] }}, {{ $json["email"] }})
ON CONFLICT (id) DO UPDATE
SET name = EXCLUDED.name, email = EXCLUDED.email;
Upsert (MySQL)
INSERT INTO users (id, name, email)
VALUES ({{ $json["id"] }}, {{ $json["name"] }}, {{ $json["email"] }})
ON DUPLICATE KEY UPDATE
name = VALUES(name), email = VALUES(email);
Consigli:
- Differenze sintattiche principali tra PostgreSQL e MySQL: LIMIT/OFFSET, funzioni date/time, tipi JSON (json vs jsonb), upsert (ON CONFLICT vs ON DUPLICATE KEY).
- Idempotenza e gestione duplicati: scegli chiavi uniche e costruisci upsert per evitare inserimenti ripetuti.
Paginazione, batching e pooling: performance e resilienza operativa
Per grandi volumi, aggira timeout e limiti con un disegno robusto.
Paginazione e batching nei workflow:
- Leggi a blocchi dal sorgente (LIMIT/OFFSET o keyset pagination) e spingi a valle con “Split In Batches” (es. 50–200 righe a batch).
- Keyset pagination (WHERE id > last_id) è preferibile su LIMIT/OFFSET per dataset ampi: è più stabile e performante.
Pattern di controllo:
- “Split In Batches” → node DB (executeQuery) → IF (error?) → Wait (1–3s) → Execute Next Batch → “No Items” → report.
- Retry con backoff: su errori temporanei (lock, deadlock, 5xx), riprova 1–3 volte (2s → 5s → 10s).
Pooling delle connessioni database:
- Evita aprire/chiudere connessioni ad alta frequenza. Mantieni un batch per transazione logica e limita la concorrenza.
- Se lavori con più nodi DB in parallelo, riduci il parallelismo per diminuire lock e aumentare throughput stabile.
Paginazione e batching nei report:
- Per estrazioni massicce, usa finestre temporali (createdat/updatedat) e salva lo “stato ultimo” per estrarre solo i delta.
[IMG: Sequenza Split In Batches → Execute Query → IF error → Wait → Execute Next Batch]
Migrare n8n da SQLite a un database esterno: variabili d’ambiente e note di deploy
Quando e perché sostituire SQLite:
- Produzione multi‑utente, storicizzazione esecuzioni e credenziali, requisiti di alta affidabilità e backup facili.
- Coordinamento tra più worker/containers.
PostgreSQL (esempio Docker)
docker run -it --rm \
--name n8n \
-p 5678:5678 \
-e DB_TYPE=postgresdb \
-e DB_POSTGRESDB_DATABASE=<POSTGRES_DATABASE> \
-e DB_POSTGRESDB_HOST=<POSTGRES_HOST> \
-e DB_POSTGRESDB_PORT=<POSTGRES_PORT> \
-e DB_POSTGRESDB_USER=<POSTGRES_USER> \
-e DB_POSTGRESDB_SCHEMA=<POSTGRES_SCHEMA> \
-e DB_POSTGRESDB_PASSWORD=<POSTGRES_PASSWORD> \
-v n8n_data:/home/node/.n8n \
docker.n8n.io/n8nio/n8n
MySQL (indicazioni)
- Imposta:
DB_TYPE=mysqldbe le variabili corrispondenti per host, database, user, password, port (pattern:DB_MYSQLDB_*). - Assicurati che l’utente disponga dei permessi necessari e che la rete consenta la connessione (allowlist/VPC).
Note operative:
- Migrazioni schema: al primo avvio con DB esterno, n8n applica le migrazioni; monitora i log.
- SSL/TLS: abilita cifratura end‑to‑end; se usi certificati custom, assicurane la disponibilità nel container/host.
- Container: monta un volume persistente per la home n8n (
/home/node/.n8n) e per il DB. - Backup: programma dump periodici del DB e snapshot del volume n8n.
[IMG: Estratto di docker-compose con servizi n8n e Postgres collegati in rete privata]
Esempi pratici: import CSV/Sheets e sincronizzazione CRM → DB
Importare CSV o Google Sheets in un database con n8n
- Google Sheets → Code (normalize) → Split In Batches (100) → MySQL/PostgreSQL (Execute Query: INSERT/UPSERT) → Slack report.
- Normalizza email/phone, valida chiavi e applica upsert per idempotenza.
Snippet INSERT/UPSERT (MySQL ON DUPLICATE KEY)
INSERT INTO contacts (email, first_name, last_name, utm_source)
VALUES ({{ $json["email"] }}, {{ $json["first"] }}, {{ $json["last"] }}, {{ $json["utm"] }})
ON DUPLICATE KEY UPDATE
first_name = VALUES(first_name),
last_name = VALUES(last_name),
utm_source = VALUES(utm_source);
Sincronizzazione dati tra CRM e database
- CRM (HTTP Request/API) → Code (mapping) → DB upsert.
- Esegui poll su updated_at/lastModified per delta‑load.
- Scrivi una tabella “changeslog” con source, recordid, action, ts per audit.
Automazioni su eventi
- Webhook (nuovo ordine/lead) → Validate → DB upsert → Trigger downstream (email, Slack, BI refresh).
[IMG: Canvas con Google Sheets → Split In Batches → Postgres (executeQuery) → Slack]
Osservabilità, errori e ottimizzazione costi
Error handling
- IF su status/risultati query; su errori transitori, retry con backoff.
- Ramo errori → log su tabella
etl_errorscon stack/message e payload minimizzato.
Timeouts e performance
- Evita SELECT senza indice su grandi tabelle: aggiungi indici sulle chiavi di filtro/join.
- Keyset pagination batte LIMIT/OFFSET su dataset ampi.
Costi e governance
- Pianifica job in orari “soft” e raggruppa modifiche in batch per ridurre esecuzioni.
- Least privilege sugli utenti DB e rotazione periodica delle credenziali (gestione segreti centralizzata).
Monitoraggio
- Crea un report giornaliero: righe inserite/aggiornate, errori per job, durata media per batch.
- Alert se errori > soglia o se la durata supera il budget.
Quick Takeaways
- Usa i nodi “n8n-nodes-base.mySql” e “n8n-nodes-base.postgres” con credenziali dedicate e privilegi minimi.
- Costruisci query con espressioni n8n solo su input validati per prevenire SQL injection.
- Preferisci upsert per idempotenza: ON CONFLICT (PostgreSQL) e ON DUPLICATE KEY (MySQL).
- Scala con Split In Batches, keyset pagination e retry con backoff; limita la concorrenza per stabilità.
- Migra da SQLite a DB esterno in produzione: configura DB_TYPE e variabili d’ambiente, abilita SSL e backup.
- Traccia esiti, errori e tempi: osservabilità e audit ti fanno risparmiare tempo e costi.
Conclusione
Portare i tuoi workflow su PostgreSQL/MySQL con n8n significa passare da automazioni “artigianali” a processi affidabili e misurabili. Con mysql n8n e l’equivalente per Postgres puoi eseguire query dinamiche, fare upsert idempotenti e orchestrare pipeline ETL/ELT con batching e paginazione efficienti. L’adozione di buone pratiche – input validati, privilegi minimi, SSL/TLS, retry con backoff e job schedulati – riduce gli incidenti e rende i dati pronti per decisioni rapide. Per i marketer, è il ponte tra operatività e insight: liste pulite, segmenti coerenti, report accurati. Inizia con un piccolo flusso (Sheets → DB con upsert), misura performance e qualità, poi estendi a CRM e canali: la robustezza del tuo data layer sarà un moltiplicatore di produttività per tutte le campagne.
FAQ
1) Come collego n8n a MySQL o PostgreSQL in un workflow?
Crea le credenziali e usa i nodi dedicati (n8n-nodes-base.mySql o n8n-nodes-base.postgres). Imposta operation “executeQuery” e scrivi SQL con espressioni per passare parametri dinamici. Mantieni un utente DB con privilegi minimi.
2) Come prevenire SQL injection nelle automazioni?
Valida e normalizza gli input prima di usarli in query. Evita concatenazioni di stringhe non sanificate; usa espressioni n8n su campi controllati. Limita i permessi dell’utente DB e monitora errori anomali.
3) Posso fare upsert portabile tra PostgreSQL e MySQL?
Sì, via SQL: ON CONFLICT (PostgreSQL) e ON DUPLICATE KEY (MySQL). Esegui queste istruzioni con “executeQuery” e definisci chiavi/index unici sulle colonne di dedup.
4) Quando migrare n8n da SQLite a un DB esterno?
In produzione, con più utenti o job intensivi. Configura DB_TYPE (postgresdb o mysqldb) e le variabili d’ambiente del DB; abilita SSL/TLS e pianifica backup. Al primo avvio, n8n applica le migrazioni schema.
5) Come importare CSV o Google Sheets nel database?
Leggi dallo Sheet, normalizza in Code, usa Split In Batches e invia batch al nodo DB con INSERT/UPSERT. Aggiungi log e un report Slack per tenere traccia di righe inserite/aggiornate ed errori.
Ci dai una mano?
Qual è il primo flusso che porterai su DB: import da Sheets con upsert o sync dal CRM? Condividi la tua scelta e questo articolo con il team: confrontiamo pattern e costruiamo pipeline più affidabili per i prossimi lanci!
Scopri la consulenza →

