Question 1

How is binary data stored in n8n and how do you work with it?

Accepted Answer

State the structure, then add the nodes and the constraint. "Binary data lives inside the item under the binary key, separate from json. One item can hold several binary properties, each under its own name. The file itself is base64-encoded, with metadata like mimeType, fileName and fileExtension alongside it. There are three main nodes: Extract From File pulls JSON out of a binary format, Convert to File goes the other way, and Read/Write Files from Disk works with the disk of the machine n8n runs on. Beyond those there are the HTML, XML, Compression and Edit Image nodes. In expressions I reach the metadata as $('Node').item.binary.data.fileName — data is the default name most nodes use, but I check the node output to be sure. The main constraint is memory: binary data travels inside the item, so large files need care."

Question 2

A CSV report arrives by email every day and must be written into a database. How do you build it?

Accepted Answer

This is a practical design question. Give the main flow, then the edge cases — the edge cases are what set the answer apart. "The main flow: Gmail Trigger → Extract From File (CSV) → Filter → Postgres. Extract From File turns each CSV row into its own item, and the next node runs over each item automatically. But in real life there are four edge cases, and I build for all of them: 1. No attachment — I filter the Gmail Trigger to the expected subject and sender, then use an IF to check the binary property exists. 2. The CSV structure changed — I check the expected columns are present; if not I alert and stop rather than writing partial data. 3. The same report arrives twice — I make the write an upsert so no duplicates appear. 4. The file is large — I batch with Loop Over Items so one execution does not hold the whole file in memory. Finally I log a per-run result to a channel: how many rows arrived, how many were written, how many were skipped. Silent failure is the worst outcome."

Question 3

What would you watch for in a self-hosted n8n handling large files?

Accepted Answer

This tests operational experience. Cover three directions. 1. Binary data storage mode. By default binary data travels in memory. On self-hosted you can switch it to filesystem storage with environment variables — for large files that is the key scaling knob. 2. Execution data retention. Binary data also lingers in the execution history. Without a retention policy the disk fills quickly. Keeping successful executions briefly and failed ones longer is the practical compromise. 3. How the flow is built. Rather than processing twenty large files in one execution, I batch with Loop Over Items or move the work into a sub-workflow — each call runs as its own execution, which relieves memory pressure. There is a security angle too: touching the disk means access to the machine n8n runs on. Where that capability is not needed, the relevant nodes can be disabled entirely with an environment variable."

Scenario	Node chain
Write a CSV attachment from an email into a sheet	Gmail Trigger → Extract From File (CSV) → Google Sheets
Send a report as an Excel file	Postgres → Convert to File (XLSX) → Gmail (attachment)
Extract data from a PDF invoice	Trigger → Extract From File (PDF) → AI (fill the fields) → accounting system
Scrape data from a web page	HTTP Request → HTML (Extract) → Edit Fields
Unpack an archive and process its contents	Trigger → Compression (Decompress) → Extract From File

Files and binary data

📚 Sources and documentation