SFTP vs. FTPS benchmarks: transfer protocol speed comparison
As a co-founder at SFTP To Go, I've often read the claim, "FTPS is faster than SFTP." But when I put this to the test, I discovered something surprising.
In this article, I'll walk you through our benchmarking results, exploring how region (latency), choice of client, and specific use cases influence actual transfer speeds. This data-driven look aims to clear up misconceptions, helping technical teams make smarter choices based on real performance benchmarks.
If you need a quick look at what sets these protocols apart (other than performance), start by reading our post on the differences between SFTP and FTPS—it makes for a great intro to this new data.
How I tested
Here’s how I structured the benchmarks.
- I created m7a.large EC2 instances running Ubuntu Server 24.04 in two AWS regions: us-east-1 (where our SFTP To Go endpoint was hosted) and eu-central-1.
- Our SFTP To Go endpoint remained fixed in us-east-1, while clients operated either in us-east-1 (same region, low-latency) or eu-central-1 (cross-region, high-latency).
- All tests were scripted end-to-end. This included:
- Generating random files of various sizes and quantities for each scenario. (Random files were deliberately chosen because they don't compress well, unlike structured files like CSV or JSON.)
- Executing CLI-based upload/download commands using both curl and LFTP, against both SFTP and FTPS.
- Capturing the total transfer time per test.
- As SFTP/FTPS clients, I selected curl and LFTP because both are CLI tools that allow fully scriptable, protocol-agnostic transfers via both SFTP and FTPS.
- Both clients were tuned for fairness: Each test reused a single connection for the entire session (upload or download of multiple files), rather than connecting/disconnecting per file. I also disabled additional FTPS commands that some clients issue after file uploads, such as setting timestamps or changing file ownership, to ensure the transfer time reflected only the transfer itself.
- I transferred various file sizes, from small 100KB files (like CSV files or tiny images) to larger, 100MB files (such as database backups or video files).
- I directly compared the performance (upload and download time) of FTPS vs. SFTP, both using our managed cloud transfer solution, SFTP To Go as the server endpoint.
- I ran each scenario multiple times and observed some natural variance in transfer times. The figures presented here reflect average run times; averages and spreads were reviewed in the analysis phase.
- I opted for serial processes (i.e. upload one file after the other, or download one file after the other) rather than parallel downloads and uploads. design choice ensured comparability.
- All analysis was performed in Google Sheets using raw output metrics.
Curl: Same-region tests (us-east-1) to establish SFTP / FTPS performance baseline
I began by focusing on transfers (uploads and downloads) within a single region (us-east-1), using curl as the client for both SFTP and FTPS. Since curl is pre-installed on most Linux distributions and it allows to (relatively) easily automate transfers using multiple protocols, this was our go-to test client. This gave us a clean baseline for comparing protocols under low-latency conditions. From here, I could isolate the effects of file size and file count without the added noise of network latency.
Step 1: A batch of small files (100 x 100KB = 10MB)
I first transferred (uploaded, downloaded) 100 small files (100KB each). These are the kinds of files you’d see in log exports or microservice reports or even small images, CSV or PDF files.
SFTP clearly outperformed FTPS across the board (lower is better), completing the transfer in less than half the time. The overhead per file, especially under FTPS, added up fast.
Step 2: Single large files(1 × 100MB)
I next tested for single large files: a 100MB file transferred in one go - simulating the upload of a large archive, short HD video, or a database dump.
With just one file and no batch overhead, FTPS completed both upload and download much faster than SFTP, with 3x difference in upload times and 5x difference in download times!
Step 3: Same volume, more files, smaller files (100 × 1MB = 100MB)
Next, sticking with the total volume of 100MB, I returned to batching, dividing that volume between 100 x 1MB files.
Interestingly, FTPS overtook SFTP again, but only on download speed, while SFTP took the lead on upload. What’s changing the dynamic? Is it the transfer direction, number of files (since the volume is the same as the last test, where FTPS won across the board), client behaviour, or (more likely) a combination of these factors? Let’s do more tests and find out!
Step 4: Same volume, mid-sized files (5 × 20MB and 10 × 10MB = 100MB)
Next, I ran two batch tests with the same 100MB transfer volume but with fewer, larger files: one with 5 files at 20MB each, and another with 10 files at 10MB each.
FTPS pulled ahead, and the fewer the files, the bigger the advantage. Interestingly, while FTPS performance varied with the number and size of files, SFTP performed pretty much the same in both tests. This reinforced the idea that FTPS performance is affected by the number of files and size of files.
It seems like, so far FTPS favors fewer and bigger, while SFTP favors more and smaller.
The following chart shows the results from all 100MB test runs:
It’s clear that FTPS’s performance consistently improves as the number of files decreases. This confirmed that file count heavily influences FTPS performance.
On downloads, FTPS had only a slight lead for the higher-count batch, but this lead increased significantly for the 20-file batch. FTPS thrives with fewer files, while SFTP shows more consistency throughout, even taking the lead on higher file-count uploads, but not handling single, large files as efficiently as FTPS.
In the next few tests, I wanted to check whether it’s the file size or file count that makes the most difference so I’ve kept the number of files constant at 100 files, and changed the file sizes.
Step 5: Same file counts, different file sizes (100 x 1MB, 5MB, 10MB, and 100MB)
To test how each protocol handles increasing batch volume at a fixed file count, I ran a new series of transfers where each batch contained 100 files, but with file sizes ranging from 1MB to 100MB.
The first batch (100 x 1MB files) was pretty balanced, as was clear on prior tests. While FTPS had a 20% download advantage, SFTP had a 30% upload advantage, but in absolute numbers, they were reasonably close in performance.
Performance gaps widened significantly with larger files. SFTP's download time was nearly 6x slower than FTPS at 100MB per file, and uploads were over 4x slower. This suggests that FTPS handles large file transfers more efficiently in this setup.
Curl same-region results, SFTP vs. FTPS: what I’ve learned
After running various same-region test rounds with curl, a few things were clear. SFTP was great at handling batches of small files, especially for uploads. But as I shifted to fewer, bigger files—or just more data overall—FTPS started pulling ahead, particularly on downloads.
The differences weren’t always huge at first, but they grew as volume increased. In the largest tests, FTPS was way faster across the board. SFTP just didn’t keep up when things got heavy.
That said, all of this happened under ideal, low-latency conditions. I wanted to check what happens when we add distance and latency into the mix. Time to move the client to Europe and see how things change.
Curl: Cross-region tests (eu-central-1 client to us-east-1 hosted SFTP To Go) to measure the effects of latency
Now that I’d established a same-region performance baseline, I turned to cross-region testing. With the client now running in eu-central-1 and the service endpoint still in us-east-1, I could measure the impact of latency on file transfer performance over SFTP and FTPS.
This next round of tests used curl again, with the same file sizes and batch structures as in the previous section. Here's what I found:
Step 6: Small batch, high file count, cross-region (100 files × 100KB = 10MB total)
Even over distance, SFTP handled this batch more efficiently. Download took over x2 faster with SFTP versus FTPS. SFTP also won the Upload test, but with a mere x1.3 gain.
Step 7: Larger batch volume, fewer and larger files, cross-region (100MB total per test)
Once I shifted toward fewer, larger files—still totaling 100MB—FTPS consistently gained an edge. That advantage was especially strong on upload.
The most dramatic gap appeared in the single 100MB file test, where FTPS completed the upload x42(!!) times faster than SFTP. Similar patterns held for 10 × 10MB and 20 × 5MB batches, where FTPS remained ahead across both directions.
One interesting result: when transferring 100 × 1MB files, SFTP came out ahead on download, even across regions. But that edge didn’t extend to upload times, where it still fell behind. In general, FTPS performance degraded in a predictable way as latency and payload increased. SFTP, while averaging slower on this round, showed much more consistency across the board.
I found it a little concerning that there were such major differences between the two protocols, so I decided to test with another client to see if I can reproduce the same results.
LFTP: Same-region tests (us-east-1) testing the effects of client behavior
Step 8: Small file batch (100 × 100KB) across clients and protocols
To see how much client choice influenced results, I ran the same 100 × 100KB batch transferI previously ran with curl, but now with LFTP. The goal here was to isolate the effect of the client while keeping the client machine, server endpoint, protocols, file size, and file count constant.
In this small-batch test, SFTP behaved similarly across both clients: LFTP was slightly slower on download but a bit faster on upload. FTPS, on the other hand, saw a more noticeable drop in download performance with LFTP.
Step 9: Single large file (1 × 100MB) across clients and protocols
Next, I ran single 100MB file tests with LFTP using both protocols, to compare with the tests performed in step 2 using curl.
The differences were dramatic:
LFTP’s SFTP download was almost 4x faster than curl’s! With LFTP, FTPS download times were a lot closer to SFTP (8.23 : 8:98, vs. curl’s 6.54: 35.34). For uploads, the shift was not quite as pronounced, but still impressive: LFTP was 2.4x faster than Curl with SFTP, and 1.6x slower with FTPS - again bringing the execution times closer together.
It seems like client choice impacts performance significantly. I decided not to dive too deep into implementation differences and continue the benchmarks, with the key takeaway that the client of choice (or programming library) makes a difference.
Step 10: LFTP on smaller batches (1–20 files, 100MB total)
I continued to run the same tests I ran previously with curl - with the same total number of bytes, spread over multiple files, but now with LFTP.
SFTP consistently outperformed FTPS on upload, and by a modest margin on download as well with multiple files.
This was a notable shift from earlier curl results, where FTPS often led when file counts were low, shown below for reference.
Step 11: LFTP with same file counts, different file sizes (100 x 1MB, 5MB, 10MB, and 100MB)
In most of these tests, SFTP beat FTPS. At 100 files × 1MB, for example, SFTP cut total transfer time nearly in half compared to FTPS. The pattern was stable through to the 5MB batch. As file size per item increased to 10MB, the gap narrowed. In the 100 × 10MB batch, FTPS briefly pulled ahead on download, though SFTP still won on upload.
Finally, with the 100MB files, FTPS showed a clear advantage in download while SFTP still performed better with uploads.
LFTP: Cross-region tests (eu-central-1 client to us-east-1 hosted SFTP To Go)
Using the same EU instance as before, I now ran the exact same tests using LFTP to compare client performance in a high latency environment:
Step 12: LFTP on small-file batches (100 files × 100KB = 10MB total)
SFTP held up remarkably well here, especially on upload. It completed the upload batch in under a third of the time it took FTPS. Even on download, SFTP maintained a healthy lead, and performed over 2x better than curl in upload.
This echoed results from previous small-batch tests: high file count + small files favors SFTP, across both clients and regions.
Step 13: LFTP vs. curl on single large files (1 file × 100MB, cross-region)
Revisiting the 1 × 100MB file transfer from the EU client region using curl and comparing to LFTP:
SFTP was way more efficient with LFTP than with Curl. It didn’t perform as well as FTPS (and FTPS on LFTP didn’t perform as well as FTPS with curl), but the difference between protocols when using LFTP wasn’t as evident.
Step 14: LFTP on same volume, more files (100MB per batch)
To continue with the LFTP cross-region testing, I ran a series of 100MB batch transfers using different file counts. Each configuration kept the total transfer size the same, while shifting the structure of the batch—from one large file to 100 small ones.
SFTP with LFTP was way more efficient than with curl. FTPS still performed better than SFTP with fewer, larger files, but not with the odd proportions curl showed. SFTP beat FTPS on download of 10 x 10MB files, and was consistently faster than FTPS in both upload and download of 20x5MB and 100x1MB files. Comparing this to the results I previously got with curl show quite a difference between the two clients:
LFTP cross-region results (FTPS vs. SFTP): What I’ve learned
The LFTP cross-region tests revealed something pretty important: protocol behavior isn’t set in stone. The client you use (and the conditions you test under) can completely flip your assumptions.
SFTP, which struggled with certain workloads when tested with curl, handled most scenarios far more gracefully under LFTP. That was especially true on uploads and in high file count situations, where SFTP proved both faster and more stable.
FTPS, while still strong in single-file cases, didn’t scale as efficiently. It often lost ground to SFTP as file counts rose, even when latency was in play.
The takeaway here isn’t just that SFTP can be faster, but rather that performance varies due to client implementation, file sizes and number of files. You usually can’t change the number or size of files you’re going to transfer, but you can probably fiddle with either protocol or client that you use and I recommend that you at least test and see what the effect is! We could also throw parallel transfers into the pile, but I figured it’s best to save something for later.
Practical advice from our SFTP performance benchmarks
After hundreds of transfers across clients, protocols, and regions, one thing’s clear: performance doesn’t follow a straight line. It bends with every variable: region, file size, file count, and the client itself.
So instead of hard rules, here’s what stood up to scrutiny:
- Don’t judge a protocol without testing your client. Curl and LFTP behaved differently enough to flip protocol outcomes in some cases, especially with SFTP. A “slow” protocol in one test sometimes became the faster one with a different client.
- Benchmarks without client diversity tell half the story. If we had stopped after curl testing, we’d have assumed SFTP was unusable for large transfers and that FTPS was always faster. But adding LFTP reversed or narrowed those gaps. Client behavior reshapes the performance curve more than most expect. Who knows what variance we’d see if we tested through 5 to 10 clients.
- Watch how each protocol scales. High volumes can overwhelm otherwise fast setups. On one 10GB batch scenario, SFTP’s performance dropped steeply, especially under curl. But with LFTP, it remained competitive longer.FTPS consistently benefited from reduced file count. The fewer the files, the faster it got. SFTP, in contrast, handled high file counts more gracefully, especially in same-region scenarios or with clients like LFTP. If your workflow pushes lots of small files, protocol behavior won’t look the same as it would with a single 100MB backup.
- Distance doesn’t degrade both protocols equally. Under latency, SFTP’s small-batch efficiency often held, but large-file uploads became slower. FTPS degraded at a slower pace and continued to favor fewer, larger files scenarios.
- Upload and download performance diverge. It’s not just about which protocol is faster overall; direction matters. In many tests, one protocol led on upload and lost on download. If your system primarily sends or receives, factor that in.
So, before committing to a protocol or diagnosing slowness, test in your real context. Measure. Compare. Your tooling, geography, and file patterns matter far more than protocol spec sheets suggest.
And so?
Most people pick a protocol based on reputation or what they’ve read on the internet. But reputation doesn’t move your data; your setup does. I ran these benchmarks with no concurrency, and no parallel transfers. I wanted to see how SFTP and FTPS actually behave under clean, repeatable conditions.
What I found was that both protocols have strengths. FTPS excels with fewer, larger files and maintains a more predictable curve as conditions shift. SFTP thrives in frequent, distributed workloads with high file counts, especially when paired with the right client. Likewise, FTPS with curl had much faster download times than FTPS with LFTP in cross-region, large-file tests. But neither protocol wins in every scenario.
The biggest takeaway? Performance is situational. And if you’re trying to fix or optimize a slow transfer, switching client/framework may have more impact than switching protocols.
Actual performance depends on context. Run the test. See the results. Choose what works for you, in the scenarios most appropriate for you.
