Learn n8n - Database & Storage Automation

#Introduction

In episode 9 you opened the inbound side of automation: webhook-driven workflows that receive external events, Respond to Webhook to expose APIs from workflows, as well as webhook security and payload validation. Now we move to one of the components most often touched in production: data storage.

This episode covers Database & Storage Automation. We'll practice connecting four popular engines — PostgreSQL, MySQL, MongoDB, and Redis — then process large numbers of batch records, sync data to other systems, and close with binary data management for uploading and downloading files. By the end of this episode, your workflows can read, write, and move data between systems massively and securely.

#Connecting PostgreSQL & MySQL

PostgreSQL and MySQL are the kings of relational databases in production. n8n's native nodes for both support common operations: insert, update, delete, and execute query with parameters safe from SQL injection.

The credentials are centralized (remembering episode 8): host, port, database, user, and password are saved once as a profile, then usable across many nodes and workflows. Example query to pull premium customers:

SELECT id, name, email
FROM customers
WHERE is_premium = true
  AND signup_date >= '2026-01-01'
ORDER BY signup_date DESC
LIMIT 100;

What you should note: use parameterized queries with placeholders like ? instead of pasting values directly into SQL strings. n8n fills them safely, preventing injection attacks when values come from external payloads. Query results become items — one row one item — so they can be processed directly by the next node, for example sent to an API or turned into documents. If you need to combine several tables, build the JOIN in the query and let n8n consume the results as flat items.

To get started, the easiest way is to run a simple query in the node's Execute tab, inspect the results as items, then build the transformation in the next node based on the actual structure that comes out. Building iteratively like this is far faster than guessing the data shape from documentation.

#MongoDB & Redis

For non-relational data, n8n has native MongoDB and Redis nodes with slightly different patterns.

• MongoDB — document-based operations: Find, Insert, Update, Aggregate, and others. The credentials are a mongodb:// connection string. Since MongoDB documents are JSON, integration with n8n feels very natural — one document becomes one item.
• Redis — works on key-value: SET, GET, HSET, and RPUSH. Great for caching, job queues, and shared state. Example usage: store process results as a key with a TTL, or use a list as a queue buffer read by another workflow.

SET last_sync_at 2026-08-03T10:15:00Z EX 3600
RPUSH sync_failures order-123

A useful pattern: write sync status to Redis so other workflows can read it, or store a last_run marker for the next delta poll. That way several workflows can share state without a large database.

Since Redis stores data in memory, remember that data can be lost when the instance restarts depending on the persistence configuration. Use Redis for data that's genuinely temporary — caches, markers, queues — and never make it the only storage for data that must survive. For that, keep a persistent database like PostgreSQL or MongoDB as the source of truth.

#Processing Batch Records

When data reaches thousands of rows, processing everything in one execution is risky — the target API might refuse due to rate limits, or the database node runs out of memory. This is where the SplitInBatches technique from episode 6 returns to the stage, this time paired with databases.

Also note the execution order between batches: each batch is processed sequentially, so you can track sync progress from the Executions tab — which batches succeeded, which failed, and how much remains unprocessed. Transparency like this is very valuable during long-running syncs.

The basic pattern: a database query fetches thousands of records → SplitInBatches splits them into small chunks → each batch is sent to the target API → return to SplitInBatches for the next batch. Any failed batch can be handled with Continue on Fail and recorded to a sync_failures table for replay.

Batch ke-1: record 1-50    -> API target (200 OK)
Batch ke-2: record 51-100  -> API target (200 OK)
...
Batch ke-100: record 4.951-5.000 -> API target (200 OK)

For relational databases, also consider pagination in the query — for example LIMIT 1000 OFFSET 1000 — so a single query execution doesn't strain the database. Combining query pagination and workflow batching is the most robust pattern for large data.

Also note that each engine has its own batch operation quirks. PostgreSQL and MySQL support bulk inserts with a single statement — for example inserting hundreds of rows in one execution — which is far faster than per-item inserts. MongoDB has insertMany for many documents. Check the operations available on each node and choose batch-based ones, because the performance difference is significant for large volumes of data.

#Syncing Data to Other Systems

Synchronization usually doesn't stop at the database — data needs to be sent to other systems: SaaS APIs, spreadsheets, email, or other databases. n8n workflows excel precisely because they can chain all of these together.

An end-to-end example: a cron trigger every hour → query PostgreSQL for new orders since last_run → transform the format with Set or Function → POST to an accounting API via HTTP Request → update the last_run marker in Redis → send a summary to Slack if any records failed. This entire pipeline is one workflow auditable from the Executions tab.

With the idempotent pattern, you can calmly replay failed batches without fear of duplicating data at the target system.

One note on choosing engines for synchronization: relational databases remain the best choice for data that must be re-queried with complex patterns, while MongoDB excels for documents whose schema changes often. For operations requiring very low latency — like caches, rate limiters, or job queues — Redis is more suitable. Often a single workflow uses several engines at once: query from PostgreSQL, write intermediate results to Redis, and store final documents in MongoDB. There's no fixed rule; choose the engine based on how the data will be read later.

#Binary Data: Upload & Download Files

Not all data is JSON — databases also store files, images, and documents. In n8n, binary data lives in the binary key on each item (remember episode 6). There are two common directions of use:

• Download — an HTTP Request node with the File response mode produces an item containing binary data, ready to be stored in file storage or uploaded to another system.
• Upload — an item with binary data can be sent to object storage, inserted into a database blob, or uploaded to services like Slack and Google Drive.

These two directions complement each other and are often used in sequence within one workflow: download from a source, process, then upload to a destination. Watch size limits — database blobs and some APIs have certain limits, so for large files it's better to stream through object storage than to store them inside the database.

{
  "json": { "name": "laporan-q3.pdf", "mime": "application/pdf" },
  "binary": { "data": { "fileName": "laporan-q3.pdf", "data": "<base64>" } }
}

A real example: a morning cron fetches a report from the database, converts it into a CSV or PDF file, then uploads it to Google Drive and sends the link to Slack. Binary data connects the world of structured data with the world of real files — and becomes a bridge to episode 11.

As a refresher for this pattern: when an HTTP Request node is configured with the File response type, the result automatically becomes an item with binary data. From there you can forward it to an S3, Google Drive, or Send Email node with attachments. Conversely, when a workflow must send a file to an API, make sure the file name and mime type are correctly filled in the binary metadata — many APIs reject uploads with incomplete metadata. Check the node's output tab to see the fileName and mimeType fields before connecting to the destination node.

#Closing

Episode 10 equipped you with complete storage automation: connections to PostgreSQL, MySQL, MongoDB, and Redis with centralized credentials; batch record processing with SplitInBatches and pagination; idempotent data synchronization between systems; and binary data management for uploading and downloading files directly from workflows.

Key takeaways:

• Use parameterized queries to prevent SQL injection from external payloads.
• Choose the engine by data: relational for structure, MongoDB for JSON documents, Redis for key-value and queues.
• Batch records with SplitInBatches plus pagination for rate-limit-friendly large data.
• Make synchronization idempotent so batch replays don't duplicate data.
• Binary data opens the file path: download from APIs, upload to storage, send to Slack.

In the next episode we continue into the file world: working with files, documents & media — file automation with S3, Google Drive, and FTP, manipulating documents, images, and CSV, as well as combining data pipelines with file transformations. See you there!