Python vs JavaScript Performance: Best Backend Language 2026 (FastAPI vs Bun)

In this video, we’ll compare the most widely used backend languages, especially for full-stack development: Python and JavaScript. For Python, we’ll use FastAPI, and as the JavaScript runtime, we’ll use Bun. We’ll measure latency, throughput, CPU, and memory usage. In the first very simple test, we’ll send a GET request, and the application will return 3 objects. Every single time, it will generate a new UUID for each just to make it more dynamic. In the second test, we’ll add a Postgres database, and I’ll also explain what happened with the connection pool in Bun in the previous test. In this test, we’ll send a POST request with a JSON payload, and the application will save that item to a Postgres database and return the entire object, including the database-generated ID, back to the client. I got multiple pull requests to improve both applications, and you can find the source along with the pull requests in the video description. Python was created in the late 1980s and got its first release in February 1991. In 1994, it got its 1. 0 release and received tools like lambda, map, filter, and reduce. Python 2. 0 was released in 2000 and introduced list comprehensions and a garbage collection system capable of collecting reference cycles. In 2008, with Python 3. 0, it got breaking changes; it was redesigned to fix fundamental flaws. And in 2020, official support for Python 2. 7 ended, marking the final transition of the community to Python 3. Currently, it's ranking #1 on the TIOBE index in 2025. The two main reasons why it became so popular are that it is very simple and readable, which makes it an ideal language for someone to start learning programming, and second, it became the de facto standard language for artificial intelligence. It is mostly used in data science and AI. Scientists use Pandas and NumPy to crunch data, and Scikit-learn to build predictive models. It is also used in web development with frameworks like Flask, Django, and FastAPI. And it is also popular in the DevOps community for automation. On the other hand, JavaScript was created in only 10 days in 1995. The problem it tried to solve was to add dynamic interactivity to web pages, as static HTML was limiting user experiences during the early web era. Later, in September, it was renamed to LiveScript, and finally, in December of the same year, to piggyback on the hype surrounding the Java language, it was renamed to JavaScript despite the two having very little in common. And it became a standard in 1997 when it was accepted by ECMA International. One of the reasons it got so popular was due to browser monopoly. Unlike other languages that had to be installed, JavaScript was shipped pre-installed on every consumer device in the world via the browser. This "zero-friction" distribution made it the default choice for UI. Eventually, developers started to use JavaScript for the backend as well, just because it allowed them to use the same language and reuse the modules that they had already created for the UI. Initially, Node. js was used as a runtime to run JavaScript on servers, but in 2021, Bun was released specifically to improve performance on the backend side. It is written in Zig and really can compete with other more specialized languages like Go. To run this test, I used AWS EKS and deployed 2 instances of each application with a 1 CPU limit on large instances with 2 CPUs, and I had a lot of other instances to generate load using Kubernetes jobs to spin up independent clients. Alright, let’s go ahead and run it. As always, each test usually takes about an hour or two so that I can slowly increase the load and not break anything ahead of time, and here you can see the entire test in just 1 minute. After that, we’ll go over each graph one by one.

Alright, first we have requests per second, and it’s not even close. In the previous test with Bun, I used a slightly larger payload and static objects. In this test, due to the smaller response, Bun achieved more requests per second, and FastAPI around 28,000 requests per second. I did receive multiple pull requests in the past with FastAPI improvements, but if you can improve it even more, I’ll rerun the tests, give you credit, and explain how to improve it for others. To run the second test, I installed a Postgres database on storage-optimized EC2 instances, one for each language, in addition to the applications and clients. Alright, let’s go ahead and run the second test. I added Postgres CPU usage as well as the connection pool size maintained by each application. Many asked me what happened in the previous test where Bun dropped connections in the middle of the test. Well, when you configure a database connection in your application, you have an option to set a maximum Lifetime for inactive connections. In the previous test, I used the default, which I think is 30 minutes. In this test, I reduced it to only 5 minutes to make it obvious what is going on with Bun. So, when Bun thinks it needs to increase the number of connections, it does not slowly increase them as other languages I tested. Instead, it just increases it to the maximum allowed number, which is 250 per application and 500 total. After it does it, it does not utilize all of them, and after 5 minutes, it drops inactive connections again. I think this can be improved in the SQL driver. Also, Bun has a runtime flag that allows your application to immediately create all those connections when you start the application. Alright, let me run it for another minute. As you can see, the difference is huge, and I tried different settings, different numbers of workers, and this is actually my 3rd test of FastAPI. If you’re a really experienced FastAPI developer, please help me to improve it; otherwise, it doesn’t look good.