We ran the same 10 production workflows in both n8n and Make for 30 days. Not demos — real automations moving real leads, invoices, and content between the tools a small agency actually uses. Here’s what we found, including the things both vendors would rather we didn’t emphasize.
What we tested
The 10 workflows were the ordinary backbone of a five-person services business: three lead-capture pipelines from different sources into a CRM, an invoice reminder sequence, a weekly reporting roll-up, a content cross-posting flow, two alerting flows, a data cleanup job, a client onboarding sequence, and one experimental AI-summarization flow. Combined, they move roughly 40,000 operations a month. Every workflow was built twice — once in n8n, once in Make — and run in parallel on live data.
Before the results, a word about what each tool actually is, because the marketing pages blur this.
The core difference in one paragraph
Make counts operations — every step that does anything in a scenario, including iterations inside loops. n8n counts executions — one run of a workflow, no matter how many steps it contains. This single accounting difference explains most of the cost divergence you’ll experience at scale, and it’s the thing people consistently underestimate when they compare pricing pages.
Pricing as it actually lands
Here’s the pricing table as of our testing window, with what it meant for our 40k operations/month workload:
| Plan | Make | n8n Cloud |
|---|---|---|
| Free tier | 1,000 ops/month | 250 executions (trial) |
| Entry paid | Core ~$9/mo, 10k ops | Starter ~$24/mo, 2.5k executions |
| Mid tier | Pro ~$16-18/mo, 10k ops + more scenarios | Pro ~$60/mo, 10k executions |
| Our workload cost | ~$29-41/mo (Core + add-ons) | ~$60-100/mo |
| Self-hosted | Not offered | $8-15/mo server, unlimited |
Read that last row again. Self-hosted n8n on a modest VPS ran our entire workload — every workflow, every operation — for the cost of a coffee a month. That’s the number that changes the calculus for most people who take the time to think about it.
But cost-per-operation isn’t the whole story. Here’s how the month actually went.
Where n8n won
Complex data transformation. Half our workflows needed to reshape data — splitting a customer record into line items, aggregating by week, cleaning inconsistent dates. n8n’s Code node (JavaScript or Python) handled every gnarly case we threw at it. Make has text parsers and aggregation tools that work for the common cases, but when we needed “group orders by customer, then for each customer compute the largest gap between orders,” Make required us to build a small Rube Goldberg machine of iterator-aggregator-router steps, and n8n needed one Code node.
Error transparency. When an n8n workflow fails, the execution log shows you exactly which node failed, what data it received, and what it tried to do. When a Make scenario failed, we sometimes spent minutes clicking through the blueprint view to find which module quietly produced an empty bundle. One of our alerting workflows failed silently in Make for six days because the filter module ate everything after an upstream schema change — no error, no notification, just no alerts. In n8n, the equivalent breakage threw a visible execution error on the first run.
Loops and batches. Processing 500 items in n8n is one execution. In Make, depending on how you structure it, those iterations consume operations from your quota — a 500-row sync could eat half a Make Core plan’s monthly allowance in one run.
Self-hosting. This is n8n’s trump card and the reason it dominates cost comparisons at volume. Our data stays on our server, and there is no quota to hit.
Where Make won
Onboarding speed. Our least technical team member — the one who explicitly avoids anything resembling code — built her first working Make scenario in an afternoon and has maintained it happily since. Her attempt to learn n8n stalled twice on concepts like “expressions” and “execute once” before she went back to Make. If your team includes people like her, this matters more than any pricing table.
The visual canvas. Make’s scenario editor is genuinely pleasant. Seeing the data flow left-to-right through modules, with the ability to click any module and inspect what it received and produced, is the best debugging-by-eyeballing experience in the category. n8n’s canvas is good; Make’s is friendlier.
Built-in templates and patterns. For the standard stuff — “new Google Sheets row → send Slack message” — Make’s template library and the module search flow made the common path genuinely fast. n8n’s template library exists and has grown a lot, but the community templates we tried needed more fixing-up.
Iterators, sorters, and the small stuff. Make’s iterator and array-aggregator modules handle the “process each item then put it back together” pattern with zero code and zero thought. It’s one of the things Make does that we genuinely miss in n8n.
What broke in each
This is the section the pricing pages never show you.
In Make: the silent filter failure above was the worst. We also hit a rate limit on the HTTP module that produced retries with exponential backoff we hadn’t configured — it turned a 30-second flow into a 20-minute one without telling us. And the error handler modules, when we finally set them up, took an afternoon to understand properly.
In n8n: a webhook step failed when a payload exceeded a size limit we didn’t know existed — the error message pointed us to the wrong setting. The AI node burned through more credits than expected because we hadn’t realized a “summarize” node was calling the model per-item rather than per-batch. And upgrading self-hosted n8n between two minor versions required a manual database migration step that the docs mentioned only in passing.
Both tools have sharp edges. The difference is that n8n’s failures were loud and Make’s were quiet. We prefer loud.
A debugging session, reconstructed
To make the loud-versus-quiet difference concrete, here’s the worst hour of our test month, reconstructed from our notes. The invoice reminder workflow — invoice data from the accounting API, filter for unpaid-and-due, send email — stopped working. Same underlying cause in both tools: the accounting API renamed due_date to dueDate in a response payload.
In n8n, the first failed run threw an error within a minute of the API change: “Cannot read properties of undefined (reading ‘split’)” on the Date node, with the execution log showing the incoming item JSON — where due_date was visibly absent and dueDate visibly present. Total fix: click the failing node, look at the received data, re-map the field, save. Four minutes including the coffee sip between steps.
In Make, the scenario kept running green. The filter module compared dueDate against a threshold, got nothing, evaluated nothing against nothing, and passed zero bundles onward — which is a perfectly ordinary outcome for a filter. No emails sent, no error, no warning. We found it on day three when a client called about a missing reminder, opened the scenario history, and saw runs of 12 operations each with zero output bundles, all “successful.” Diagnosis: twenty minutes of comparing module inputs against outputs to find where items vanished. Fix: two minutes. Total cost of the quiet failure: three days of un-sent reminders and an apologetic phone call.
That’s the pattern in one story. n8n errors when data doesn’t match expectations; Make shrugs and produces nothing. When your automations feed real business processes, “successfully did nothing” is the most expensive failure mode there is.
Which team shapes fit which tool
The pricing and debugging sections cover the tools in the abstract; here’s the decision from the team’s side, because we’ve now watched this choice play out across several clients:
The one-operator business. You’re the founder, the operator, and the automation department, and your time is the constraint. Make. The onboarding speed is worth real money when there’s nobody to delegate debugging to, and your volume (typically under 10k ops/month) keeps the cost difference small. Revisit if volume triples.
The agency with one technical person. Someone on the team — maybe you, maybe the one developer-adjacent hire — enjoys this stuff and becomes the internal expert by accident. n8n, self-hosted from the start. The technical person absorbs the Docker-and-updates overhead in an hour a month, and every nontrivial workflow routes through them anyway, so the friendlier canvas buys less.
The mixed team (our shape). Half the team automates, half won’t ever. This is the both-tools case from our verdict, and it’s more common than either vendor admits: n8n for the pipelines one team owns, Make for the scenarios the other team maintains. The only real cost is paying two subscriptions, and at modest volume that’s less than a single mis-sized plan on either side.
The compliance-constrained shop. Clients or regulators specify where data may physically live. The decision is already made: self-hosted n8n, because it’s the only option in this comparison where the data never leaves a server you control. Make has no self-hosted tier, and no canvas prettiness compensates for a contract clause.
Migration costs, if you switch later
Since neither tool can import the other’s workflows, a mid-life switch means rebuilding. For calibration: our 10-workflow portfolio took roughly 18 hours to rebuild Make→n8n the first time (we were learning), and our most recent client migration of comparable scope took 9 hours (we weren’t). The rebuilding itself is mechanical; the expensive part is the audit — opening every workflow, asking “what does this actually do,” and discovering the undocumented filters and edge-case handlers the original builder forgot. Budget the audit at the same size as the rebuild, run both tools in parallel for two weeks before cutover, and keep the old scenarios paused (not deleted) for a month as a reference.
The cost math, honestly
Let’s redo the pricing table with our actual measured usage, at three volume levels:
| Volume | Make (realistic plan) | n8n Cloud | n8n Self-hosted |
|---|---|---|---|
| 5,000 ops/month | Core $9/mo (fits) | Starter $24/mo | ~$8/mo VPS |
| 40,000 ops/month | ~$29-41/mo | Pro $60/mo | ~$10/mo VPS |
| 400,000 ops/month | ~$100+/mo, plan gymnastics | Pro+ or negotiations | ~$20/mo VPS |
The crossover is roughly at a few thousand operations a month: below that, Make’s free tier or Core plan is cheaper than an n8n VPS. Above it, self-hosted n8n wins by an increasingly absurd margin. The people who get hurt are the ones who start on Make’s free tier, grow organically, and discover the operation-counting cliff one busy month in.
Our verdict
Pick Make if you’re starting from zero, your workflows are the standard connect-app-A-to-app-B variety, your team includes people who will never write a line of code, and your volume is modest (under ~10k operations a month). You’ll ship your first automation faster, and the free tier is enough to know whether automation is for you.
Pick n8n if you have any developer-adjacent person on the team, you expect volume growth, you need custom data transformation, or data residency matters to you or your clients. Self-hosting n8n is the single highest-leverage cost decision available in this category.
Our own outcome: we consolidated on self-hosted n8n for the heavy pipelines (lead routing, reporting, the AI flow) and kept one Make account for the simple alerting scenarios the non-technical half of the team maintains themselves. The combination costs us less per month than either tool alone would at full workload.
That’s not a cop-out answer — it’s what actually made sense after 30 days of both tools running the same real work. But if you force us to pick one tool, forever, sight unseen: n8n, because loud failures and unlimited executions age better than a pretty canvas and quiet quota overruns.
Update cadence
We re-verify pricing and feature claims for this comparison quarterly. Both vendors adjust pricing tiers frequently enough that you should check their current pricing pages (linked below) before committing to a plan.