Belajar n8n - Database & Storage Automation

#Pendahuluan

Di episode 9 kalian membuka sisi inbound otomasi: webhook-driven workflow yang menerima event eksternal, Respond to Webhook untuk mengekspos API dari workflow, serta webhook security dan payload validation. Sekarang kita beranjak ke salah satu komponen paling sering dipegang dalam produksi: penyimpanan data.

Episode ini membahas Database & Storage Automation. Kita praktik menghubungkan empat engine populer — PostgreSQL, MySQL, MongoDB, dan Redis — lalu memproses batch records dalam jumlah besar, menyinkronkan data ke sistem lain, dan menutup dengan pengelolaan binary data untuk upload dan download file. Di akhir episode, workflow kalian bisa membaca, menulis, dan memindahkan data antar sistem secara masif dan aman.

#Menghubungkan PostgreSQL & MySQL

PostgreSQL dan MySQL adalah raja database relasional di produksi. Node native n8n untuk keduanya mendukung operasi umum: insert, update, delete, dan execute query dengan parameter yang aman dari SQL injection.

Kredensialnya terpusat (mengingat episode 8): host, port, database, user, dan password disimpan sekali sebagai profil, lalu bisa dipakai di banyak node dan workflow. Contoh query untuk menarik customer premium:

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

Yang perlu diperhatikan: gunakan parameterized query dengan placeholder seperti ? alih-alih menempelkan nilai langsung ke string SQL. n8n mengisinya secara aman, mencegah serangan injeksi bila nilai berasal dari payload eksternal. Hasil query berubah menjadi item — satu baris satu item — sehingga langsung bisa diproses node berikutnya, misalnya dikirim ke API atau dibuatkan dokumen. Bila kalian butuh gabungan beberapa tabel, susun JOIN di query dan biarkan n8n mengonsumsi hasilnya sebagai item datar.

Untuk memulai, cara termudah adalah menjalankan query sederhana di tab Execute node, memeriksa hasilnya sebagai item, lalu menyusun transformasi di node berikutnya berdasarkan struktur nyata yang keluar. Membangun iteratif seperti ini jauh lebih cepat daripada menebak bentuk data dari dokumentasi.

#MongoDB & Redis

Untuk data non-relasional, n8n punya node native MongoDB dan Redis dengan pola yang sedikit berbeda.

• MongoDB — operasi berbasis dokumen: Find, Insert, Update, Aggregate, dan lainnya. Kredensialnya berupa connection string mongodb://. Karena dokumen MongoDB berbentuk JSON, integrasi dengan n8n terasa sangat natural — satu dokumen menjadi satu item.
• Redis — bekerja pada key-value: SET, GET, HSET, dan RPUSH. Cocok untuk caching, antrean job, dan state bersama. Contoh penggunaan: simpan hasil proses sebagai key dengan TTL, atau gunakan list sebagai buffer antrean yang dibaca workflow lain.

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

Pola yang berguna: tulis status sinkronisasi ke Redis supaya workflow lain bisa membacanya, atau simpan marker last_run untuk polling delta berikutnya. Dengan begitu beberapa workflow bisa berbagi state tanpa database besar.

Karena Redis menyimpan data di memori, ingatlah bahwa datanya bisa hilang saat instance di-restart tergantung konfigurasi persistence. Gunakan Redis untuk data yang memang bersifat sementara — cache, marker, antrean — dan jangan pernah menjadikannya satu-satunya penyimpanan untuk data yang wajib selamat. Untuk itu, tetap gunakan database persisten seperti PostgreSQL atau MongoDB sebagai sumber kebenaran utama.

#Memproses Batch Records

Saat data mencapai ribuan baris, memproses semuanya dalam satu eksekusi berisiko — API target bisa menolak karena rate limit, atau node database memori penuh. Di sinilah teknik SplitInBatches dari episode 6 kembali berperan, kali ini berpasangan dengan database.

Perhatikan juga urutan eksekusi antar batch: setiap batch diproses berurutan, sehingga kalian bisa melacak kemajuan sinkronisasi dari tab Executions — batch mana sukses, mana gagal, dan berapa sisa yang belum diproses. Transparansi semacam ini sangat berharga saat sinkronisasi berjalan lama.

Pola dasarnya: query database mengambil ribuan record → SplitInBatches memecahnya jadi potongan kecil → tiap batch dikirim ke API target → kembali ke SplitInBatches untuk batch berikutnya. Setiap batch yang gagal bisa ditangani dengan Continue on Fail dan dicatat ke tabel sync_failures untuk di-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)

Untuk database relasional, pertimbangkan juga pagination di query — misalnya LIMIT 1000 OFFSET 1000 — agar satu eksekusi query tidak membebani database. Kombinasi pagination di query dan batching di workflow adalah pola paling tahan banting untuk data besar.

