On this host, a 0.879 GiB corpus (2000 × 256 KiB files plus one 400 MiB blob) uploaded over loopback HTTP APIs with two workers. Nextcloud 31.0.9 WebDAV took 388.7 s (~2.32 MiB/s). Seafile CE 12.0.14 api2 took 60.3 s (~14.9 MiB/s). Linear scale of those rates to a 100 GiB first sync is about 12.3 hours for Nextcloud and 1.9 hours for Seafile. Small-file wall time alone was 387.2 s vs 57.5 s (~6.7×). During the Nextcloud run, stack CPU median sat near 169% of one core’s worth across containers; Seafile’s large-file phase sampled much quieter. Idle RAM favored Nextcloud here (~453 MiB vs ~675 MiB).
Sync is not the whole product. Nextcloud still wins if you want calendar, Talk, and the app ecosystem (Nextcloud PHP/RAM). Seafile wins when the job is “files, fast,” especially many small objects.
| Metric | Nextcloud 31.0.9 | Seafile CE 12.0.14 |
|---|---|---|
| Small upload (2000 files, 2 workers) | 387.2 s | 57.5 s |
| Large upload (400 MiB) | 1.5 s | 2.8 s |
| Total corpus | 388.7 s | 60.3 s |
| Throughput | ~2.32 MiB/s | ~14.9 MiB/s |
| 100 GiB scale (linear) | ~12.3 h | ~1.9 h |
| Idle stack RAM | ~453 MiB | ~675 MiB |
| CPU (lab) | med ~169% (full run) | quieter on large phase |
Method (so you can distrust us usefully)
| Piece | Choice |
|---|---|
| Corpus | 2000 × 256 KiB random + 1 × 400 MiB random (~0.879 GiB) |
| Nextcloud | nextcloud:31.0.9-apache + MariaDB 11.4 + Redis 7 · WebDAV PUT |
| Seafile | seafileltd/seafile-mc:12.0.14 + MariaDB + Memcached · /api2 upload-link |
| Parallelism | 2 workers |
| Network | Loopback on one machine (server overhead, not WAN) |
| 100 GiB | 100 GiB / measured_MiB_per_s → hours |
Not measured: official desktop clients, WAN latency, multi-user load, preview generators, or true block-delta re-sync after a 1% edit (Seafile’s usual marketing win). Disk du after Nextcloud included leftovers from an earlier oversized PUT attempt, so treat disk ratios as noisy; prefer wall time and CPU.
Nextcloud: WebDAV numbers
# PUT to /remote.php/dav/files/admin/… with basic auth
# 2000 small files @ 2 workers, then one 400 MiB PUT| Phase | Time |
|---|---|
| Small | 387.2 s |
| Large | 1.5 s |
| Total | 388.7 s |
Idle after quiet: ~453 MiB across app+DB+Redis. Large single-file PUT was fast on loopback; the tax is per-file HTTP/PHP for the small set.
Seafile: api2 numbers
# Token auth → upload-link per file → multipart POST
# Upload-link host rewritten to the published :8086 port| Phase | Time |
|---|---|
| Small | 57.5 s |
| Large | 2.8 s |
| Total | 60.3 s |
Idle ~675 MiB (Seafile container + MariaDB + Memcached). Slightly slower than Nextcloud on the single 400 MiB blob here; much faster on the 2000-file set even with an upload-link round trip per file inside the timer.
What “100 GB” means on these rates
| Stack | Measured | Scaled first sync of 100 GiB |
|---|---|---|
| Nextcloud | 2.32 MiB/s | ~12.3 hours |
| Seafile | 14.9 MiB/s | ~1.9 hours |
A home uplink slower than loopback will stretch both; the ratio is the planning takeaway. Incremental edits to large binaries are where Seafile’s block store usually widens the gap further. We did not re-bench delta sync on this pass.
When to pick which
| You care about… | Lean |
|---|---|
| Many small files / sync CPU | Seafile |
| Single large blob on a fat link | Either (NC edged large here) |
| Calendar, Talk, app store | Nextcloud |
| Lower idle RAM on this lab | Nextcloud |
| Suite on 2 GB with PHP tuning | Nextcloud post |
| Skip this | What this lab did |
|---|---|
| Trusting brochure LAN MB/s | Timed real HTTP APIs |
| Scaling without stating the formula | 100 GiB / MiB/s |
| Calling desktop sync “measured” | API-only, documented |
| Ignoring idle RAM | NC ~453 vs SF ~675 MiB |
| One-size “winner” | Split sync vs suite |
What other measured bake-offs keep finding
Independent 2026 sync labs that push the same generated datasets through Seafile CE and Nextcloud over HTTP APIs keep landing on the same pattern this post is about. Seafile tends to win on many small files and on downloads of those sets; Nextcloud is often competitive or ahead on a single large blob over loopback. Idle RAM for a quiet Seafile stack (app + MariaDB + Redis) often sits in the mid-hundreds of MiB, while a comparable Nextcloud file stack can idle lower until you enable the rest of the app ecosystem. Seafile’s own docs still ask for about 2 GB RAM and two cores; Nextcloud documents memory per PHP process (128 MB minimum, 512 MB recommended) times worker count, then add database and Redis. Block-level dedup is why Seafile re-sync of a lightly edited multi-gigabyte file stays cheap; Nextcloud’s unit of transfer is still closer to the whole file unless you lean on other tooling. Treat third-party absolute seconds as relative behaviour on their guest, and keep our lab’s CPU/disk figures as the numbers this page owns.
FAQ
Why not 100 GiB on disk? Host free space could not hold two full copies; the corpus is representative and the scale is linear on measured throughput.
WebDAV fair to Nextcloud? It is the integration path many tools use. Desktop clients may differ; they were out of scope.
Seafile Pro? CE only here. Pro features are a separate buy.
Compose? Minimal Apache Nextcloud + MariaDB/Redis; official seafile-mc with JWT .env, Memcached service name memcached, and client_max_body_size 0 for large PUTs.
What to run on the VPS
If sync of order 100 GB is the job, Seafile’s measured rate on this box points at a much shorter first load and lower sync CPU. If you need the Nextcloud suite, budget the longer small-file sync and follow the 2 GB PHP notes. Size a Compute Instance from idle RAM plus headroom for the sync CPU spike you actually expect, not from marketing MB/s.