n8n-wms: can a workflow tool run a warehouse?
Company: Personal project (feasibility study)
Duration: 2026
Tools & Technologies: n8n, PostgreSQL (plpgsql), JavaScript, Docker Compose, GitHub Actions
Repository: github.com/remkostas/n8n-wms
n8n-wms: can a workflow tool run a warehouse?
Company: Personal project (feasibility study)
Duration: 2026
Tools & Technologies: n8n, PostgreSQL (plpgsql), JavaScript, Docker Compose, GitHub Actions
Repository: github.com/remkostas/n8n-wms
Context
A feasibility study, never meant to be a finished product. The question: can n8n as the workflow engine and PostgreSQL as the only system of record run the core of a warehouse management system for a small warehouse, with handheld scanners on the floor? The interface is deliberately minimal. The point was the logic, the data and the load, not the screens.
Key Result
Technically, yes. Receiving, picking with short picks, stock lookup, badge sign-in, and sessions that survive a reload or a device switch mid-task. Ten operators receiving the same article at once, 400 receipts in total, leave the ledger and stock in exact agreement.
Tools
n8n · PostgreSQL · plpgsql · JavaScript · Docker · CI
Small warehouses often run on spreadsheets because a full WMS is too heavy and too expensive. A workflow tool like n8n promises something in between: logic you can see and change without a development team.
I wanted to know if that promise holds once real stock movements are involved, so I built the smallest version that could answer it.
Every stock movement is one database call. n8n can't hold a transaction across nodes, and every movement is at least two writes that must never disagree. So each mutation is a single plpgsql function, and n8n only routes requests and renders screens.
State lives in the database. Each scan is POST, redirect, GET. The operator's progress sits in a session table, so a task continues on another device.
Tested like production. 51 unit tests, an 84-check acceptance walkthrough against the database, and a contention benchmark, all in CI on every push.
The logic didn't stay on the canvas. More than half the code ended up in SQL.
Passing tests aren't working software. The tests passed while the app was unusable in a browser: n8n serves webhook pages in a sandbox that drops cookies on form posts. I documented the cause and the fix.
The first benchmark flattered it. Early probes suggested room for about 85 operators. The finished terminal handles roughly 25 to 35 before response times get long.
Feasible for a small warehouse, but not worth turning into a product. n8n's licence rules out shipping it, a free open-source ERP already covers the space, and "customisable without developers" fell apart once the logic moved into SQL.
It shows how I test an idea before anyone invests in it: build the smallest version that answers the question, measure it honestly, and say no when the numbers say no.