Go (Golang) vs TypeScript Performance Benchmark (2026)

In this video, we'll compare Go with TypeScript.

We'll use the Fiber framework for Go and Bun for the TypeScript runtime.

In the first static test, I'll measure the latency of the requests, throughput, CPU, and memory usage.

In the second, more realistic test, I'll add a PostgreSQL database, and in addition to latency and throughput, I'll measure the database load as well as how many connections each application creates.

I think the biggest appeal of using JavaScript—or nowadays TypeScript—for front-end and back-end development is that it enables developers to become full-stack.

With a single language, you can create websites as well as develop APIs for your applications.

Node.js was released in 2009, which was the first widely adopted JavaScript runtime that allowed developers to create server-side applications using JavaScript.

Later, in 2018, Deno was announced and brought multiple improvements, such as enhanced security, native support for TypeScript, and more.

And more recently, Bun was released in 2021, specifically to boost performance.

It's written in Zig, a low-level language that enables precise memory management and high speed.

I recently published a benchmark comparing all three on AWS.

So now, you have a decent, performant TypeScript runtime that you can use for your back-end applications.

On the other hand, we have the Go language, which was specifically developed for server-side applications and optimized for networking.

The question is: Should you stick with the same TypeScript language and develop your back-end applications using Bun, or switch to Golang for potentially better performance?

For the first test, I created an EKS-managed Kubernetes cluster and deployed 2 instances, each with a single CPU core limit, on large instances.

I also deployed 40 independent clients running in different pods, and I slowly increased the number of threads in each to add more load until both applications started to fail.

In the first test, I used simple HTTP GET requests and returned static responses back to the client.

In the second test, I provisioned two more EC2 storage-optimized instances for the PostgreSQL databases, and each application, after receiving a POST request, saved that item in the relational database and returned the ID to the client.

I used quite large instances for the databases just to avoid bottlenecks, which made the test a little bit expensive. I use AWS to run all my tests and use the same production setup as I use for client-facing applications.

Let’s go ahead and run the first test.

You can find the source code in my public GitHub repo.

The entire test took around 2 hours, and I just compressed it into a single minute.

At the end we’ll go over each graph.

Alright, first we have latency.

Next we have throughput, or requests per second.

In this static test, it looks like Bun performs slightly better than Go, but I would say it's a very similar performance overall.

Bun did reach 200 requests per second on a 2-CPU instance, which is one of the best results I’ve seen so far.

Next we have CPU usage, which is also very similar.

And finally, we have memory usage—and for some reason, it does increase for Go with load.

Overall, I would say Go and Bun have similar performance in the first test.

Let’s see if Bun will be able to compete in something more complicated.

In this test, I added CPU usage of the Postgres instance as well as the connection pool size for each application.

I set the connection limit to 250 per instance, which is 500 total.

Bun immediately creates all connections, but Go slowly increases them based on the load. Alright,

let me run it for a minute.

First, we have throughput—and here you can clearly see that Go performs better and is more stable.

It reached 84,000 requests per second.

Next, we have latency, and here as well Go is significantly better compared to Bun.

Then we have CPU usage.

CPU usage of the Postgres instance itself.

Connection pool size.

And finally memory usage.

So, I would say that Go still outperforms in real-world use cases, especially if you interact with other microservices or databases, but the performance gap between TypeScript and server-side languages like Go definitely shrinks.

Let me know what I should test next.