Back to blog
Backend Development 6 min read5 June 2026

Node.js vs Serverless — Which Backend Should You Pick in 2026?

Serverless promised to kill traditional servers. It didn't. Here's when to use each, based on what we've learned running both in production.

Node.js Serverless AWS Lambda Backend Architecture
H

Hanuman Singh

Founder & Lead Engineer · Hanuman Software Services

The promise vs the reality

Serverless (Lambda, Cloud Functions, Vercel Functions) promised zero infrastructure management, infinite scale, and pay-per-use pricing. For many use cases it delivers exactly that. For others, it creates a distributed systems nightmare. Here's how we think about the decision.

When serverless wins

  • Infrequent, bursty workloads. A webhook handler that fires 10 times a day, or a batch job that runs at midnight. Serverless costs almost nothing and you never think about it.
  • APIs with unpredictable traffic spikes. A product launch, a viral moment — serverless scales from 0 to 10,000 concurrent requests without any action on your part.
  • Small teams without DevOps expertise. No Kubernetes, no load balancers, no AMI updates. Deploy a function, move on.
  • Edge compute. Cloudflare Workers and Vercel Edge Functions run your code <50ms from every user on earth. For latency-sensitive responses, nothing else competes.

When Node.js (traditional server) wins

  • Long-running processes. Serverless functions time out (typically 15–30 seconds). Video processing, large file uploads, complex report generation — these need a persistent process.
  • Persistent WebSocket connections. Real-time apps (chat, collaborative editing, live dashboards) need a process that stays alive. Serverless doesn't do stateful connections.
  • High-volume, low-latency APIs. At scale, a warm Node.js server is cheaper and faster than cold-start serverless. If you're handling 10 million requests/day, run a server.
  • Complex database connection pooling. Serverless functions spawn new database connections per invocation. At scale this exhausts your Postgres connection limit. Workarounds (PgBouncer, RDS Proxy) add cost and complexity.

The architecture we actually use

For most products we ship a hybrid: a traditional Node.js/Express (or Fastify) server for the core API, and serverless functions for background tasks, webhooks, and scheduled jobs. You get the best of both.

The core API runs on a $20/month VPS or a small ECS container. Background jobs (sending emails, processing uploads, calling third-party APIs) run as Lambda functions triggered by SQS queues. Zero cold-start problems on the hot path, infinite scale on the async path.

The cold start problem in 2026

Cold starts are mostly solved for Node.js on modern serverless platforms — typically 200–500ms. For most applications this is acceptable. Where it's not: customer-facing APIs where p99 latency matters, or anything using large dependencies (machine learning models, heavy ORMs).

Our recommendation

Start with serverless (Vercel, AWS Lambda, or Cloudflare Workers) unless you have a known reason not to. You can always migrate hot paths to a traditional server when you have the traffic data to justify it. Premature infrastructure optimisation is as wasteful as premature code optimisation.

Need help designing your backend architecture? Book a free call — we'll map out the right approach for your specific traffic patterns and team size.

Interested in working together?

Free 30-minute discovery call — no commitment.

Book a call