--- title: "How to choose a VPS for an API: CPU, RAM and connections | StreetHosting" description: "See how much CPU, RAM and how many concurrent connections your API needs, how the runtime changes the math and when to scale, with real Ryzen and Xeon plans." url: "https://streethosting.com.br/en/guides/vps/choose-vps-for-api" type: "page" language: "en-US" --- VPS · 10 min · Intermediate Published on Sep 28, 2026 · Updated on Sep 28, 2026 # VPS for an API: sizing by runtime, connections and database A Node.js API, a Python API and a Java API with the same traffic call for different VPS plans. See how the runtime, concurrent connections and the database define CPU and RAM, how to measure before you buy and how to grow later. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Hardware and datacenter](https://streethosting.com.br/en/guides/topics/hardware) [Deploying and running apps](https://streethosting.com.br/en/guides/topics/deploy) [Performance and optimization](https://streethosting.com.br/en/guides/topics/performance) [Costs, plans and billing](https://streethosting.com.br/en/guides/topics/costs) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20choose%20a%20VPS%20for%20an%20API%3A%20CPU%2C%20RAM%20and%20connections&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api "Share on LinkedIn") [](https://wa.me/?text=How%20to%20choose%20a%20VPS%20for%20an%20API%3A%20CPU%2C%20RAM%20and%20connections%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fchoose-vps-for-api "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/choose-vps-for-api.md) In this guide 8 sections * [How an API consumes a VPS](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#como-api-consome) * [The runtime changes the math](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#runtime) * [Concurrent connections and limits](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#conexoes) * [Factoring in the database](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#banco) * [Measure before you choose](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#medir) * [Sizing table](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#tabela) * [How to scale later](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#escalar) * [Ryzen or Xeon for your API](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#onde-rodar) Quick answer To choose a **VPS for an API**, start from the runtime and the database, not from estimated traffic. Add up the memory of each process or worker, of the database and of the cache; pick vCPUs based on the language's concurrency model; and confirm with a load test. An API with the database on the same machine starts well with 2 to 4 vCPUs and 4 to 8 GB of RAM, from R$ 66.00 to R$ 118.00 per month on the Ryzen 9 9950X line. ## How an API consumes a VPS[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#como-api-consome) Every request has two phases. In the first, the API works: it validates data, checks the token, builds the JSON response. That is CPU. In the second, it waits: on the database, on another API, on the disk. Waiting does not burn CPU, but it keeps the connection open, takes up memory and holds a worker. Knowing which phase your API spends more time in decides what to buy. * **CPU-bound API:** server-side rendering, PDF generation, image resizing, cryptography. Here the clock speed of each core drives latency. * **Wait-bound API:** the most common case, a CRUD that queries the database and returns JSON. Here what matters is the number of workers, memory and latency to the database. * **Treacherous endpoints:** login with bcrypt or argon2 deliberately spends tens to hundreds of milliseconds of CPU per attempt. A spike in logins, or a brute-force attack, saturates the CPU of an API that sits idle the rest of the time. The target that guides the choice is latency at the 95th percentile, the maximum time 95% of requests take. Averages hide problems: an API with a 40 ms average can have 5% of responses going past two seconds. ## The runtime changes the math[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#runtime) The same traffic calls for different resources depending on the language, because each runtime uses cores and memory its own way. | Runtime | How it uses cores | What weighs on RAM | Tends to prefer | | ----------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------ | ----------------------------------------- | | Node.js | One core per process for JavaScript; more processes with PM2 in cluster mode | Heap of each process | High clock, Ryzen line | | Python (FastAPI, Django) | One core per worker because of the GIL; scales with several workers | Each worker duplicates the application in memory | vCPUs for workers; clock helps latency | | PHP (Laravel with PHP FPM) | One process per in-flight request | Memory per process times the total number of processes | RAM and vCPUs, Xeon line does well | | Java and Kotlin (Spring Boot) | Several cores in one process, with threads | JVM heap, set by Xmx | RAM and several cores | | Go, Rust and .NET | Several cores in one process, with little overhead | Low per connection | Any line; extra vCPUs are put to good use | Two practical consequences. In Node.js, a 4 vCPU VPS with a single process uses only one core for application code: without cluster mode in [PM2](https://streethosting.com.br/en/guides/vps/pm2-vs-systemd-nodejs) or several processes behind Nginx, the other three sit idle. In Python with Gunicorn, the documentation suggests starting with two times the number of cores plus one as the number of synchronous workers; with Uvicorn's asynchronous workers, one per core is usually enough. Each worker loads a copy of the application, so RAM grows with it. The [Node.js API on a VPS](https://streethosting.com.br/en/guides/vps/host-nodejs-on-vps) guide shows the Node.js side of this setup in practice. In PHP and Java the memory math is more direct. In PHP FPM, the maximum number of processes, the `pm.max_children`, comes from dividing the RAM reserved for PHP by the average memory of one process, which you see in `htop` with the application in use: 2 GB for 60 MB processes gives about 33. Going past that makes the VPS hit swap at peak. On the JVM, total memory is larger than the heap, because threads, metaspace and buffers live outside it, so leave headroom between `-Xmx` and the free RAM of the VPS. ## Concurrent connections and limits[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#conexoes) Requests per second and concurrent connections are different things, and the link between them is simple: in-flight requests equal throughput multiplied by response time. An API with 200 requests per second and 50 ms responses has, on average, only 10 requests in flight. If the database slows down and the response climbs to 500 ms, that is 100 at the same time, with the same traffic. That is why a slow database takes down the whole API: the workers run out. WebSocket and Server Sent Events change the math, because each connected user holds a connection for minutes or hours. Then what counts is memory per connection and the system limits, which are low by default: * **Open files per process:** each connection is a file descriptor, and the default limit for a service is usually 1024. Raise it in the systemd unit with `LimitNOFILE=65535`, as in the example right below the list. * **Nginx:** Ubuntu ships with `worker_connections 768`, and each connection proxied to the API counts twice, once with the client and once with the application. * **Protection:** rate limit requests per IP in Nginx with `limit_req`, especially on login and sign-up. That protects the CPU from bursts and bots. To raise the open file limit without editing the original unit, create an override with `sudo systemctl edit minha-api`, add the lines below and restart the service. Check the applied value in `/proc/PID/limits`. `[Service] LimitNOFILE=65535` ## Factoring in the database[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#banco) In most APIs, the database is the bottleneck before the application's CPU. Three points decide whether it fits on the same VPS and how much it weighs: * **Connection pool:**the total number of database connections is the pool size times the number of API processes. Four processes with a pool of 25 open 100 connections, exactly PostgreSQL's default limit. * **Queries per request:** the N+1 pattern, where a listing fires one query per item, multiplies latency. An endpoint with 50 queries feels every millisecond of distance to the database. * **Cache:** results that rarely change can live in [Redis](https://streethosting.com.br/en/guides/vps/install-redis-ubuntu-vps), which also holds sessions and background job queues. With the database and the API on the same VPS, add the RAM the database needs, which is usually the biggest slice. How to work out that part is in [how to choose a VPS for a database](https://streethosting.com.br/en/guides/vps/choose-vps-for-database). ## Measure before you choose[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#medir) No table replaces a load test against your API. k6 is a free tool that simulates virtual users from a short script: `// teste.js import http from "k6/http"; import { sleep } from "k6"; export default function () { http.get("https://api.seu-dominio.com.br/produtos"); sleep(1); } // in the terminal, from another machine k6 run --vus 50 --duration 2m teste.js` Run the test from another machine, never from the VPS itself, otherwise the load generator competes with the API for CPU. Point it at a test environment or at read-only endpoints, raise the virtual users gradually and, meanwhile, watch the VPS with `htop` and `vmstat 1`. * p95 latency within target at the expected peak * CPU below 70% at peak, leaving room for bursts * No sustained swap usage * Database pool with no requests waiting for a connection * Zero error rate during the test If the test saturates the CPU with few users, hunt down the most expensive endpoint before thinking about a bigger plan. In production, track these numbers continuously with a tool like Netdata. ## Sizing table[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#tabela) The scenarios below assume API, database and cache on the same VPS, which is how most projects start. Use them as a starting point and confirm with the load test. | Scenario | Ryzen 9 9950X VPS | Xeon E5-2680 v4 VPS | | -------------------------------------------- | ------------------------- | ------------------------- | | Webhook, bot, MVP or internal API | 1 vCPU, 2 GB: R$ 40.00 | 2 vCPU, 2 GB: R$ 26.00 | | App API with the database on the same VPS | 2 vCPU, 4 GB: R$ 66.00 | 3 vCPU, 4 GB: R$ 43.00 | | Production API with Redis and a queue | 4 vCPU, 8 GB: R$ 118.00 | 6 vCPU, 8 GB: R$ 77.00 | | WebSocket with many connected users | 6 vCPU, 16 GB: R$ 222.00 | 9 vCPU, 16 GB: R$ 145.00 | | Several services in Docker, SSR and workers | 8 vCPU, 24 GB: R$ 326.00 | 12 vCPU, 24 GB: R$ 213.00 | | High volume with a heavy database of its own | 10 vCPU, 32 GB: R$ 430.00 | 15 vCPU, 32 GB: R$ 281.00 | Notice that the Xeon line gives more vCPUs and the same amount of RAM for a lower price, while Ryzen delivers much faster cores. The choice between them depends on the API's profile, as the last section shows. The Budget line with the Ryzen 9 5900XT, listed on the same page, is out of stock at the moment. ## How to scale later[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#escalar) The first step is almost always vertical: a bigger plan. At StreetHosting, the upgrade is done through the control panel, charges only the prorated difference for the cycle, and raises memory, vCPUs and disk, with one VM restart. Schedule the restart for a quiet period. Before going up, though, check what usually pays off more: * **Indexes and queries:** a missing index can cost more than doubling the CPU. * **Response caching:** read endpoints that rarely change leave the database and move to Redis. * **Work outside the request:** email, notifications and file processing go to a queue with a separate worker. When vertical runs out or you need high availability, the path is horizontal: several API instances behind a load balancer. That requires an API with no local state: sessions in Redis, uploaded files in object storage, as in the [S3-compatible storage](https://streethosting.com.br/en/guides/vps/install-minio-on-vps) guide, and the database on its own server. With more than one server, manual deployment becomes a problem, and it is worth automating with GitHub Actions. ## Ryzen or Xeon for your API[](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#onde-rodar) The [Ryzen 9 9950X VPS](https://streethosting.com.br/en/vps/ryzen) is the pick when the latency of each request depends on the CPU: Node.js APIs, server-side rendering, heavy serialization, password hashing and image processing. It uses DDR5, reaches 5.7 GHz and goes from R$ 40.00 (1 vCPU, 2 GB, 20 GB NVMe) to R$ 846.00 (14 vCPU, 64 GB, 640 GB NVMe). The [Xeon VPS](https://streethosting.com.br/en/vps/xeon) does better when the API spends its time waiting: many Python or PHP workers, Java with many threads, and APIs that are basically a thin layer over the database. It gives more vCPUs for the money, from R$ 26.00 (2 vCPU, 2 GB) to R$ 553.00 (24 vCPU, 64 GB, 640 GB). The full comparison is in [Ryzen VPS or Xeon VPS](https://streethosting.com.br/en/guides/vps/ryzen-vs-xeon-vps). Both lines are in São Paulo, which lowers latency for users and integrations in Brazil, include Anti-DDoS, which matters for any public API, and activate within 60 seconds. If in doubt, start with the smallest option that passes your load test and move up through the control panel when the numbers call for it. In this guide * [How an API consumes a VPS](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#como-api-consome) * [The runtime changes the math](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#runtime) * [Concurrent connections and limits](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#conexoes) * [Factoring in the database](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#banco) * [Measure before you choose](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#medir) * [Sizing table](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#tabela) * [How to scale later](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#escalar) * [Ryzen or Xeon for your API](https://streethosting.com.br/en/guides/vps/choose-vps-for-api#onde-rodar) ## Frequently asked questions How many vCPUs does an API need? A small API with the database on the same VPS runs fine on 2 vCPUs. The real number depends on the runtime: Node.js uses one core per process, Python and PHP scale with the number of workers, and Java and Go use several cores in a single process. Measure with a load test before you upgrade. How much RAM does a VPS for an API need? Add up the memory of each process or worker, the database if it lives on the same VPS, Redis, and about 500 MB for the system. Simple APIs fit in 2 to 4 GB; with database, cache and queue together, 8 GB is a comfortable starting point. Ryzen or Xeon to host an API? Ryzen 9 9950X, with its higher clock, cuts the latency of each request and favors Node.js, server-side rendering and endpoints that do heavy processing. Xeon delivers more vCPUs for the money and does well with many Python, PHP or Java workers and with APIs that spend their time waiting on the database. How many concurrent connections can a VPS handle? The limit is rarely the VPS itself but the configuration: the process's open file limit, Nginx's worker\_connections, the database pool and memory per connection. With those tuned, a small VPS sustains thousands of idle connections, as with WebSocket. When should you scale the API to more than one server? When the largest viable plan no longer holds the peak, when you need high availability, or when the database and the application compete for resources. First, optimize queries and add caching, which usually pay off more than a bigger VPS. Next step See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS. [See Ryzen VPS](https://streethosting.com.br/en/vps/ryzen) [See Xeon VPS Xeon VPS for steady workloads, automation and long-running projects.](https://streethosting.com.br/en/vps/xeon) [See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS.](https://streethosting.com.br/en/vps) ## Related guides [VPS Intermediate How to host a Node.js app on a VPS in Brazil A Node.js app in production needs a process manager, a reverse proxy, HTTPS and automatic restarts. Follow the complete walkthrough on an Ubuntu VPS in São Paulo, close to your users and to Brazilian integrations. 9 min Read guide](https://streethosting.com.br/en/guides/vps/host-nodejs-on-vps) [VPS Intermediate How to deploy FastAPI on a VPS with Gunicorn and Nginx A production-ready FastAPI API on an Ubuntu 24.04 VPS: Python in a virtual environment, Gunicorn managing Uvicorn workers through the current package, a systemd service with zero-downtime reload, Nginx with HTTPS, and how to size the workers. 9 min Read guide](https://streethosting.com.br/en/guides/vps/host-fastapi-on-vps) [VPS Intermediate How to choose a VPS for a database: RAM, CPU and NVMe A slow database is rarely fixed with more vCPUs: almost always it is short on RAM for the hot data or stuck on disk latency. Learn how to measure what your database actually consumes and pick the plan by the right number. 9 min Read guide](https://streethosting.com.br/en/guides/vps/choose-vps-for-database) [← Back to the Guide Center](https://streethosting.com.br/en/guides)