We keep running into the same question: should we host our services on serverless or traditional servers? This post breaks down the differences and helps you decide based on actual use cases.
A lot of newer developers start with frameworks like Next.js and deploy on Vercel without ever thinking about infrastructure. They define endpoints in the api folder and everything just works. That’s the experience Vercel offers—and it’s genuinely great. But that convenience can be misleading. It doesn’t mean serverless is the right fit for every kind of backend.
If you go all-in on serverless without understanding where it works best, you’re likely to run into unexpected costs and limitations.
That said, this isn’t a “which one is better” comparison. The goal is to clarify when to use serverless and when traditional servers make more sense.
What is a traditional server
A traditional server is just a machine, like your laptop, a PC, or a virtual machine such as an AWS EC2 instance. You install an operating system, add any libraries or runtimes your application needs such as node js for node application, and run your application as a long-lived process that listens for requests.
You are responsible for everything:
- Server configuration
- How your application runs
- Scaling and resource management
If you deploy a REST API this way, it runs as a persistent service that stays active and handles requests as they arrive.
What is serverless
Serverless takes a different approach. Instead of managing a machine, you deploy functions that run in response to requests. The platform handles the underlying infrastructure and execution, so you can focus on writing code, You can just deploy a node js endpoint and you don't even need to install or manage anything isn't that a great experience?
Each request triggers a function:
- Request comes in
- A function instance starts
- Your code runs
- A response is returned
Unlike traditional servers, these functions are not long-lived. They start when needed and stop after the request is handled.
Scaling is handled automatically by running multiple function instances as traffic increases, without requiring you to manage capacity.
Then why not deploy everything on serverless?
No approach is perfect. Serverless looks ideal on paper: no servers to manage, automatic scaling, and pay-per-use pricing. The trade-offs become clearer once you move beyond simple use cases.
1. Cold starts
Functions are not always running. If a function hasn’t been invoked recently, it needs to start before handling the request. This introduces latency, which can be noticeable for user-facing APIs.
2. Stateless by design
Each invocation is isolated, You cannot rely on in-memory state between requests. Any shared state must live outside the function, such as in a database, cache, or object storage. This changes how systems need to be designed.
3. Database connection issues at scale
If 1,000 requests hit your system:
- A traditional server can reuse a small pool of connections
- Serverless functions may attempt to open many connections in parallel
Without proper handling, such as connection pooling or proxies, this can overwhelm your database or significantly increase costs.
4. Execution limits
Serverless functions are not designed for long-running workloads and have execution time limits. Tasks that require continuous processing or extended compute time are not a natural fit for this model.
5. Cost can go both ways
Serverless is highly cost-efficient for low or unpredictable traffic. The pay-per-invocation model makes it attractive early on. Even at scale, compute costs for functions can remain reasonable.
However, costs are not limited to function execution. They also include:
- longer execution durations
- sustained high traffic
- external services such as databases, caching, and bandwidth
Traditional servers follow a different model. You pay for uptime, regardless of usage.
The difference is not that one is cheaper than the other, but how costs scale:
- serverless scales with usage
- servers are priced based on capacity
The right choice depends on how your traffic behaves.
So when should you use what?
Use a traditional server if:
- Your application runs continuously
- You rely on persistent connections or in-memory caching
- Traffic is steady and predictable
- You want full control over the environment
Use serverless if:
- Traffic is unpredictable or bursty
- You are building event-driven systems such as webhooks or background jobs
- You want minimal operational overhead
- You need to move quickly without managing infrastructure
The practical approach
Most real-world systems don’t fit neatly into a single model—the real mistake is treating it like a binary choice. In practice, effective systems are built by applying the right approach to each component.
Serverless can be the core API
For many workloads, serverless is a strong default. This is especially true when traffic is unpredictable or distributed. A public API, checkout flow, or internal service often does not justify a continuously running server.
In these cases, serverless provides:
- automatic scaling
- no capacity planning
- lower operational overhead
- usage-based pricing
Traditional servers still have a place
Some workloads benefit from a continuously running process like:
- APIs with sustained high traffic
- services that rely on persistent connections
- workloads that depend on in-memory caching
- long-running or compute-heavy operations
These cases are not impossible with serverless, but the model becomes less natural as complexity increases.
Serverless is well-suited for background work
Serverless works particularly well for tasks that run on demand and do not need to stay active.
Examples include:
- cron jobs
- scheduled cleanups
- webhook handling
- event-driven background jobs
These workloads benefit from a model where execution starts, completes, and then stops.
Conclusion
At this point you should have a clear idea of when to use what. Picking the right model for a workload matters more than people think, running a simple ping cron on an EC2 instance will cost significantly more than the same job on Lambda.