Docker Swarm vs Kubernetes: A Small Team Load Test Verdict

The question I get most often after my Swarm posts is some version of: should we just move to Kubernetes? It usually arrives right after a slow week, when someone has noticed that one container is pinned at its CPU limit and that Swarm will not add a second one on its own.

This post answers it for a small team, using the one piece of evidence I can stand behind: the load tests and the custom autoscaler I built while running a Java Spring Boot service on Docker Swarm during my thesis research. I quote those numbers only as my results, link the full write-ups, and take every statement about Kubernetes and Swarm behaviour from their official documentation. I did not benchmark Kubernetes, so there is no Swarm-versus-Kubernetes speed number here, on purpose.

What Swarm gave me, and the one thing it did not

Swarm mode is built into the Docker Engine. The official overview lists scaling, desired state reconciliation, rolling updates, load balancing, service discovery and multi-host networking as its headline features, and that was genuinely enough to run a multi-service platform. You declare how many tasks a service should have, and the manager adds or removes tasks until reality matches.

What the same page does not list is autoscaling. Scaling in Swarm means declaring a number, and the number changes only when something runs the scale command. In my case that something did not exist, so every service sat at a single replica and nobody knew where it would break. That gap, not any dislike of Swarm, is the honest reason the Kubernetes question came up.

What my load test said about adding replicas

Before arguing about orchestrators it is worth knowing what more replicas actually buy you. I ran a k6 load test against the busiest write endpoint of the service, with 10 virtual users for 120 seconds on every comparison, so each run was like for like.

In my load test, which I describe in full in the Swarm load testing post going from one replica to two cut p95 latency from 8.40 seconds to 4.50 seconds, but throughput only moved from 1.72 to 1.88 iterations per second. A single replica with PostgreSQL and connection pool tuning reached 2.27 iterations per second with a p95 of 3.65 seconds, and two tuned replicas did worse than that single tuned one, at 2.00 iterations per second and a p95 of 5.43 seconds. The cause was a row lock: every request updated the same row, so more replicas only meant more sessions waiting in line.

Autoscaling: my under-80-line daemon versus a declared HPA

Because Swarm has no autoscaler, I wrote one, and the custom autoscaler post has the full Bash. It polls CPU every 10 seconds, scales out after two consecutive samples above 70 percent, scales in after three below 30 percent, and then refuses to act again for a 90-second cooldown. In my staged load test it scaled from one replica to two at 52 seconds and suppressed a spurious 92 percent spike during the cooldown.

# Swarm: the whole scaling API is one imperative command.
# Something you write has to decide WHEN to run it (see the daemon post).
docker service scale my-stack_api=3

# Kubernetes: the decision loop is built in. You declare the target and
# the damping instead of writing the loop.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 1
  maxReplicas: 4
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70   # percent of the container's CPU REQUEST
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0      # react at once (the default)
    scaleDown:
      stabilizationWindowSeconds: 300    # wait before removing replicas

Kubernetes ships this loop. The official HPA documentation describes a control loop that runs every 15 seconds by default and computes the desired replica count as the current count multiplied by the ratio of the current metric to the target, rounded up. Scale-down is damped by a default 300-second stabilization window, scale-up has none, and changes within a default 10 percent tolerance are ignored. As I read the formula, HPA works toward one target value rather than my two thresholds of 70 and 30, so my asymmetry maps onto the behavior block instead. The price is its prerequisites: CPU metrics come from a separately installed Metrics Server, and a Pod without a CPU request has undefined utilization, so the autoscaler does nothing for it.

The comparison, without the marketing

This table keeps only differences that I can trace to the Docker or Kubernetes documentation, or to my own build. Where a cell describes my own work it says so.

Read the table as a ledger of what you must build or buy. Kubernetes makes the autoscaling and access control rows cheaper and the learning row more expensive. Swarm does the opposite.

Where Swarm stops being enough for a small team

I would not move because Kubernetes is the industry default. I would move when one of these is true, each of which the table or my own work backs up:

• You need to autoscale on signals beyond one CPU number, and you are tired of maintaining your own decision loop and its tests.
• More than a few people deploy into the same cluster and you need real separation between what each of them may touch.
• You cannot accept that losing manager quorum freezes all changes, and you would rather pay a provider to run the control plane.
• You depend on tooling that targets Kubernetes and has no Swarm equivalent.

The failure I would watch for is different. A CPU autoscaler, mine or HPA, keeps adding replicas for as long as CPU is the signal, and when the true limit is a row lock the extra replicas just queue. In my case the autoscaler would have converged on the same 2.27 iterations per second ceiling the tuning found. Moving orchestrators first would have cost weeks and left that number unchanged.

What I would do differently, and the limits of this evidence

My numbers come from one service, one endpoint and one staging database with a single hot row, and they are measurements of Swarm only. I have not run the same test under Kubernetes, so I cannot tell you Kubernetes is faster, slower or equal. The 70 and 30 thresholds, the streak counts and the 90-second cooldown are design choices I made for that service, not recommendations.

If I did it again I would profile the database before building any scaling logic, and I would use a CPU request based metric instead of raw docker stats from the start, so that a later move to HPA is a translation rather than a rewrite. I would also add a latency signal next to CPU, since CPU alone was blind to the lock.

Monday checklist

Choose Swarm or Kubernetes for what you must build or buy, never for what the benchmark said about replicas. My load test showed that replicas only help until a shared resource becomes the limit, and no orchestrator moves that limit. Fix the bottleneck, then pay for the autoscaling and access control you can name.

Related reading

• Docker Swarm orchestration for production
• Docker Compose vs Kubernetes for small teams
• Kubernetes HPA scale to zero for GPU queue workers