Perhatikan juga bahwa tiap engine punya kekhasan operasi batch. PostgreSQL dan MySQL mendukung bulk insert dengan satu statement — misalnya menyisipkan ratusan baris dalam satu kali eksekusi — yang jauh lebih cepat daripada insert per item. MongoDB punya insertMany untuk dokumen banyak. Cek operasi yang tersedia di masing-masing node dan pilih yang berbasis batch, karena perbedaan performanya signifikan untuk data dalam jumlah besar.

#Sink Data ke Sistem Lain

Sinkronisasi biasanya tidak berhenti di database — data perlu dikirim ke sistem lain: API SaaS, spreadsheet, email, atau database lain. Workflow n8n unggul justru karena bisa merangkai ketiganya.

Contoh end-to-end: trigger cron setiap jam → query PostgreSQL untuk order baru sejak last_run → transformasi format dengan Set atau Function → POST ke API akuntansi via HTTP Request → update marker last_run di Redis → kirim ringkasan ke Slack bila ada record gagal. Seluruh pipeline ini satu workflow yang bisa diaudit dari tab Executions.

Dengan pola idempotent, kalian bisa dengan tenang me-replay batch yang gagal tanpa takut menggandakan data di sistem tujuan.

Satu catatan tentang pilihan engine untuk sinkronisasi: database relasional tetap pilihan terbaik untuk data yang harus di-query ulang dengan pola kompleks, sedangkan MongoDB unggul untuk dokumen yang skemanya sering berubah. Untuk operasi yang butuh latensi sangat rendah — semacam cache, rate limiter, atau antrean pekerjaan — Redis lebih cocok. Sering kali satu workflow memakai beberapa engine sekaligus: query dari PostgreSQL, tulis hasil antara ke Redis, dan simpan dokumen akhir di MongoDB. Tidak ada aturan baku; pilih engine berdasarkan cara data itu akan dibaca nanti.

#Binary Data: Upload & Download File

Tidak semua data berupa JSON — database juga menyimpan file, gambar, dan dokumen. Di n8n, data biner hidup di kunci binary pada tiap item (ingat episode 6). Ada dua arah penggunaan yang umum:

• Download — node HTTP Request dengan mode response File akan menghasilkan item berisi data biner, siap disimpan ke penyimpanan file atau diunggah ke sistem lain.
• Upload — item yang punya data biner bisa dikirim ke penyimpanan objek, disisipkan ke database blob, atau diunggah ke layanan seperti Slack dan Google Drive.

Kedua arah ini saling melengkapi dan sering dipakai berurutan dalam satu workflow: unduh dari sumber, proses, lalu unggah ke tujuan. Perhatikan batas ukuran — database blob dan beberapa API punya limit tertentu, jadi untuk file besar lebih baik alirkan lewat penyimpanan objek daripada menyimpannya di dalam database.

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

Contoh nyata: cron setiap pagi mengambil laporan dari database, mengonversinya menjadi file CSV atau PDF, lalu mengunggahnya ke Google Drive dan mengirim link ke Slack. Binary data menghubungkan dunia data terstruktur dengan dunia file nyata — dan menjadi jembatan menuju episode 11.

Sebagai penyegaran untuk pola ini: ketika node HTTP Request diatur dengan response type File, hasilnya otomatis menjadi item dengan data biner. Dari sana kalian bisa meneruskannya ke node S3, Google Drive, atau Send Email dengan lampiran. Sebaliknya, saat workflow harus mengirim file ke API, pastikan nama file dan mime type terisi dengan benar di metadata binary — banyak API menolak upload yang metadata-nya tidak lengkap. Periksa tab output node untuk melihat field fileName dan mimeType sebelum menyambung ke node tujuan.

#Penutup

Episode 10 membekali kalian automasi penyimpanan yang lengkap: koneksi ke PostgreSQL, MySQL, MongoDB, dan Redis dengan kredensial terpusat; pemrosesan batch records dengan SplitInBatches dan pagination; sinkronisasi data antar sistem yang idempotent; serta pengelolaan binary data untuk upload dan download file langsung dari workflow.

Inti yang harus dibawa pulang:

• Gunakan parameterized query untuk mencegah SQL injection dari payload eksternal.
• Pilih engine sesuai data: relasional untuk struktur, MongoDB untuk dokumen JSON, Redis untuk key-value dan antrean.
• Batch records dengan SplitInBatches plus pagination untuk data besar yang tahan rate limit.
• Jadikan sinkronisasi idempotent agar replay batch tidak menggandakan data.
• Binary data membuka jalur file: download dari API, unggah ke penyimpanan, kirim ke Slack.

Di episode 11 berikutnya kita lanjut ke dunia file: working with files, documents & media — automasi file dengan S3, Google Drive, dan FTP, memanipulasi dokumen, gambar, dan CSV, serta menggabungkan data pipeline dengan transformasi file. Sampai jumpa!