VPS vs Serverless

What is it? #

Serverless means running code without managing servers. You deploy a function; the platform runs it on demand and bills per invocation.

There are still servers. You do not see, patch or size them, which is the actual product.

The strengths are real: no maintenance, automatic scaling from zero to very high concurrency, and no cost when idle.

The constraints are equally real: execution time limits, cold starts, no local state, difficult long-lived connections, and a cost model that becomes expensive at sustained high volume.

Think of it like this #

Taxis versus owning a car.

Taxis are ideal for occasional trips — no parking, no insurance, no maintenance. If you drive four hours every day, owning is considerably cheaper, and you can keep your tools in the boot.

Simple example #

An image thumbnail generator that runs a few thousand times a day is ideal serverless work. A WebSocket chat server with constant connections is close to the worst fit.

Code #

                        Serverless                 VPS
maintenance             none                       yours
scaling                 automatic, to zero         manual or scripted
idle cost               nothing                    the full monthly price
cost at high volume     can be very expensive      flat and predictable
cold start              100ms to several seconds   none
max execution time      typically 15 minutes       unlimited
persistent connections  awkward or unsupported     natural
local state and disk    ephemeral only             full filesystem
background workers      via queues and triggers    ordinary processes
debugging               platform logs and traces   full shell access
vendor lock-in          moderate to high           low

Cold starts, concretely

A function that has not run recently must be initialised: container start,
runtime boot, dependency import, connection setup.

  interpreted, small dependencies   ~100-300ms
  large frameworks, many imports    1-3s
  JVM or heavy initialisation       several seconds

Mitigations: keep functions small, lazy-import, use provisioned concurrency
(which reintroduces an idle cost), or accept it for non-interactive work.

Cost crossover, roughly

Low, bursty traffic          serverless usually cheaper, often free
Steady moderate traffic      a small VPS is usually cheaper
High sustained traffic       a VPS is dramatically cheaper

The exact point depends on execution time and memory, but the shape is
consistent: pay-per-use wins when usage is low or spiky, and loses when
it is continuous.

A common hybrid

VPS or containers   the main application, database connections, WebSockets
serverless          image processing, scheduled jobs, webhooks, spiky
                    workloads, and anything that must scale instantly

Choosing one exclusively is rarely necessary.

How it works #

A serverless platform starts a container when a request arrives and keeps it warm briefly for subsequent requests. A request arriving after that window pays the cold start.

Database connections are the classic difficulty. Each concurrent function instance opens its own connection, so a traffic spike can exhaust the database connection limit — which is why connection poolers and HTTP-based database proxies exist for this model.

The execution time limit shapes what can be done in a single invocation. Anything longer must be split across invocations or moved to a different compute model.

No local state means no in-memory cache that survives, no local file storage, and no in-process scheduler. Everything that would have been local becomes an external service.

The cost model is per invocation and per gigabyte-second. At low volume that rounds to nothing; at sustained high volume it exceeds a dedicated machine by a wide margin, because you are paying a premium for elasticity you are not using.

Edge functions are a related model with tighter limits and lower latency, suited to redirects, authentication checks and lightweight personalisation close to the user.

Real-world use #

Serverless is excellent for glue: webhook handlers, scheduled tasks, image and video processing, and anything with unpredictable spikes.

It is a poor fit for WebSocket servers, long-running jobs, applications with heavy database connection use, and steady high-volume traffic.

The operational trade is different rather than absent. You stop patching servers and start managing cold starts, execution limits, distributed tracing and platform-specific configuration.

Lock-in deserves honest consideration. Functions themselves port reasonably; the surrounding platform services — triggers, queues, identity, storage — do not.

Many teams run a VPS or container platform for the core application and use serverless for the workloads that suit it. That combination is usually cheaper and simpler than forcing everything into one model.

Common mistakes #

• Running steady high-volume traffic on serverless and receiving a surprising bill.
• Exhausting database connections during a scaling spike.
• Assuming no maintenance means no operational work.
• Using serverless for WebSockets or jobs longer than the execution limit.
• Ignoring cold starts on user-facing, latency-sensitive endpoints.

Practice #

Take two workloads from a project you know: one spiky and short, one steady and long-running. For each, estimate monthly invocations and duration, compare the serverless cost with a small VPS, and state which model you would choose and why.