n8n 2.0 review — what changed, what's better, what to actually use it for

n8n 2.0 shipped in January 2026. The 2.4 minor release (April 2026) is the version we now ship on every new NexFlow client engagement and have promoted 14 of 18 existing 1.x estates to. This is the honest review after enough time in production to know what works and what doesn't.

1 · The 70+ AI nodes — actually useful, mostly

n8n 1.x had AI nodes (OpenAI, basic LangChain) but they were second-class — the integration patterns were obvious add-ons. n8n 2.0 rebuilt the AI node family around three primitives: Chain (composable LangChain-style steps), Memory (persistent conversational state), and Tool (function-calling agents that can take real actions via other n8n nodes).

The node count breaks down roughly as:

• Model providers (12): OpenAI, Anthropic, Cohere, Mistral, Google Gemini, AWS Bedrock, Azure OpenAI, Ollama, vLLM, HuggingFace Inference, OpenRouter, plus a generic OpenAI-compatible node for self-hosted models.
• Chain composition (8): sequential, parallel, conditional, summarisation, retrieval, refine, map-reduce, conversation.
• Memory backends (6): buffer, window-buffer, summary, summary-buffer, vector-backed, Redis-persistent.
• Vector stores (10): Pinecone, Weaviate, Qdrant, pgvector, Chroma, Supabase, MongoDB Atlas Vector Search, Milvus, plus in-memory and local-disk fallbacks for dev.
• Embedding providers (8): OpenAI, Cohere, Google, HuggingFace, Ollama, BGE-M3 local, plus a generic node.
• Tool / agent (12): tool-calling agent, ReAct agent, structured-output parser, JSON schema validator, code-execution, web-search, calculator, plus 5 utility tools.
• Document loaders & splitters (14+): PDF, DOCX, web crawler, GitHub, Notion, Confluence, S3, plus all common text-splitting strategies.

The verdict after five months: about 80% of the AI node family is good enough to ship without modification. The remaining 20% — mostly the more obscure document loaders and a couple of vector-store variants — work but have edge cases that require a code node to clean up output. Compared to LangChain-from-scratch in a Function node (the only path on n8n 1.x), the development time savings are substantial: a RAG chatbot that took us 3 days to build cleanly in 1.x ships in roughly 1 day on 2.x.

2 · Persistent agent memory — the killer feature

n8n 2.0's Memory node was the single feature that flipped our default architecture. In 1.x, conversational state was the client's problem — sessionIds, vector stores, custom Function nodes that kept buffers in Redis. In 2.0, the Memory node takes a sessionId and a backend, and the conversation buffer Just Works across workflow executions, container restarts, and database backups.

Practical impact: every chatbot we ship now uses the n8n-native Memory node. The "bot forgot what I just said" bug class disappears. The sessionId discipline is now handled at the trigger layer — the n8n Advanced AI Chat Trigger passes a session identifier through to Memory automatically — which means client code doesn't need to track anything beyond the trigger URL.

3 · Queue mode — 5–10× throughput on the same hardware

n8n 1.x had queue mode but it was a single-process bottleneck for many workloads. The 2.0 rewrite uses BullMQ over Redis, with proper worker isolation, retry policies, and concurrency controls per workflow. On a single Hetzner CX22 we used to comfortably run about 8,000 executions/day. The same hardware on 2.0 handles 40,000-50,000 executions/day with the same latency profile.

What this unlocks for SMBs: workloads that used to require horizontal scaling (multiple n8n instances behind a load balancer, which most SMBs avoid because of the operational complexity) now run on a single small VPS. For the typical NexFlow client running 5,000–30,000 monthly executions, that means n8n self-hosted moves from "viable" to "comfortable" on the smallest commercial cloud tier.

Workload	1.x · executions / hr (CX22)	2.x · executions / hr (CX22)	Improvement
Webhook → HTTP → DB write (simple)	~1,800	~9,400	5.2×
OCR + AI extract + Xero post	~120	~640	5.3×
RAG chatbot turn (memory + 2 vector calls)	~340	~2,100	6.1×
Multi-step agent (4 tools, ReAct loop)	~85	~520	6.1×

Caveat: these numbers are with externally-rate-limited AI calls factored out — most workloads in practice bottleneck on OpenAI's TPM (tokens-per-minute) rate limit before they bottleneck on n8n's process throughput. The 5–6× speedup is what you can theoretically get; the real-world ceiling for AI-heavy workloads sits between the two.

What's still rough

1 · LangChain version pinning is brittle

n8n 2.x bundles a specific LangChain version per release. When upstream LangChain ships a breaking change (and they do — quarterly), n8n's catch-up release lags by 2–6 weeks. If you've been hand-crafting code that interoperates with the bundled LangChain, those weeks can be painful. NexFlow's standard practice: avoid relying on LangChain's lower-level primitives from Code nodes; use only the n8n-wrapped Chain / Memory / Tool nodes.

2 · The new credentials UI on small screens

The hierarchical credentials UI is clearly better for large estates with shared credentials. On a 13" laptop, the three-column layout (folders / credentials / details) is too cramped. Either use a larger monitor when managing credentials, or stay on the legacy view (still available via a toggle in user settings).

3 · Function node migration if you used globals

n8n 1.x's Function node sandbox exposed some undocumented globals — global.$item across iterations, runtime mutations on the input array, etc. n8n 2.x's sandbox is stricter (good for security, bad for migrations). Any Function node that relied on these will need rewriting. Our experience: about 1 in 12 production Function nodes needed a touch on the upgrade; the rest migrated cleanly.

4 · Documentation lag on community nodes

The first-party node documentation is current and good. Community-maintained nodes (still about 40% of available integrations) often haven't been updated to reflect 2.x's API changes. If you use a community node, test in staging first; don't trust the documentation at face value.