Question 1

What do you watch for security-wise when working with a database in n8n?

Accepted Answer

The most concrete answer starts with SQL injection. "First, query parameters. In Execute Query I never build the query by concatenating an expression. I write $1, $2 tokens and pass the values through the Query Parameters field — n8n sanitises them and that prevents SQL injection. It matters especially because data reaching n8n usually comes from a webhook or a form, that is, from outside. Second, least privilege. If a workflow only reads, its credential should not have write access. Creating a dedicated user with access only to the tables needed is the better practice. Third, delete operations. The Delete node can drop a whole table. I either keep such operations out of n8n entirely or put them behind a human approval. Fourth, sensitive data landing in logs. The execution history stores every node's input and output. When personal or payment data is involved you have to look at the workflow settings to keep it out of the execution data."

Question 2

How would you build a reliable sync between two systems?

Accepted Answer

This sits on the middle/senior boundary. Show four elements. 1. A cursor. I do not write "the last hour" queries — I store the last processed ID or timestamp in a Data Table (or the database) and resume from it. Even after two hours of downtime it picks everything up. 2. Idempotency. I make the write an Insert or Update. If the same record arrives twice there is no duplicate — the same row is updated. Retries and re-runs are normal, and the system has to be ready for them. 3. Tolerating partial failure. If 5 of 500 records fail I do not want the whole execution to stop. I route the failures down a separate path, record them, and build a separate retry for them. 4. Reconciliation. This is the most-forgotten part. Once a day I run a separate workflow that compares the counts or a checksum on both sides and alerts on a mismatch. However well you build it, something can still go missing — and you need to know when it does."

Question 3

Where would you store a workflow's state — what has already been processed?

Accepted Answer

Compare the options and give the selection criterion. "There are four, each with its place. 1. In the source system itself — the best option. A label on the email, a processed column on the record, a status on the ticket. It needs no extra infrastructure and the state stays next to the data. 2. A Data Table — n8n's built-in tabular storage. Ideal for cursors, processed IDs and configuration without an external database. 3. An external database — when the volume is large or the state is needed by other systems too. 4. Google Sheets — works for simple cases and being human-readable is an advantage, but it becomes the bottleneck as volume and concurrent writes grow. My criterion: keep state as close to the data as possible. State kept somewhere separate eventually drifts out of sync with the primary data — a record is deleted from the database while n8n still considers it processed."

Operation	What it does	When
Select	Reads rows; conditions are built in the node UI	Simple reads without writing SQL
Insert	Adds new rows; columns can be mapped automatically or by hand	Writing new records
Insert or Update	An upsert — updates if it exists, otherwise inserts	The key operation: it makes the workflow idempotent
Execute Query	Runs raw SQL; supports parameter tokens like `$1`, `$2`	JOINs, grouping, complex reporting queries
Delete	Deletes rows, or an entire table	With care — it cannot be undone

Databases and Data Table

📚 Sources and documentation