N8n VS Make

Hey all,

Looking to dive deep into automations, but was wondering what platform to dive into. Seen pros and cons when comparing Make and n8n, and was wondering your guys’s thoughts!

I know you guys are probably biased, hahah:), but just want your perspectives, so don’t hold back.

From my understanding n8n might be more technical than make, but more opportunities because of that. In terms of learning curve, I have seen more knowledge about Make/Integromat, probably because its bigger as of now. But did you guys have trouble with this when learning the platform?

Thanks, appreciate all answers!

Hey @Bjorn_Stubrud - welcome to the community :tada:

I’m happy to share my thoughts here, though you might get the answer(s) you’re wanting more out of other users :sweat_smile:

While I am both obviously biased as part of the n8n team and as someone who hasn’t really used make much, one key difference is n8n doesn’t charge you extra for running more advanced workflows that have a lot of nodes or how much data you exchange. From my understanding, make also doesn’t really have this sort of community collaboration, or the ability to build your own integrations or self-host.

You can view an overview of the differences as outlined here.

I think part of the joys of working with n8n is it can be as simple or as complex as you want it to be - we’ve quite a few core nodes, and if you self-host, there’s even community nodes that might cover integrations we don’t have yet in the core product. If the integration you want doesn’t exist but the service has an API, the HTTP request node is extremely powerful. And if you get stuck, members of the n8n team like myself or members of the community who are genuinely just helpful people jump in. :slight_smile: Having these forums be an open, searchable form of a helpdesk greatly assisted me when I first started here!

So to summarise a long-winded reply that actually answers your question… while it can feel slightly overwhelming to start because of the control and customisation that n8n allows you to have, the documentation and forums are genuinely helpful and detailed. There are some trickier nodes, but it’s very easy to get help when you’re stuck. Just playing with product and following our courses will help you learn a lot!


Thanks for the reply! And perspective.

Your linked sites where very helpful as well!

I might actually go with n8n, cause it seems more scalable with techy part + its pricing structure. Again thanks!

Gonna go through the linked courses, and will let you know whenever I got questions.

1 Like

No worries @Bjorn_Stubrud , I’m glad I could help! If you run into any issues while you’re giving n8n a go, just make a new forum thread and follow our template, and you’ll get an answer quickly :smiley:

1 Like

@Bjorn_Stubrud I’ve talked with a lot of Make users who made the switch to n8n. Can +1 what @EmeraldHerald said.

@EmeraldHerald already touched on pricing model - I’d also like to underscore that for a vast majority of usecases, n8n will be more affordable than Make (that is when comparing our cloud offering to theirs). I’ve seen this countless times on folks migrating over. This is because we count per executed workflow, whereas they charge per “Operation”. From their own site “[an operation is] when your scenario reads a record from Pipedrive, writes a row into a Google sheet, or posts a tweet, each counts as one operation.”

So as an example:

  • First step pulls in 100 Google sheet rows; 100 operations
  • IF step to route those 100 rows, 100 operations
  • Push those 100 rows into a CRM, 100 operations

:point_up: This would be 1x workflow execution in n8n cloud terms, and 300 “Operations” (3 * 100) in Make terms. So of course it depends on what you’re doing. But as soon as it’s a non-trivial usecase (or even just “move these 1000 rows to that DB”) n8n will invariably be a better deal. Beyond the money, I also see technical users be able to build their flows “properly” and not have to make those very painful decisions regarding a well-engineer and robust flow vs. deliberately poor flow design in order to reduce operations.

Hope that helps!


Before starting with n8n, I actually liked Integromat quite a lot. But that changed rapidly when actually trying to use it for production ready stuff. It just misses some functionality or you have to do a lot of weird things to work around it. That made me pretty mad as these workarounds also made it a lot more expensive.

At first I didn’t like n8n, but that is because someone showed it to me that doesn’t really know how to introduce someone to a new platform.
When Integromat drove me crazy I tried n8n for my self, diving in watching some youtube video’s on the data structure and such of n8n. And then I was hooked. So yeah now I am a fulltime n8n consultant.

It is basically all about the flexibility. Most often you can simply use no code to create a flow. But sometimes it is nice to add an algorithm for example to fix something real quick. You can easily integrate that into your overall flow which is awesome. And if I am missing something I develop a node for it myself. Helping my self and the community which is of course very nice to be able to do easily/quickly.
Of course I am a bit biased, but I think n8n brings together all things you need for a good automation platform. Only thing lacking really is a dashboard, but you can of course fix one your self by simply extracting the data from the n8n api/database and constructing your own insights.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.