Best VPS for API Hosting in 2026 — I Hit 15K req/s on a $12 Server

The 6 Things I Stopped Doing — And What Happened to Throughput

I started with a standard Express.js API on a 2 vCPU / 4GB Hetzner CX22. No optimization, just the way most tutorials teach you. The baseline: 1,840 requests per second. Then I changed one thing at a time and measured after each change. Here is the progression:

That is an 8.3x improvement. Same server. Same monthly bill. The hardware did not change — the way I used it did. Let me break down each optimization because the order matters.

1. Connection Pooling — The Single Biggest Win

Without pooling, every API request opens a new TCP connection to PostgreSQL. That is a 3-way TCP handshake, TLS negotiation if you are using SSL, and a PostgreSQL authentication exchange. Each one takes 5-12ms before your query even starts. At 500 concurrent requests, that is 500 simultaneous connection attempts, and PostgreSQL's default max_connections = 100 means 400 of them are queuing or failing.

With pg-pool maintaining 20 pre-established connections, API requests grab an idle connection in microseconds. The pool handles queuing when all 20 are busy. Throughput jumped from 1,840 to 4,210 req/s — a 129% increase from changing 4 lines of code. If you do nothing else from this article, add connection pooling. For Python, use SQLAlchemy's built-in pool. For Go, database/sql pools by default. For Node.js, pg-pool or Knex.js.

2. Response Compression — 70% Less Bandwidth

A typical JSON API response is 1-5KB uncompressed. Gzip reduces that to 300-800 bytes. The CPU cost of compression is negligible on modern hardware — Nginx compresses faster than the network can transmit uncompressed data. Let Nginx handle it with gzip on; gzip_types application/json; rather than compressing in your application. This frees your API workers to process requests instead of running zlib.

3. HTTP Keep-Alive — Stop Rebuilding the Highway

Without keep-alive, every request-response cycle tears down the TCP connection and the next request builds a new one. TLS handshake alone adds 1-2 round trips. With keep-alive enabled (Nginx: keepalive_timeout 65;, upstream: keepalive 32;), connections persist across multiple requests. The client sends request 2, 3, 4 on the same connection. For API consumers making sequential calls — which is most of them — this eliminates connection overhead entirely.

4. Reverse Proxy Buffering — Protecting Your Workers

Here is a scenario that kills API throughput: a mobile client on a 3G connection makes a request. Your API generates the response in 5ms, but the client takes 800ms to download it. Without proxy buffering, your Node.js worker is tied up for that entire 800ms, doing nothing but waiting for the client to finish receiving bytes. With 4 workers and 10 slow clients, you are already at capacity.

Nginx's proxy_buffering on absorbs the response from your API instantly, frees the worker, and drip-feeds the response to the slow client using Nginx's event loop (which handles thousands of slow connections without breaking a sweat). This is the optimization that matters most on APIs with mobile or international clients.

5. In-Memory Caching — Stop Asking the Same Question Twice

My test API had an endpoint that returned product listings. Every request ran the same SELECT against PostgreSQL, returning the same data that changes once per hour. Caching the response in Redis with a 5-minute TTL meant 99.9% of requests never touched the database. For read-heavy APIs — and most APIs are read-heavy — this single change cuts database load by an order of magnitude. Even a simple in-process cache (node-cache, lru-cache) works if you do not need cache invalidation across multiple API instances.

6. Query Optimization — The Forgotten Layer

The remaining bottleneck was the database queries that did hit PostgreSQL. SELECT * was returning 15 columns when the API only needed 4. A missing index on the WHERE clause forced a sequential scan on a 2 million row table. After adding a composite index and selecting only necessary columns, the cache-miss path dropped from 18ms to 3ms. That brought the overall throughput from 13,100 to 15,247 req/s. Run EXPLAIN ANALYZE on every query your API makes. If you see "Seq Scan" on a table with more than 10,000 rows, you are leaving performance on the floor.

The p99 Latency Trap Nobody Warns You About

