The serverless vs traditional server debate usually ends in a shrug: “it depends on your workload.” True, but useless. This guide replaces the shrug with numbers, thresholds and a scoring checklist you can run in ten minutes, so you leave with an actual architecture decision instead of another comparison table.
The short answer
If your compute sits idle most of the time, serverless is almost always cheaper and less work. If your compute is busy most of the time, an always-on server is almost always cheaper and more predictable. Everything else in this article is about the grey zone between those two statements. Full details on https://akamai.com.
| Signal in your project | Points to |
|---|---|
| Sustained CPU utilisation below roughly 15 to 20 percent | Serverless |
| Sustained CPU utilisation above roughly 40 percent, 24/7 | Traditional server |
| Traffic spikes of 10x or more with no warning | Serverless (or autoscaled containers) |
| Jobs that run longer than 15 minutes | Traditional server or containers |
| Hard p99 latency budget under 100 ms for every request | Traditional server (or edge runtimes) |
| No dedicated ops person on the team | Serverless |
| Heavy stateful connections (WebSockets, gRPC streams, long polling) | Traditional server |
Definitions, kept honest
What serverless actually means
Serverless does not mean there are no servers. It means you never provision, patch or scale them, and you pay per invocation and per unit of execution time rather than per hour of uptime. The practical family includes AWS Lambda, Google Cloud Run functions, Azure Functions, Cloudflare Workers, Vercel and Netlify functions, and increasingly serverless databases and queues.
Two properties define the model:
- Scale to zero. No traffic means no bill for compute.
- Per-request isolation. Each execution gets its own sandbox, which is why state does not survive reliably between calls.
What traditional server means in 2026
Nobody is racking hardware in a cupboard for a new SaaS. “Traditional server” today means an always-on compute unit you own the lifecycle of: a VPS, an EC2 or Compute Engine instance, a long-running container on ECS, Cloud Run with minimum instances set above zero, Fly.io machines, or a Kubernetes deployment. The billing clock runs whether or not anyone is using your app.
Cost compared with real scenarios
Published per-unit prices mislead because they ignore the glue. Below are four scenarios using representative public pricing. Verify current rates with your provider before committing, but the shape of these results is stable. An extended version exists for anyone curious.
Scenario 1: Early stage SaaS API
500,000 requests per month, 120 ms average duration, 512 MB memory.
- Serverless compute: 30,000 GB-seconds, roughly $0.50
- Request charges plus a managed HTTP gateway: roughly $0.60
- Total: about $1.10 per month, often zero inside the free tier
- Equivalent always-on setup: one small instance at $12 to $25, plus a load balancer at $16 to $22
Winner: serverless, by a factor of 20 or more. At this stage the server bill is almost entirely idle time.
Scenario 2: Mature, steady-traffic API
50,000,000 requests per month, 200 ms average duration, 1 GB memory, fairly flat traffic.
- Serverless compute: 10,000,000 GB-seconds, roughly $167
- Request charges: roughly $10
- Managed HTTP gateway: roughly $50
- Total: around $227 per month
- Equivalent always-on setup: two mid-size ARM instances at roughly $106 combined, plus a load balancer at about $20, total around $126
Winner: traditional server, by roughly 45 percent. And the gap widens with reserved or committed-use discounts, which can cut instance cost by 40 to 60 percent while serverless discounting options stay thinner.
Scenario 3: Cron-heavy back office app
2,000 scheduled executions per day, 30 seconds each, 512 MB.
- Serverless: about 900,000 GB-seconds per month, roughly $15, plus negligible request fees
- Always-on: one small instance at $12 to $25, plus a scheduler, plus patching and monitoring
Costs are close. Serverless wins on operational overhead: retries, per-job logs, concurrency isolation and alerting arrive for free. The caveat is the execution ceiling, covered below.
Scenario 4: High-traffic ecommerce with spikes
Baseline 3,000 requests per minute, with flash sale peaks at 60,000 requests per minute for 90 minutes, a few times per quarter. You can read more here.
Running always-on capacity sized for peak costs roughly 20x the baseline bill for the other 99 percent of the time. Running serverless for the full year costs more than baseline servers but absorbs peaks with no capacity planning. The winning answer here is neither pure option: always-on servers for baseline traffic, with serverless or autoscaled containers absorbing the overflow, plus aggressive CDN caching in front.
The hidden cost lines that decide real budgets
| Cost line | Serverless impact | Server impact |
|---|---|---|
| NAT gateway for private VPC access | Roughly $32 per month plus per-GB processing, frequently the single largest line on small serverless bills | Same charge, but amortised over far more traffic |
| Logging and tracing | High. Per-invocation structured logs can exceed compute cost at volume | Moderate, easy to sample or ship to self-hosted storage |
| API gateway or ingress | Per-request pricing that scales linearly and can rival compute | Flat load balancer fee |
| Engineering time | Lower for patching and scaling, higher for local testing and debugging distributed flows | Higher for OS updates, capacity planning, incident response |
| Egress bandwidth | Same per-GB rates, identical on both sides | Same, unless you pick a provider with generous bundled transfer |
Latency and cold starts
Cold starts are the most cited objection to serverless and the most commonly misquoted. Here is the realistic current picture.
| Runtime | Typical cold start | Warm invocation overhead |
|---|---|---|
| Edge isolate runtimes (V8 based) | Under 10 ms | Negligible |
| Node.js or Python function, small bundle | 150 to 400 ms | Under 10 ms |
| Node.js or Python inside a VPC with large dependencies | 400 ms to 1.2 s | Under 20 ms |
| JVM or .NET without snapshotting | 1 to 6 s | Under 10 ms |
| JVM with snapshot restore features | 200 to 600 ms | Under 10 ms |
| Always-on server, warm process | None | Under 5 ms |
How much do cold starts really matter?
At steady traffic, cold starts typically affect well under 1 percent of invocations, because containers stay warm and get reused. They matter disproportionately in three situations:
- Low and irregular traffic. A function invoked every 20 minutes is cold almost every time.
- Sudden scale-out. A 10x spike means hundreds of simultaneous cold starts, exactly when users are watching.
- Chained functions. Five sequential functions each with a 300 ms cold start produce a 1.5 second user-visible delay.
Mitigations, and what they cost you
- Provisioned or reserved concurrency: keeps instances warm, but you now pay hourly, which erodes the main financial argument for serverless.
- Minimum instances on container platforms: same trade-off, cleaner implementation.
- Trim the bundle: tree-shaking and lazy imports routinely cut cold starts by half. This is the cheapest win available.
- Move auth and routing to an edge runtime: keeps the hot path fast, lets heavier functions stay cold-tolerant.
Long-running jobs: the hard ceiling
This is where serverless stops being a preference and becomes a constraint. Major function platforms cap execution between 5 and 15 minutes depending on the service and trigger type, and edge runtimes impose far tighter CPU budgets.
Workloads that break the model:
- Video transcoding and large media processing
- Full database migrations or nightly ETL over tens of millions of rows
- Model training or heavy batch inference
- Monthly report generation across the entire customer base in one pass
- Persistent WebSocket or SSE connections held open for hours
You have three ways out, in order of preference:
- Chunk the work. Split one 3-hour job into 2,000 independent 5-second jobs behind a queue. This is often the best outcome regardless of architecture, because it gives you retries and parallelism.
- Use a workflow orchestrator. Step Functions, Durable Functions or Workflows coordinate many short executions into a long-running state machine.
- Use containers for that job only. Fargate tasks or a dedicated worker instance handle the heavy lifting while the API stays serverless.
If chunking is impossible because the job needs a large shared in-memory working set, stop evaluating serverless for that component. That is a server workload.
Database connection limits
The classic serverless failure is not cold starts, it is connection exhaustion. A Postgres instance with a 100 connection limit meets 500 concurrent function instances, each opening its own connection, and the database falls over during exactly the traffic spike serverless was supposed to handle gracefully.
| Approach | Connection behaviour | Trade-off |
|---|---|---|
| Traditional server with in-process pool | A handful of long-lived connections per instance, fully predictable | None, this is the model Postgres was designed for |
| Serverless plus managed proxy (RDS Proxy, Cloud SQL connector) | Multiplexes thousands of clients onto a small pool | Extra hourly cost and a few ms of added latency |
| Serverless plus PgBouncer in transaction mode | Very high client fan-in | Breaks prepared statements, session variables and some ORM features |
| HTTP or data API drivers (serverless-native Postgres and MySQL platforms) | Stateless, no connection pool to exhaust | Vendor-specific driver, limited support for interactive transactions |
| DynamoDB, Firestore and similar HTTP-first stores | No connection concept at all | Access patterns must be designed up front, joins are your problem |
Rule of thumb: if you are committed to a relational database on a traditional managed instance and you expect high concurrency, budget for a proxy from day one or accept that an always-on application tier is the simpler design.
Operational overhead, measured in hours
Ops cost is where serverless quietly earns back whatever it loses on the compute invoice. Rough monthly engineering hours for a small product team:
| Task | Serverless | Self-managed servers |
|---|---|---|
| OS patching and base image updates | 0 h | 2 to 6 h |
| Capacity planning and autoscaling tuning | 0 to 1 h | 2 to 8 h |
| Deployment pipeline maintenance | 1 to 3 h | 2 to 5 h |
| Local development and testing friction | 3 to 8 h | 1 to 2 h |
| Debugging distributed traces | 3 to 10 h | 1 to 4 h |
| Out-of-hours incidents | Low frequency, low control | Higher frequency, full control |
Notice the shape: serverless removes infrastructure work and adds cognitive and debugging work. Teams with one or two engineers and no ops specialist almost always come out ahead with serverless. Teams with an existing platform group often find servers cheaper because the ops cost is already paid.
Why some teams migrate off serverless
Public post-mortems from companies that moved back to servers tend to share the same four causes. Check yourself against them before committing:
- Chatty internal architecture. Splitting a monolith into dozens of functions that call each other adds network hops, serialisation and per-call charges. The fix is usually a modular monolith, not a different hosting model.
- Data transfer between steps. Passing large payloads through orchestration services or object storage between functions costs more than keeping the data in one process’s memory.
- Utilisation crossed the break-even line. Growth turned bursty traffic into steady traffic and nobody re-ran the maths.
- Latency floors. Gateway plus function plus proxy plus database adds up, and a 40 ms p99 target becomes unreachable.
None of these say serverless is bad. They say serverless was applied to a workload with the opposite profile.
The scoring checklist
Answer each question. Add the points shown. Positive totals favour serverless, negative totals favour an always-on server.
| # | Question | If yes |
|---|---|---|
| 1 | Is traffic idle or near idle for more than 12 hours of a typical day? | +3 |
| 2 | Do you see unpredictable spikes of 5x or more? | +3 |
| 3 | Is the team smaller than four engineers with no ops specialist? | +3 |
| 4 | Is the workload event driven (webhooks, queues, uploads, scheduled tasks)? | +2 |
| 5 | Are you using an HTTP-native or serverless-native database? | +2 |
| 6 | Is a 300 to 800 ms cold start acceptable on a small fraction of requests? | +2 |
| 7 | Does any single job need more than 15 minutes of continuous execution? | -4 |
| 8 | Is average CPU utilisation above 40 percent around the clock? | -4 |
| 9 | Do you need persistent connections (WebSockets, streaming, gRPC)? | -3 |
| 10 | Is your p99 latency budget below 100 ms end to end? | -3 |
| 11 | Do you need GPUs, specific kernels, or unusual system dependencies? | -3 |
| 12 | Do compliance rules require full control of the host or data residency guarantees? | -2 |
| 13 | Does your team already operate Kubernetes or a mature server platform? | -2 |
Reading your score
- +6 or higher: go serverless. Revisit when traffic becomes steady or the bill crosses the price of two mid-size instances.
- +1 to +5: serverless with planned escape hatches. Keep business logic framework-agnostic so it can be lifted into a container later.
- -1 to -5: hybrid. Always-on core, serverless for bursty or peripheral work.
- -6 or lower: use traditional servers or managed containers. Serverless will fight you on every constraint that matters.
Common project types mapped to an architecture
| Project type | Recommended architecture | Why, and what to watch |
|---|---|---|
| Early stage SaaS API (pre product-market fit) | Serverless functions plus a serverless Postgres | Near zero idle cost and zero ops. Re-evaluate once monthly compute passes roughly $300. |
| Mature SaaS API with steady enterprise traffic | Containers on an always-on autoscaling group, serverless only for webhooks and exports | Steady utilisation makes reserved capacity 40 to 60 percent cheaper and keeps p99 predictable. |
| Cron-heavy / batch app | Serverless functions plus a queue, with container tasks for jobs over 15 minutes | Per-job isolation, retries and logging come free. Chunk long jobs rather than fighting the timeout. |
| High-traffic ecommerce | Hybrid: CDN plus always-on baseline servers plus serverless overflow | Pure serverless is expensive at this volume, pure servers are wasteful between peaks. Cache aggressively, keep checkout on warm capacity. |
| Side project or MVP | Serverless, or one small VPS running everything | Either works. Choose serverless if you hate maintenance, choose a single VPS if you hate vendor lock-in and complexity. |
| Real-time app (chat, collaboration, multiplayer) | Always-on servers, optionally with edge durable-state primitives | Persistent connections and shared state are not a function-shaped problem. |
| Data or ML pipeline | Containers or managed batch compute, serverless for triggers and orchestration | Memory ceilings, GPU access and execution limits rule out functions for the heavy stages. |
| Internal tools and admin panels | Serverless | Used a few hours a day by a handful of people. Cold starts are irrelevant internally. |
How to keep the decision reversible
The smartest move is to make this choice cheap to change. Four practices do most of the work:
- Keep handlers thin. A function should parse input, call a plain service module, and format output. That service module runs equally well in a long-lived process.
- Depend on open protocols. SQS, Pub/Sub and similar queues have portable equivalents. Proprietary workflow DSLs do not.
- Containerise even your functions. Container image deployment for functions is supported on all major platforms and gives you a direct path to a container runtime later.
- Instrument cost per request from day one. Tag everything, then set a billing alert at the point where two reserved instances become cheaper. Most teams discover the crossover six months late.
FAQ
Why are some teams leaving serverless?
Mostly because their workload profile changed or never matched in the first place. The three recurring triggers are sustained high utilisation that makes per-millisecond billing expensive, over-decomposition into chatty functions that multiply network hops and charges, and latency targets that the gateway plus function plus proxy chain cannot meet. Teams that move back typically consolidate into a modular monolith on autoscaled containers and keep serverless for webhooks, cron and bursty side tasks.
What are the main downsides of serverless computing?
- Cold start latency on infrequent or sharply scaling traffic
- Execution time limits, generally 5 to 15 minutes
- Database connection pressure that forces a proxy or an HTTP-native database
- Harder local development, testing and distributed debugging
- Cost unpredictability at high and steady volume
- Stronger coupling to a specific cloud provider’s event and permission model
Is Kubernetes considered serverless?
No. Kubernetes is a container orchestrator that you provision, upgrade and scale yourself, which is the opposite of the serverless operating contract. You can run serverless-style platforms on top of it (Knative, OpenFaaS and similar) to give developers a scale-to-zero experience, but the platform team still owns nodes, upgrades and capacity. Managed node-less variants blur the line, though you still think in pods rather than invocations.
What is a “serverless server”?
It is a contradiction people use to describe the fact that serverless code still runs on physical servers, just ones you never see, provision or pay for while idle. The cloud provider keeps pooled capacity warm and places your code on it per request. The more useful modern meaning is a managed runtime that scales to zero, such as a container service with a minimum instance count of zero, which behaves like a server to your code and like serverless to your invoice.
Is serverless always cheaper than a traditional server?
No. Serverless is dramatically cheaper when utilisation is low and dramatically more expensive when utilisation is high and constant. The crossover for a typical web API sits somewhere between 15 and 30 percent sustained utilisation. Below that, pay per request. Above it, buy the machine and commit to a discount plan.
Can I mix both architectures in one product?
Yes, and most production systems at scale do. A standard pattern is always-on servers for the latency-sensitive core API, serverless for webhooks, scheduled jobs, image processing and overflow traffic, and a CDN in front of everything. Mixing is not a compromise, it is the mature answer to the serverless vs traditional server question.
Final take
Stop asking which architecture is better and start measuring two numbers: your sustained utilisation and your idle hours. Those two figures, combined with your longest job and your tightest latency budget, decide the answer in almost every case. Run the scoring checklist above, write the total in your architecture decision record, and set a calendar reminder to re-run it in six months. Workloads change. The right architecture changes with them.