Průvodce
Databázové triggery: PostgreSQL/MySQL → n8n workflow bez vlastního kódu
Data z PostgreSQL a MySQL dostaneš do n8n bez jediného řádku vlastního kódu: push přes Postgres Trigger, pro MySQL chytřejší polling, idempotence přes Remove Duplicates a dedikovaný read-only účet. Postupy, práva a limity ověřeny 30. 9. 2026.
⏱️
Čas
3–4 hodiny nastavení + 10 minut týdně
📊
Obtížnost
Pokročilý
💰
Úspora
Odhad pro ilustrativní scénář: hodiny ad-hoc skriptování a ranních kontrol přejdou na automatizaci; provoz stojí 0 Kč (n8n Community self-hosted) nebo 20 €/měsíc při roční platbě (Cloud Starter, 2 500 executionů) — cena ověřena 30. 9. 2026.
🎯
Kroků
7
🛠️ Co budete potřebovat
Nástroje
- • n8n — Community Edition self-hosted zdarma, nebo Cloud Starter za 20 €/měsíc při roční platbě (2 500 executionů), Pro za 50 €/měsíc (10 000 executionů); ověřeno 30. 9. 2026 na n8n.io/pricing
- • PostgreSQL — pro push (node Postgres Trigger) účet s TRIGGER privilegiem na sledované tabulce a CREATE na schématu (dokumentace n8n, 30. 9. 2026); funguje i na managed hostinzích, které povolují vlastní procedury
- • MySQL 8.x nebo MariaDB — pro node MySQL stačí read-only přístup (SELECT); node dále umí Insert, Update, Insert or Update, Delete a Execute SQL
- • Vestavěné nody n8n: Schedule Trigger, Remove Duplicates (přestavěný ve verzi 1.64.0), Edit Fields (Set), IF — žádné doplňky instalovat nemusíš
Dovednosti
- • Orientace v n8n editoru: přidat node, vytvořit credential, spustit workflow a číst Executions — základy popisuje [průvodce N8N automatizací krok za krokem](/content/n8n-automatizace-pruvodce-krok-za-krokem)
- • Základní SQL: SELECT s WHERE a ORDER BY, CREATE USER/ROLE a GRANT — ukázkové příkazy jsou v návodu, stačí vědět, kde je spustit (psql, mysql klient)
- • Přístup do databáze s právem vytvořit účet (admin/vlastník tabulky); veřejnou IP ani přijímání webhooků nepotřebuješ, celý návod jede zevnitř sítě
V kostce
- PostgreSQL umí v n8n skutečný push: node Postgres Trigger si při publikování workflow sám vytvoří na tabulce trigger a proceduru a posílá události INSERT/UPDATE/DELETE. Trigger node pro MySQL neexistuje — tam je cesta Schedule Trigger + pravidelný SELECT (polling).
- Read-only účet stačí jen na polling. Push vyžaduje TRIGGER právo na tabulce a CREATE na schématu — přiděluj je úzce na jednu tabulku a vyčleněné schéma, nebo u pollingu se čistým read-only zůstaň, když to policy nedovolí.
- Idempotenci postav na dvou pojistkách: kurzor (id > poslední zpracované) posunovaný až po úspěšných akcích a node Remove Duplicates s klíčem podle primárního klíče — chrání tě překryv oken, retry i ruční re-run.
- Hlídej smyčky a limity: zápis zpět do sledované tabulky u push triggeru vyvolá další událost (smyčka), takže zapisuj do vedlejší tabulky; a minutový polling spotřebuje ~43 200 executionů měsíčně, což přeteče tarif Starter (2 500).
Krok za krokem
Rozhodni mezi pushem a pollingem (a proč MySQL musí čekat)
- U PostgreSQL má n8n skutečný push: node Postgres Trigger naslouchá událostem INSERT, UPDATE a DELETE přímo v databázi. Při publikování workflow si n8n na cílové tabulce sám vytvoří trigger a proceduru, která ho o událostech informuje (dokumentace n8n, 30. 9. 2026).
- Trigger node pro MySQL v n8n neexistuje. MySQL node umí jen operace Delete, Execute SQL, Insert, Insert or Update, Select a Update — události tedy řešíš pollingem: Schedule Trigger v pravidelném intervalu + MySQL node s dotazem na nové řádky.
- Rozhodovací pravidlo: potřebuješ reagovat v řádu sekund (rezervace, podezřelé platby, kritické chyby) → push na PostgreSQL. Stačí minuty (synchronizace do CRM, notifikace, reporty) → polling, klidně i na PostgreSQL, pokud nechceš dát n8n právo vytvářet triggery.
- Zmapuj si sledovanou tabulku: má monotónně rostoucí primární klíč (id BIGINT AUTO_INCREMENT)? Má sloupce created_at a updated_at? Obojí ovlivní kurzor, který postavíš v krocích 4 a 5.
- Odhadni objem: kolik řádků přibyde denně a kolik z nich skutečně potřebuje spustit akci. U pushu platí, že každá událost = jedna execution n8n.
Tip
- Polling na PostgreSQL je legitimní volba, když firemní policy zakazuje cizí triggery v produkční databázi — read-only účet je bezpečnější default.
- Interval 1–5 minut je pro většinu interních procesů (notifikace, sync) úplně dostatečný; pod sekundu lidé stejně nezvládnou zareagovat.
- Než se rozhodneš, zkus si před týden pohrát s oběma variantami na kopii tabulky — rozdíl pocítíš hlavně při ladění.
Pozor
- Push na vytížené tabulce generuje tolik executionů, kolik je zápisů: hromadný UPDATE pole u 100 000 řádků = 100 000 událostí. Tarif n8n Cloud Starter má 2 500 executionů měsíčně — minutový polling naopak spotřebuje ~43 200. Počítej s limitem už teď.
Očekávaný výsledek
Máš písemně: databázi (PostgreSQL/MySQL), tabulku, sledované události (INSERT/UPDATE/DELETE), požadovanou latenci a práva, která smíš přidělit. Podle toho jdeš do kroku 3 (push) nebo 4 (polling).
Vytvoř dedikovaný databázový účet s minimálními právy
- Nikdy nepřipojuj n8n pod superuživatelem ani pod účtem, kterým běží aplikace. Vytvoř účet výhradně pro n8n, ať se v auditu databáze pozná, kdo co dělal.
- Pro polling stačí read-only. PostgreSQL: CREATE ROLE n8n_reader LOGIN PASSWORD '…'; GRANT USAGE ON SCHEMA public TO n8n_reader; GRANT SELECT ON objednavky TO n8n_reader;. MySQL: CREATE USER 'n8n_reader'@'10.0.0.5' IDENTIFIED BY '…'; GRANT SELECT ON shop.objednavky TO 'n8n_reader'@'10.0.0.5';
- Omez účet po síti. V MySQL přímo v definici uživatele (host 'n8n_reader'@'IP-n8n-serveru'), v PostgreSQL řádkem v pg_hba.conf pro CIDR adresu n8n serveru. Vynuť šifrování: MySQL klauzulí REQUIRE SSL, PostgreSQL parametrem sslmode=require v connection stringu (n8n credential to má v nastavení).
- Push na PostgreSQL se čistě read-only účtem nepostavíš: n8n si musí na tabulce vytvořit trigger a uložit proceduru. Dokumentace n8n výslovně uvádí, že účet potřebuje superuser přístup, vlastnictví tabulky nebo TRIGGER privilegium — plus CREATE privilegium na schématu, kde procedura vznikne. Přidělej to úzce: GRANT TRIGGER ON TABLE objednavky TO n8n_push; GRANT USAGE, CREATE ON SCHEMA n8n_app TO n8n_push;.
- Když databázová policy cizí triggery zakazuje, zůstaň u pollingu z kroku 4 s read-only účtem. Je to pomalejší, ale bezpečnější default.
Tip
- Hesla generuj (openssl rand -base64 24) a naplánuj si čtvrtletní rotaci rovnou do kalendáře.
- Účty pojmenovávej podle účelu (n8n_poll_shop, n8n_push_events) — při incidentu okamžitě víš, který konec automatu komunikoval s databází.
- I když potřebuješ číst i zapisovat, dělej to dvěma účty: read-only na zdrojovou tabulku, druhý účet na zápis do vedlejší tabulky.
Pozor
- Read-only účet s GRANT SELECT na celé schéma čte všechny sloupce včetně hesel a tokenů. V dotazech v kroku 4 vybírej jen konkrétní sloupce, které workflow opravdu potřebuje.
- TRIGGER + CREATE na schématu je víc než čtení: n8n s tímto účtem může instalovat kód do databáze. Vyčleň pro proceduru samostatné schéma a práva nedávej na celou databázi.
Očekávaný výsledek
Účet je připojený v n8n credentials, vidí jen cílovou tabulku, spojení jede přes SSL a je omezené na IP n8n serveru. Test: pod novým účtem spusť SELECT (projde) a INSERT (musí selhat s chybou oprávnění).
PostgreSQL: napoj Postgres Trigger na INSERT, UPDATE a DELETE
- V n8n přidej jako první node Postgres Trigger a připoj credential z kroku 2 (účet s TRIGGER a CREATE právy).
- V parametru Listen zvol Create Trigger Rule a zaškrtni události: Insert, Update, Delete — libovolnou kombinaci podle toho, na co má workflow reagovat.
- Vyber schéma a tabulku. Až workflow publikuješ (Activate), n8n na tabulce automaticky vytvoří trigger; po deaktivaci ho zas smaže. Při testování v editoru se trigger vytvoří taky a po skončení testu se odstraní — o nic se nemusíš starat ručně.
- Trigger volá automaticky vytvořenou proceduru, která n8n předá událost. Do dalších nodů dostaneš JSON s daty řádku a typem události — můžeš rovnou větvit přes IF node (nová objednávka vs. změna stavu).
- Druhá možnost v parametru Listen je Listen to Channel: pokud už aplikace posílá pg_notify('zmeny', …) do vlastního kanálu, n8n na něj jen naslouchá a nic do databáze neinstaluje. To je nejčistší varianta, když si o změnách notifikuje sama aplikace.
- Za Postgres Trigger připoj hned node Remove Duplicates z kroku 5 — UPDATE jednoho řádku může v krátkém sledu přijít víckrát.
Tip
- Pro proceduru n8n vyčleň samostatné schéma (třeba n8n_app). Po roce snadno ověříš, co tam n8n má, a práva jsou úzká.
- Stav triggeru si ověříš dotazem SELECT tgname FROM pg_trigger WHERE tgrelid = 'objednavky'::regclass; — použiješ ho v kroku 7 po každé aktivaci.
- Listen to Channel funguje i pro události, které do databáze píše aplikace sama — n8n pak není vlastníkem triggeru a nemůže ho nechtěně smazat.
Pozor
- Na managed PostgreSQL hostinzích bývají omezené práva na vytváření procedur. Než se do pushu pustíš, ověř si, že tvůj hosting TRIGGER a CREATE na schématu vůbec dovolí.
- Migrace, které dropnou a znovu vytvoří tabulku (DROP TABLE … CASCADE), smažou i n8n trigger. Workflow pak tiše přestane sbírat data — hlídá to watchdog z kroku 7.
Očekávaný výsledek
Publikované workflow, které na každý INSERT do sledované tabulky spustí execution s daty řádku. V pg_trigger vidíš n8n trigger a po deaktivaci workflow zmizí.
MySQL: postav polling přes Schedule Trigger a MySQL node
- První node je Schedule Trigger. Interval zvol podle latence z kroku 1 (typicky každé 1–5 minut). Každé spuštění = jedna execution, takže počítej s limitem tarifu.
- Přidej MySQL node s operací Select — nebo Execute SQL, pokud chceš kurzor dotáhnout dotazem (níže). Dotaz vždy řaď aomez kurzorem: SELECT id, email, stav FROM objednavky WHERE id > :last_id ORDER BY id ASC LIMIT 200.
- Hodnoty do dotazu nikdy nevkládej slepováním textu. Použij pole Query Parameters v Options node a na hodnoty se odvoluj výrazem — n8n hodnoty sanitizuje a chrání tě proti SQL injection (dokumentace n8n to uvádí explicitně).
- Kurzor :last_id ulož bez kódu do databáze samotné: vedle sledované tabulky si vytvoř tabulku sync_state (klic VARCHAR PRIMARY KEY, hodnota BIGINT). První node Execute SQL hodnotu načte, MySQL node vytáhne nové řádky a poslední node Execute SQL ji posune na největší zpracované id.
- Pokud sleduješ i změny (UPDATE), přidej do dotazu podmínku na updated_at: WHERE id > :last_id OR updated_at > :last_ts. Kurzor pak drží dvě hodnoty a musíš ho posouvat po úspěšném dokončení akcí, ne před nimi.
- Dotaz píš jen na sloupce, které workflow skutečně potřebuje — read-only účet z kroku 2 jinak tahá data, která nikam nepatří.
Tip
- LIMIT 200 chrání workflow proti nárazovému backlogu po hromadném importu — data se zpracovávají po dávkách v každém intervalu, místo aby jeden běh dostal 50 000 řádků.
- Pro noční plnou kontrolu souhlasu (rekonciliace) si postav druhý workflow s ručním spuštěním, ať nemícháš inkrementální běh s full scanem.
- Časy v dotazech vede v UTC a v n8n si nastav Timezone na Europe/Prague — ušetříš si hodiny ladění přestupných měsíců.
Pozor
- Časový kurzor (created_at) selže při zpětných zápisech a špatných časových zónách — pokud tabulka má monotónní id, preferuj id jako kurzor.
- Polling nevidí mizející řádky: DELETE se nedozvíš. Pokud potřebuješ reagovat na smazání, přidej soft-delete sloupec (smazano_kdy) nebo denní full compare.
Očekávaný výsledek
Workflow, které každých X minut vytáhne jen řádky od posledního běhu. Ruční opakované spuštění nevrací už zpracované řádky a sync_state se posouvá dopředu.
Zajisti idempotenci: Remove Duplicates a důsledný kurzor
- Duplicity vzniknou snadno: překryv intervalů pollingu, ruční re-run execution, retry po chybě uprostřed běhu, nebo update jednoho řádku třikrát za sekundu. Cíl: jeden řádek = jedna akce, i když se událost doručí víckrát.
- Za trigger (nebo za MySQL Select) dej node Remove Duplicates. Zvol operaci Remove Items Processed in Previous Executions a jako klíč pro porovnávání nastav primární klíč řádku, u push triggeru kombinaci id + typ události. Node si zpracované položky pamatuje ve statických datech workflow a při dalších bězích je vyřadí.
- Pro duplicity v jednom běhu (dávka 200 řádků obsahuje stejný řádek dvakrát) přidej druhý Remove Duplicates s operací Remove Items Repeated Within Current Input.
- Node prošel ve verzi n8n 1.64.0 velkou přestavbou — na starší self-hosted instanci se parametry můžou jmenovat jinak. Po upgradu vymaž paměť operací Clear Deduplication History, ať historie nezastará.
- Nejsilnější pojistka je kurzor bez překryvu: sync_state posouvej až po úspěšném dokončení akcí. Když execution spadne, další běh řádky vytáhne znovu — a Remove Duplicates je odchytí jako už zpracované.
Tip
- Dedupe klíč si ulož do n8n Variables a používej ho napříč workflowy — při změně schématu upravíš jedno místo.
- U akcí s vedlejšími účinky (e-mail, faktura, notifikace zákazníkovi) přidej druhou pojistku: do cílového systému zapisuj s external id (id řádku z databáze) a cílový systém nech duplicity odmítnout.
- Deduplikační historie ve statických datech není nekonečná — pro dlouhé okno mezi retry proto nespoléhej jen na node, ale hlavně na kurzor.
Pozor
- Statická data workflow se nepřestěhovávají s exportem: importuješ-li workflow do jiné instance n8n, dedupe historie je prázdná. První běh po migraci zkontroluj ručně.
- Klíč bez typu události u push triggeru spolkne opravu: UPDATE po INSERTU se neprovede, protože „tenhle řádek už byl“. Kombinuj id s akcí.
Očekávaný výsledek
Test: stejnou položku pošli workflow dvakrát (dvojí insert nebo ruční re-run) — akce se provede jen jednou. V Executions vidíš druhý běh s prázdným výstupem Remove Duplicates.
Doprovoď data do akcí a ošetři chyby
- Za deduplikaci přidej akce: notifikace do Slacku nebo Teams, zápis do CRM přes HTTP node, e-mail přes SMTP node. U nodů s vlastními retry nastav v nastavení node Retry On Fail (3 pokusy, čekání alespoň 5 s) — síťový výpadek cíle pak nerozbije celý běh.
- Postav error workflow: v nastavení hlavního workflow připoj samostatný error workflow, který pošle notifikaci (Slack/e-mail). Při pádu se to dozvíš ty, ne uživatel, kterého data neprošla.
- Přidej pojistku proti tichému zmrznutí: malé denní workflow, které se podívá do sync_state (polling) nebo na poslední execution triggeru (push) a když je poslední běh starší než X hodin, pošle alert. Tohle je jediný spolehlivý signál, že automatizace přestala sbírat data.
- Zápis stavu „zpracováno“ dělej do vedlejší tabulky (processing_log) přes Postgres/MySQL node s operací Insert or Update — nikdy neupdatuj tabulku, kterou sleduješ. U push triggeru by update sledované tabulky vygeneroval novou událost Update a workflow se chytilo do smyčky.
- Osobní údaje před odesláním do externích služeb očisti: node Edit Fields (Set) sloupce vynechá, přejmenuje nebo přemapuje dřív, než data opustí tvůj server. U e-mailů do Slacku většinou stačí id a lidsky čitelný popis, ne celý řádek z databáze.
Tip
- Workflow pojmenuj podle zdroje a cíle (shop.objednavky → slack), ať se v seznamu neztratí. Experimenty dělej na kopii workflow, originál nech běžet.
- Error workflow připoj i k watchdogu z bodu 3 — jinak zjistíš, že databáze mlčí, až když si stěžuje uživatel.
- Do processing_log zapisuj i výsledek akcí (odesláno / chyba), ať máš stopu pro ladění bez pohledu do Executions.
Pozor
- Smyčka událostí je nejčastější vážná chyba u push triggerů: zápis do sledované tabulky → nová událost → zápis → dokola. Zapisuj výhradně do jiných tabulek nebo přes jiný účet a události od něj filtruj.
Očekávaný výsledek
Kompletní workflow: zdroj → Remove Duplicates → akce → zápis stavu do processing_log. Error workflow je připojený a watchdog na sync_state běží jednou denně.
Otestuj, publikuj a monitoruj
- Test v editoru: u Postgres Triggeru spusti testovací naslouchání (trigger se dočasně nainstaluje), vlož do tabulky testovací řádek a sleduj, jak execution přijde s daty. U pollingu workflow spusť ručně a zkontroluj, že kurzor odfiltruje staré řádky.
- První dny jeď v dry-run režimu: akce směřuj do testovacího kanálu nebo tabulky. Až vidíš pár dní reálných běhů, přepni cíle na produkční.
- Workflow aktivuj (Activate). U PostgreSQL si v databázi ověř, že trigger vznikl (SELECT tgname FROM pg_trigger …), u MySQL že se sync_state posouvá s každým během.
- Sleduj Executions: první týden denně s filtrem na chyby, pak stačí týdně. U cloudových tarifů hlídej spotřebu executionů (Starter 2 500 měsíčně) — minutový polling ji spotřebuje sám (~43 200).
- Zdokumentuj pro tým, co kde žije: jaký účet n8n používá, co instaloval do databáze (trigger + procedura v jakém schématu), kde se ukládá kurzor a co se stane po deaktivaci workflow. Napiš to do vlákna u workflow v n8n (poznámka) i do interní dokumentace.
Tip
- Workflow si exportuj jako JSON a ulož do repozitáře — obnova po havárii instance pak trvá minuty.
- Nejvíc chyb přichází po změnách schématu: po každém ALTER TABLE na sledované tabulce prober workflow ručně, i když testy prošly.
Pozor
- Deaktivace workflow smaže DB trigger a polling se zastaví — data se mezitím hromadí. Po opětovné aktivaci dotáhne kurzor backlog najednou; LIMIT z kroku 4 ho rozloží do dávek, ale akce můžou chvíli běžet ve vlnách.
Očekávaný výsledek
Aktivní workflow v produkci, pár dní úspěšných běhů v Executions, ověřený trigger/kurzor v databázi a tým, který ví, co n8n v databázi instaluje a proč.
Výsledky implementace
❌ Před implementací
- • Ilustrativní scénář: aplikace zapisuje události do tabulky a o změnách se nikdo nedozví, dokud si admin ráno nespustí export nebo neprohlédne dashboard. Notifikace řeší ad-hoc skripty jednoho člověka, které po jeho odchodu z firmy nikdo neudržuje, a superuživatelské přístupy do produkční databáze kolují v konfiguračních souborech.
✅ Po implementaci
- • Událost z tabulky se do n8n dostane během sekund (PostgreSQL push) nebo minut (polling) a pokračuje do Slacku, CRM nebo e-mailu — bez jediného řádku vlastního kódu, s deduplikací proti dvojitým akcím a dedikovaným účtem, který v nejhorším případě čte jednu tabulku.
Odhad pro ilustrativní scénář: hodiny ad-hoc skriptování a ranních kontrol přejdou na automatizaci; provoz stojí 0 Kč (n8n Community self-hosted) nebo 20 €/měsíc při roční platbě (Cloud Starter, 2 500 executionů) — cena ověřena 30. 9. 2026.
Měsíční úspora
Investice: odpoledne nastavení + hodina ladění kurzoru a deduplikace. Návratnost: notifikace a synchronizace běží samo, přístup do databáze je auditovatelný a tady po tobě zůstane dokumentovaný systém místo skriptů v osobním repozitáři.
Návratnost