Why SFTP uploads are slow (and how to speed them up)

When SFTP feels slow, the protocol is rarely the culprit. SFTP encryption overhead is small on modern CPUs; the slowness almost always comes from latency, transfer patterns, or distance. Here are the real causes and what to do about each.

1. Lots of small files

This is the most common cause. SFTP does a round-trip for each file (open, write, close), so 10,000 tiny files pay the latency cost 10,000 times. The bytes are trivial; the round-trips aren’t.

Fix: batch small files into an archive (tar/zip) and upload one large object, or use a client that pipelines and parallelises, like lftp:

lftp -u user, -e "mirror -R --parallel=8 ./localdir /incoming; bye" sftp://host

2. A single, serial transfer stream

The plain sftp client moves one file at a time on one stream. On a high-latency link, that leaves bandwidth on the table.

Fix: use parallel transfers (lftp --parallel, or multiple workers). Several streams fill a fat, high-latency pipe far better than one.

3. Distance to the server (latency)

Every round-trip is gated by the round-trip time between you and the server. A transfer to a region on the other side of the world will feel sluggish on small files no matter how much bandwidth you have.

Fix: connect to a gateway region close to where the data originates. With a gateway in front of cloud storage, picking a nearby endpoint cuts latency on every operation.

4. Bandwidth limits

Sometimes it really is the pipe: a constrained uplink, a shaped network, or contention.

Fix: check actual available bandwidth (not the headline figure), and schedule large bulk transfers for off-peak windows.

5. Large single files and multipart

Very large files take time simply because they’re large. A good object-storage gateway uploads them in multipart chunks, which is efficient, but a slow or lossy network will still drag a multi-gigabyte object out.

Fix: ensure a stable connection, use a client that resumes on failure so a dropped transfer doesn’t restart from zero, and parallelise where the file count allows.

6. SSH window / client tuning

Older clients or conservative SSH window sizes can cap throughput on long-fat networks.

Fix: use an up-to-date client; modern OpenSSH and lftp handle window sizing well.

What’s usually not the problem

• Encryption. SSH crypto is cheap on current hardware; it’s not why your upload is slow.
• The gateway translating to object storage. The per-operation overhead is small; the dominant cost is still round-trips and distance.

The quick diagnosis

If small files are slow but a single large file flies, you have a round-trip/latency problem, batch or parallelise. If even one large file is slow, you have a bandwidth or distance problem, check the pipe and pick a closer region. Either way, the fix is about transfer pattern and proximity, not the protocol. To run SFTP close to your cloud storage, see SFTP to S3.