Your API's average response time is 12ms. Looks great in the dashboard. But your p99 is 1,200ms. That means 1 in 100 requests takes over a second. Why does this matter more than average?

Because API consumers do not experience averages. A frontend making 5 parallel API calls experiences the maximum of those 5 response times. If each call has a 1% chance of hitting a 1,200ms outlier, the probability that at least one of the 5 calls hits it is 4.9%. Nearly 1 in 20 page loads feels slow, even though the "average" latency looks fine.

When I load-tested each VPS provider, I tracked p99 religiously. Average throughput tells you the best case. p99 tells you the worst case your users actually experience. Here is what I found: dedicated CPU instances (Hetzner CCX, Vultr dedicated) had 3-5x lower p99 variance than shared instances. If your API serves real-time traffic and your SLA includes latency percentiles, shared VPS is a gamble.

#1. Hetzner — 15,247 req/s on $5.29/mo Hardware

Hetzner is the provider where I ran the optimization progression above, and there is a reason I started here: AMD EPYC dedicated cores at prices that make other providers look like they are running a charity in reverse. The CX22 (2 shared vCPU, 4GB RAM, $5.29/mo) hit 15,247 req/s with all optimizations applied. The CPX21 (3 shared vCPU, 4GB RAM, $7.59/mo) pushed it to 18,900 req/s. But here is the number that matters: on the CCX13 dedicated vCPU plan ($14.49/mo), p99 dropped from 7ms to 2.8ms under the same load. Same throughput, dramatically tighter latency distribution.

Hetzner's network is what makes API hosting work at this price point. The 20TB included bandwidth means you are not counting bytes on a high-traffic API. Their internal network between Falkenstein and Nuremberg datacenters runs at sub-0.5ms latency, so if your API talks to a separate database VPS or Redis instance, the inter-service communication overhead is negligible. I ran a microservices setup with 3 Hetzner CX22s (API gateway, business logic, database) communicating over private network. Total inter-service latency for a 3-hop request: 1.4ms. The entire microservices architecture added less latency than a single unoptimized database query.

Hetzner Pros for API Hosting

• Highest throughput-per-dollar tested — 15,247 req/s on a $5.29/mo plan
• Dedicated CPU plans (CCX) eliminate noisy neighbor p99 variance
• 20TB bandwidth included — no bandwidth anxiety on high-traffic APIs
• Sub-0.5ms private network latency for microservices architectures
• Terraform provider and full API for infrastructure-as-code deployments
• Ashburn, VA datacenter for low-latency East Coast API serving

Hetzner Cons for API Hosting

• Only 1 US datacenter (Ashburn) — West Coast users add 60-70ms
• No managed database or managed Redis — fully self-managed
• No phone support
• Cloud console is functional but less polished than DigitalOcean

#2. Vultr — Put Your API Where Your Users Are

Here is a question most API performance guides skip: where are your API consumers? If your users are in Dallas and your server is in Ashburn, you are adding 35-40ms of network latency to every single request before your code even executes. For an API that averages 8ms of processing time, network latency is 80% of the total response time. You cannot optimize your way out of physics.

Vultr has 9 US datacenter locations: New York, Los Angeles, Dallas, Chicago, Seattle, Miami, Atlanta, Silicon Valley, and Honolulu. No other provider on this list comes close to that geographic coverage. I tested the same API (Express.js + PostgreSQL, all 6 optimizations applied) on Vultr's High Performance plan (2 vCPU AMD EPYC / 4GB / NVMe) at $12/mo. Result: 12,800 req/s with a p99 of 9ms. About 16% lower throughput than Hetzner at a higher price, but Vultr is not competing on raw power — it is competing on proximity.

I deployed the same API in Dallas, measured from a client in Houston: 4ms total response time. Same API on Hetzner Ashburn, same Houston client: 42ms total. The API was 10x faster for that user purely because of geography. If you run a multi-region API or need to minimize latency for a specific US metro area, Vultr's datacenter network is the differentiator. Their Kubernetes offering also supports multi-region API deployments with a single control plane.

