n8n vs Python: when to build a workflow and when to write code
The short answer: n8n when the work is a sequence of calls between systems that already exist and people on your team need to be able to read it. Python when the work is heavy on data, has to answer in milliseconds, or has logic complex enough that the canvas becomes harder to follow than code would be. Most real systems use both.
Last updated: August 27, 2026
The comparison
| n8n | Python | |
|---|---|---|
| Who can read it | Anyone on the team after a short session | Someone who writes code |
| Speed to build | Fast for connections between systems | Slower at the start |
| Data volume | Fine into the thousands of records per run | Comfortable with millions |
| Response time | Seconds | Milliseconds |
| Testing | Manual runs and execution history | Real automated tests |
| Version control | JSON export, workable and awkward | Entirely natural |
| Where it falls apart | Branching logic, nested loops | Simple connections that would take half an hour |
Where n8n wins
The overwhelming majority of business automation is a sequence of calls: take what arrived, check something, update a system, tell someone. For that, n8n is faster to build and, more importantly, it stays readable.
That readability is the real value rather than a convenience. You can open an n8n workflow a year after it was built and see what it does without reading code. An operations manager can change a threshold, some wording or a routing rule without us. When somebody asks why a particular customer got no email last Tuesday, the execution history is right there and searchable.
There is an ownership dimension too. n8n installs on your own server, with no per-task pricing and no data leaving your environment.
Where n8n stops
Volume. A workflow looping over ten thousand records will be slow and memory-hungry. Python does the same work in a fraction of the time.
Response time. If something has to answer in milliseconds, such as an endpoint your website calls while a user waits, this is not n8n's job.
Logical complexity. Once you have nested loops, exception handling at several levels, and state that has to be remembered across steps, the canvas becomes harder to follow than the equivalent code. That is the signal to move.
Testing. You can test an n8n workflow, and you cannot cover it with automated tests the way you cover code. For logic that costs money when it is wrong, that matters.
The pattern we actually build
Most of our systems are a combination: n8n orchestrating, Python doing the heavy parts. The workflow takes the trigger, gathers what it needs, calls a Python service for the processing, then carries on with the result to update systems and raise alerts.
The benefit is that the part your team needs to understand and change stays visible on the canvas, and the part that needs a developer sits behind one clear interface. Changing a threshold or a routing rule means nobody touches code.
Who maintains it in a year
This question decides more than any technical consideration. A system only its builder can operate stops working the day that person is busy.
If your team has no developer and no plan to hire one, anything that can be built in n8n is worth building in n8n, even where code would have been more elegant. If you have a development team already maintaining services, the logic runs the other way for the heavy parts.
FAQ
Can you write code inside n8n?
Yes, there is a Code node that runs JavaScript or Python. It is excellent for a short data transformation inside a workflow. It is not a substitute for a real service once the logic grows, because that code lives inside the workflow rather than in version control.
Which costs more?
Self-hosted n8n runs roughly $20 to $50 a month on a small server, with no per-task pricing. A Python service costs about the same in infrastructure and more in development time. The real difference is in people-hours rather than servers.
How do you keep n8n workflows in git?
You export them as JSON and commit that. It works and it is awkward, because JSON diffs are hard to read. On our projects the workflows are exported into the client's repository even though the editing happens in the interface.
When is n8n simply the wrong tool?
When the work is a product rather than a process. If you are building something users log into and work inside, that is an application rather than an automation, and we wrote about that separately.
Who holds the knowledge after the project ends?
Your team, and that is part of the price. Handover is a working session on the workflows we actually built, which lands better than a generic course.
Next step
We build both sides, and we say up front which part belongs where and why. If you are mid-decision, talk to us.
