Take a notification service that sends push messages and WhatsApp templates for around two million users. Written in Node.js, a service like that commonly ends up on five or six containers at a few hundred megabytes each. Rewritten in Go, the same load often fits on two containers using under 100 MB. That looks like a clear win for Go, and for that kind of service it usually is. Yet the customer dashboard API sitting next to it is often better left in NestJS. Here is how we think about the choice.
The Short Comparison
| Aspect | Go | Node.js |
|---|---|---|
| Concurrency | Goroutines spread across all CPU cores by the runtime | One event loop per process, worker_threads or more processes for extra cores |
| Idle memory per instance | Often 10 to 30 MB | Often 50 to 100 MB before your code does much |
| CPU-heavy work | Fine, it runs in parallel | Blocks the event loop unless moved off the main thread |
| Typing | Static types checked by the compiler, always on | TypeScript on top of JavaScript, only as strict as your tsconfig |
| Deployment artifact | One static binary, images of 10 to 25 MB are common | Runtime plus node_modules, images of 150 MB or more are common |
| Ecosystem | Strong standard library, fewer but stable packages | npm has a package for nearly everything, quality varies a lot |
| Hiring in Indonesia | Smaller pool, mostly mid and senior engineers | Very large pool, easy to find juniors |
Performance and Memory
For plain I/O work, such as an API that reads from PostgreSQL and returns JSON, the gap is smaller than benchmarks suggest. V8 is fast, and most of the time is spent waiting on the database anyway. A well written Fastify service and a Go service using net/http will both serve a few thousand requests per second per core on that kind of endpoint.
The difference shows up in two places. The first is memory. A Go process starts small and stays predictable, which matters when you pay per container or run on a modest VPS. The second is tail latency under load. Go spreads work across every core in one process, and its garbage collector usually pauses for well under a millisecond. A Node process uses one core for JavaScript, so a single slow request can make every other request on that process wait.
Goroutines and the Event Loop
Node runs your JavaScript on one thread. Network and file I/O are handed to the operating system or to libuv, and callbacks come back to the loop when results are ready. This model is efficient as long as nothing on the main thread takes long. The trouble starts with code that looks innocent. A JSON.parse on a 20 MB payload, a synchronous bcrypt call, a badly written regular expression, or a loop over a hundred thousand rows will freeze every request on that process until it finishes.
Go takes the other route. Each request runs in its own goroutine, which starts with a stack of a few kilobytes, and the scheduler maps thousands of them onto OS threads across all cores. You write plain blocking code and the runtime handles the waiting. A slow request only slows itself. Since Go 1.25 the runtime also reads the container CPU limit when setting GOMAXPROCS, so it behaves sensibly in Kubernetes without extra tuning. The cost is that you now have real parallelism, with data races to think about. We covered the habits that prevent those in our Go concurrency article.
Go Types Versus TypeScript
Very few teams write plain JavaScript on the backend now, so the real comparison is Go against TypeScript. TypeScript has the richer type system. Union types, generics with conditional types, and inference make it expressive. Go is plainer, and some people find it repetitive, especially the if err != nil checks.
In practice the plainness helps on long-lived services. TypeScript types disappear at runtime, so data from a request body or a third-party API is only as safe as your validation with Zod or class-validator. Any can creep in, and strict mode is often switched off in older projects. In Go the compiler checks everything, there is one formatter, and code written by a new hire looks a lot like code written by the tech lead. Newer Node versions can run .ts files directly by stripping types, which is handy, but you still need tsc in CI to get any checking.
Ecosystem and Hiring in Indonesia
JavaScript is the language most Indonesian developers learn first, through bootcamps, campus projects, and frontend work. Finding a Node.js developer in Bandung or Jakarta takes days. Go became popular here mainly through Gojek, Tokopedia, and other large tech companies, so Go engineers tend to be mid level or senior, and they cost more. If you need to grow a team quickly with juniors, Node is the easier road.
On libraries, npm wins on breadth. There is an SDK for every payment gateway, every SaaS tool, and every odd file format. Go has fewer packages, but the standard library covers HTTP, JSON, crypto, templates, and testing well. Since Go 1.22, net/http supports method and path parameters in routes, so many services no longer need Gin or Echo. Fewer dependencies also means fewer surprise security advisories to patch.
Deployment and Operations
A Go service builds into one binary. You can copy it into a distroless image, ship it to a server with scp, or run it as a systemd unit. Cross compiling for Linux from a Mac is one environment variable. A Node service needs the runtime, a lockfile, and node_modules, which often holds several hundred megabytes before pruning. Docker smooths most of this over, but image size still affects pull time, cold starts, and registry costs. On the other hand, Node gives you faster local feedback with hot reload, and most PaaS platforms support it with zero configuration.
How We Decide
- Pick Node.js when the team is already strong in TypeScript, the frontend is Next.js or React and can share types with the backend, and the service is mostly CRUD around a database.
- Pick Node.js when you need many third-party SDKs and speed of delivery matters more than server cost.
- Pick Go for services with high concurrency, such as gateways, WebSocket servers, queue workers, and anything that fans out to many other services.
- Pick Go when memory per instance drives your bill, or when CPU-heavy work like image processing, PDF generation, or encryption sits on the request path.
- Pick Go for CLI tools and internal agents that must run on many machines without installing a runtime.
Running Both Is Normal
Many of the teams we work with end up running both, and that works well. A common setup puts a Next.js frontend and a NestJS or Express API in front of users, with Go services behind it for the heavy parts. The two sides talk over HTTP with an OpenAPI contract, or over gRPC when latency matters. If you go this way, a few rules keep it manageable.
- 1Profile first. Find the endpoint or job that actually hurts, using clinic.js or the Node inspector, before deciding anything moves.
- 2Move one bounded piece, such as a report generator or a webhook consumer, and keep the same API contract so callers do not change.
- 3Run both versions side by side for a week and compare latency, error rate, and cost.
- 4Share one logging format and one tracing setup with OpenTelemetry so a request can be followed across both languages.
Rewriting a working Node service in Go because Go is faster is rarely worth it. Moving the one hot path that costs you money usually is.
We build and maintain backends in both languages, and our Golang training is often taken by Node.js teams who want to move one or two services to Go without stopping feature work. If that sounds like your team, we are happy to talk through which services make sense to start with.
Key takeaways
- For simple database-backed APIs the speed gap between Go and Node.js is small, and memory use is where Go clearly wins.
- Node runs JavaScript on one thread per process, so any CPU-heavy code on the request path slows every other request.
- Go types are checked at compile time and always on, while TypeScript safety depends on strict settings and runtime validation.
- Node developers are much easier to hire in Indonesia, and Go engineers tend to be more senior and more expensive.
- A mixed setup with Node for product APIs and Go for heavy or highly concurrent services is common and works well.