Vultr Pros for API Hosting

• 9 US datacenters — unmatched geographic coverage for low-latency APIs
• High Performance plans with NVMe and AMD EPYC
• Sub-1ms private networking for API-to-database communication
• Managed databases (PostgreSQL, MySQL, Redis) in every region
• $100 trial credit for multi-region load testing
• Hourly billing for spinning up temporary load test instances
• Full API and CLI for automated deployments

Vultr Cons for API Hosting

• 16% lower throughput than Hetzner at a higher price point
• Base plans (Regular Performance) use older hardware — must select High Performance
• No phone support
• Managed database adds separate cost ($15/mo+)

#3. DigitalOcean — When Your API Needs a Platform, Not Just a Server

At some point, your API outgrows a single VPS. You need a load balancer distributing traffic across multiple API instances. A managed PostgreSQL database with automatic failover. A managed Redis layer for caching. Monitoring that alerts when p99 crosses a threshold. You can build all of this yourself on Hetzner or Vultr with Nginx, Patroni, Redis Sentinel, and Prometheus. Or you can click 6 buttons on DigitalOcean.

The raw performance is competitive but not chart-topping. The same Express.js API on a 2 vCPU / 4GB Droplet ($24/mo for Premium AMD) hit 11,200 req/s with a p99 of 12ms. That is 27% less throughput at 4.5x the price of Hetzner. But DigitalOcean is not selling you a server — it is selling you operational simplicity. Load balancer ($12/mo) with health checks, sticky sessions, and automatic TLS. Managed PostgreSQL ($15/mo) with daily backups and read replicas. Managed Redis ($15/mo) with failover. That entire stack, configured from a dashboard, costs ~$66/mo and takes 20 minutes to deploy. Building the equivalent self-managed on cheaper providers takes 2-3 days and ongoing maintenance.

The $200 trial credit is generous enough to load-test your API at production scale. I used it to test autoscaling: started with 2 Droplets behind a load balancer, simulated a traffic spike with k6, and watched the managed database handle the connection surge without intervention. For teams where engineering time costs more than server time, DigitalOcean is the rational choice.

DigitalOcean Pros for API Hosting

• Complete API platform: load balancer + managed DB + managed Redis + monitoring
• $200 trial credit — enough for production-scale load testing
• Managed PostgreSQL and Redis eliminate database ops burden
• App Platform for container-based API deployments without managing VMs
• Excellent API documentation and Docker registry integration
• Private networking between all components

DigitalOcean Cons for API Hosting

• 27% lower raw throughput than Hetzner at higher price
• Only 3 US regions (NYC, SFO, TOR-adjacent)
• Premium AMD plans required for competitive performance — regular Droplets use older CPUs
• Managed services add up fast — full stack hits $90/mo

#4. Kamatera — Scale CPU Vertically Without Rebuilding Your Stack

Most VPS providers make you choose a fixed plan: 2 vCPU or 4 vCPU. If your API needs 6 vCPU during business hours and 2 at night, you pay for 8 around the clock. Kamatera's component-based pricing lets you configure exactly what your API needs: 4 vCPU / 8GB RAM / 40GB SSD for one workload, 8 vCPU / 4GB RAM / 20GB SSD for another. You are not buying a plan — you are buying resources.

This matters for APIs because API workloads are CPU-bound. Unlike Redis (RAM-bound) or databases (I/O-bound), an API handling complex business logic, JSON serialization, authentication token validation, and response formatting is burning CPU cycles. When you hit a throughput ceiling, you need more CPU, not more RAM. On Kamatera, adding 2 vCPU to an existing server takes a reboot, not a migration to a new plan tier.

Performance on a 4 vCPU / 8GB configuration ($36/mo): 14,100 req/s with p99 of 8ms. Competitive with Hetzner but at a higher price point. The value is in the flexibility. I ran a load test, watched CPU hit 85%, added 2 vCPU via the dashboard, rebooted, and throughput jumped to 19,400 req/s. No data migration, no new IP address, no DNS changes. For APIs where traffic growth is unpredictable, this vertical scaling path avoids the complexity of horizontal scaling until you genuinely need it. The $100 trial credit covers several weeks of testing at production configurations.

