Deep-dive guide
Serverless vs VPS Breakeven Simulator: Pay-Per-Request or Flat Server Price
Executive industry analysis
The choice between serverless and a plain virtual server is usually argued as ideology, but it is arithmetic. Serverless charges per request and per unit of compute time, so cost starts at zero and rises with every call. A VPS charges a flat monthly price whether it is idle or busy, so it costs something from the first day and then stays the same until it runs out of capacity. The two lines cross at some request volume, and which side of that point you are on decides the bill by an order of magnitude at the extremes.
What makes the comparison tricky is that the cheap line is not the whole story. Serverless bills are made of several parts: invocations, memory-time, an API gateway in front, and logs that grow with traffic. The VPS bill looks small, but the server needs patching, backups, monitoring and someone awake when it fails. That time is real, and for a small team it is often the most expensive input. A fair breakeven therefore includes both the cloud invoice and the value of the hours spent operating the server.
The domino model follows the cost from load to profit. Requests per month and execution time define the workload. Together with the price rules they give a cost per million requests, which becomes the infrastructure bill. Operations time is added, and the total is compared with revenue. Execution time is the quiet driver, because it multiplies the serverless compute charge and also reduces how many requests one VPS can serve. Halving it can move the breakeven point very far.
The iceberg shows what the main line leaves out. Visible are the invocation and compute charges, or the VPS instances. Below the waterline sit the API gateway fees that are often larger than the functions themselves, log ingestion that grows with every request, the ops hours priced at what your time is worth, and revenue lost when cold starts make some users wait. Use the simulator to enter your own volume and execution time, then test moving traffic to a VPS to see the monthly difference.
Formula and methodology blueprint
The model is a single month. Serverless cost per million requests is the invocation price plus memory-time (half a gigabyte for the execution time), plus gateway and log charges. A VPS serves a number of million requests per month equal to a capacity constant divided by execution time, rounded up to whole instances, each with a backup charge. Operations time is 1.5 hours a month on serverless and 9 hours on a VPS, valued at your hourly rate. Cold starts cost a small share of revenue on serverless traffic.
- Serverless cost per million
- s = invoke + 0.5 GB × (ms ÷ 1000) × 10⁶ × GB-s price + gateway + logs
- What one million requests cost on a pay-per-use platform.
- VPS capacity
- Cap = 40,000 ÷ execution ms (million requests per instance)
- How much traffic one instance can serve in a month, falling as requests get slower.
- VPS bill
- V = ceil(VPS traffic ÷ Cap) × (price + backup)
- Instances needed, rounded up, times the flat monthly price.
- Breakeven volume
- M* = (VPS price + backup + extra ops hours × rate) ÷ s
- Million requests per month at which serverless costs the same as one VPS and its extra operations time.
- Net profit
- Net = revenue − serverless bill − VPS bill − ops − cold-start loss
- The monthly result. The breaking point is where it reaches zero.
Cascading elasticity
Requests per month and execution time are the most elastic inputs on serverless, because the bill is linear in both. On a VPS the cost is flat until an instance fills, so the effect shows up as steps. Your ops rate matters most at low volume, where the VPS bill is small and your time dominates.
Three real-world case studies
Bootstrapped starter
A side project with light traffic
A small project serves fifteen million requests a month with short functions. Serverless costs a few dollars, and a VPS plus maintenance time would cost more. Loading it shows why serverless wins at small scale and why the free tier is such a strong start.
Scaling mid-market
A steady product with high volume
A product with strong revenue serves hundreds of millions of short requests. The serverless bill is noticeable but the revenue absorbs it. Loading it shows the margin in absolute terms and why testing the VPS switch pays off here.
Black-swan crisis
A slow API at huge volume
An API with long execution times serves close to two billion requests a month on serverless, while revenue stays flat. Compute, gateway and logs outgrow the income. Loading it shows the bill overtaking revenue and how a flat-price server restores the month.
Industry benchmark matrix
| Metric | Danger zone | Industry average | Top 10% elite |
|---|---|---|---|
| Monthly requests where a small VPS usually beats serverless | Above 500M on serverless | 50–300M | Hybrid: steady routes on VPS, spikes on serverless |
| Average function execution time | Above 800 ms | 100–300 ms | Under 100 ms |
| Infrastructure as share of revenue | Above 40% | 10–20% | Under 8% |
| Monthly ops hours on a small VPS setup | Above 20 h | 6–10 h | 2–4 h with automation |
| Gateway and log charges as share of the serverless bill | Above 60% | 30–50% | Under 25% |
Variables and levers
Requests per month (millions)
Total API or page requests your application handles in a month, counted in millions.
Lever: Cache responses at the edge and drop chatty polling, because every request avoided is a request you do not pay for on serverless.
Average execution time (ms)
How long one request takes to run. It drives both serverless compute charges and how many requests a VPS can serve.
Lever: Profile slow functions, reuse connections and trim dependencies; execution time multiplies the compute bill and shrinks VPS capacity.
Monthly revenue of the product
What the product earns each month, which the infrastructure and your time must be paid from.
Lever: Tie pricing to usage so that infrastructure cost scales with revenue rather than ahead of it.
VPS price per instance
Monthly price of one virtual server of the size you would run, before backups.
Lever: Compare providers and sizes, and use one larger instance with a snapshot plan instead of several small ones.
Value of an ops hour
What an hour of your own or your engineer's time is worth when it is spent on servers instead of the product.
Lever: Automate deploys, patching and backups with a small repeatable setup so server time stays near an hour or two a month.
Share of traffic on the VPS
Zero means everything runs serverless, 100 means everything runs on VPS. Used to test the switch.
Lever: Move only the steady, high-volume routes to a VPS and keep spiky or rarely used endpoints serverless.
How to use this simulator
- 1Start from the realistic preset or enter last month's requests, average execution time and revenue.
- 2Read the five domino boxes to see whether cost per million requests or ops time turns red first.
- 3Press Find my breaking point to see the request volume that wipes out profit on serverless.
- 4Compare the current setup with the all-VPS plan on the 24-month chart, or test a partial split with the traffic share slider.
- 5Measure real execution times and invoices for a month before you migrate anything.
Mistakes to avoid
- Comparing the VPS price with the function price alone and ignoring gateway, log and bandwidth charges on the serverless side.
- Valuing ops hours at zero, which makes a VPS look cheaper than it is for a team with other priorities.
- Assuming one VPS can handle any load, when slow requests and traffic peaks fill an instance quickly.
- Migrating the whole system at once, instead of moving the steady high-volume routes and keeping the rest serverless.
Frequently asked questions
Is serverless always more expensive at scale?
Often but not always. Bursty or unpredictable workloads can be cheaper on serverless even at scale, because a VPS must be sized for the peak. Steady, high-volume traffic usually favours flat-price servers.
Why does execution time matter so much?
Serverless compute is billed by memory-time, so doubling the run time roughly doubles that part of the bill. On a VPS it halves how many requests one instance can serve.
How should I price my own ops time?
Use what the same hour would earn if spent on the product, or your engineer's loaded hourly cost. If you enjoy the work and have no better use for the hour, you may use a lower value.
What about reliability and scaling on a VPS?
A single VPS is a single point of failure, so serious products add a second instance or a load balancer, which this model approximates through instance count. Check what your provider offers.
How do I find the volume where my profit breaks?
Press Find my breaking point. The tool moves each input towards its worse end and reports the value at which monthly profit reaches zero.
How accurate is this?
It is an educational model using illustrative list prices, not a quote or advice. Replace the constants with your provider's current prices and your measured execution times.
This is an educational planning model with stated assumptions. It is not financial, tax or legal advice. Replace the inputs with your own figures and verify important decisions with a qualified professional.