Kamatera Pros for API Hosting

• Fully customizable CPU/RAM/storage configuration
• Vertical scaling without migration — add vCPU or RAM with a reboot
• Enterprise Intel Xeon CPUs with consistent per-core performance
• Hourly billing for burst capacity during traffic spikes
• $100 trial credit for testing custom configurations
• API and CLI for automated provisioning

Kamatera Cons for API Hosting

• Higher price-per-req/s than Hetzner for equivalent throughput
• Only 3 US datacenter locations
• No managed database or Redis offerings
• Dashboard interface has a steeper learning curve
• No private networking free tier

#5. Cherry Servers — Bare Metal When the Hypervisor Is Your Bottleneck

Every VPS on this list runs inside a virtual machine. The hypervisor adds overhead: CPU steal time, memory ballooning, I/O scheduling contention. For most APIs, this overhead is 3-8% and irrelevant. But if your API processes large payloads (image processing, PDF generation, data transformation), handles sustained high concurrency (5,000+ simultaneous connections), or requires deterministic latency for financial or real-time applications, that 3-8% becomes the difference between meeting your SLA and missing it.

Cherry Servers offers bare metal starting at $119/mo (E-2236, 6 cores / 12 threads, 32GB RAM, 2x 500GB SSD). No hypervisor. No noisy neighbors. No CPU steal. When I ran the same API benchmark on bare metal, the throughput number (28,400 req/s) was impressive but expected for 6 dedicated cores. The p99 number was the revelation: 1.9ms under sustained load, compared to 7-12ms on shared VPS plans. The latency distribution was a near-flat line instead of the spiky histogram you see on shared infrastructure. Every request got the same performance, every time.

Cherry Servers also offers a cloud VPS line starting at $10/mo for teams that want to mix bare metal API servers with cloud utility VMs (load balancers, cron workers, staging environments). Their API and Terraform provider support infrastructure-as-code workflows, and their BGP support is a niche advantage for APIs that need custom IP routing or DDoS mitigation at the network layer.

Cherry Servers Pros for API Hosting

• Bare metal eliminates hypervisor overhead and noisy neighbor variance
• Lowest p99 latency tested (1.9ms) — deterministic performance
• 28,400 req/s on 6-core bare metal
• BGP support for custom routing and DDoS mitigation
• Terraform provider and API for automated provisioning
• Mix bare metal + cloud VPS within the same account and network

Cherry Servers Cons for API Hosting

• Bare metal starts at $119/mo — overkill for APIs under 10K req/s
• Provisioning takes hours, not seconds (physical hardware)
• Limited US datacenter locations
• Smaller ecosystem and community compared to Vultr/DigitalOcean
• No managed database or Redis services

How to Load Test Your API Without Lying to Yourself

Most API load tests produce garbage numbers because they violate one or more of these rules. I have seen teams proudly announce "our API handles 50,000 req/s" based on tests that would not survive 5 minutes of scrutiny.

Rule 1: Never Load Test From the Same Server

Running wrk on the same VPS as your API is the most common mistake. The load generator competes for CPU, RAM, and network with your API. Your "10,000 req/s" result is actually "5,000 req/s from the API + 5,000 req/s of overhead from wrk eating your CPU." Always use a separate VPS on the same provider's private network. Budget $5-10/mo for a dedicated load test instance — it pays for itself in accurate data.

Rule 2: Use Realistic Payloads

Testing GET /health returns a 12-byte "ok" response. Testing GET /api/products?category=electronics&limit=50 returns a 14KB JSON payload involving 3 database joins and a cache lookup. These are not the same workload. Always test your slowest and most common endpoints, not your fastest one.

Rule 3: Ramp Up, Do Not Slam

Real traffic does not jump from 0 to 10,000 concurrent connections. Use k6's ramping pattern:

// k6 script for realistic API load testing
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },   // ramp up
    { duration: '5m', target: 100 },   // steady state
    { duration: '2m', target: 500 },   // spike
    { duration: '5m', target: 100 },   // recover
    { duration: '2m', target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ['p(99)<200'],   // p99 under 200ms
    http_req_failed: ['rate<0.01'],     // error rate under 1%
  },
};

export default function () {
  const res = http.get('http://your-api/endpoint');
  check(res, {
    'status 200': (r) => r.status === 200,
    'body not empty': (r) => r.body.length > 0,
  });
  sleep(Math.random() * 0.5); // simulate think time
}

Rule 4: Measure What Matters

Stop looking at average latency. Look at p99. Stop looking at max throughput. Look at throughput at your target p99. The question is not "how many requests can my server handle" but "how many requests can my server handle while keeping p99 under 200ms." Those are very different numbers. For the wrk quick test:

# Quick throughput test (from separate VPS)
wrk -t4 -c100 -d30s --latency http://your-api/endpoint

# Sustained load test with connection ramp
wrk -t4 -c100 -d60s --latency http://your-api/endpoint
wrk -t8 -c500 -d60s --latency http://your-api/endpoint
wrk -t8 -c1000 -d60s --latency http://your-api/endpoint

# Compare the p99 column across the three runs.
# The number where p99 doubles is your actual capacity.

Rate Limiting: The Feature Your API Is Missing

An API without rate limiting is an API waiting to be taken down. Not by a DDoS attack — by one enthusiastic consumer running a broken retry loop, or a scraper hitting your endpoint 1,000 times per second, or your own frontend making duplicate requests on every keystroke.

Two-layer rate limiting is the approach that works in production:

# nginx.conf
limit_req_zone $binary_remote_addr zone=api:10m rate=30r/s;

server {
    location /api/ {
        limit_req zone=api burst=50 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }
}

# Per-API-key limiting with Redis sliding window
# 100 requests per minute per API key
CURRENT = redis.incr(f"rate:{api_key}:{minute}")
if CURRENT == 1:
    redis.expire(f"rate:{api_key}:{minute}", 60)
if CURRENT > 100:
    return Response(status=429, headers={"Retry-After": "60"})

API Hosting VPS Comparison Table

All tests: Express.js + PostgreSQL API, 2KB JSON responses, wrk from separate VPS on same private network. All 6 optimizations (connection pooling, gzip, keep-alive, proxy buffering, Redis caching, query optimization) applied.

How I Tested

The API under test was a realistic Express.js application: 4 endpoints (list, detail, search, create), PostgreSQL backend with 2 million rows, authentication middleware, JSON validation, and structured error handling. Not a "hello world" — a representative production API.

• Load generator: wrk 4.2.0 running on a separate VPS from the same provider, connected via private network. 4 threads, connections ramped from 50 to 1000 in 100-connection increments, 60-second duration per step. k6 used for scenario-based tests (ramp up, steady state, spike, recovery).
• Metrics captured: Requests per second (throughput), latency distribution (p50, p90, p95, p99), error rate, CPU utilization, memory usage, I/O wait, and CPU steal time. All metrics recorded with sar at 1-second intervals during the test.
• Optimization progression: Each of the 6 optimizations was applied incrementally with a full 60-second benchmark after each change. The progression table above reflects real measured data, not theoretical improvements.
• Multiple runs: Each benchmark was repeated 3 times. The reported number is the median. Variance between runs was under 5% on dedicated CPU plans and up to 15% on shared plans (noisy neighbor effect).
• Database state: PostgreSQL was pre-warmed with pg_prewarm on all test tables. Redis was pre-populated with cached responses for the caching test. This eliminates cold-start variance and measures steady-state performance.

Hetzner won on raw throughput-per-dollar. Vultr won on geographic flexibility. DigitalOcean won on operational simplicity. Cherry Servers won on deterministic p99 latency. Kamatera won on vertical scaling flexibility. The right choice depends on which constraint your API faces today.

Frequently Asked Questions