Nextcloud Test 2026: A Hands-On Review With Our Own Measurements

Most of what passes for a Nextcloud test online is a feature list: files, calendar, contacts, video chat, office — tick, tick, tick, done. The problem is that every one of those ticks remains true even when the installation is miserable to use. Features say nothing about how the software feels with 26,000 files in it, when a major version upgrade is due, or when you upload 500 small files.

So for this Nextcloud test we did not read a brochure. We built an instance and used it. On 20 August 2026, deliberately starting on Nextcloud 33.0.8 so we could actually perform and time the upgrade to 34.0.3 rather than describe it.

The most important result first, because it concerns the one practical decision almost everybody gets wrong when moving to their own cloud:

The same 2,000 files went in at 3.6 files per second over WebDAV and 953 files per second via occ files:scan. That is a factor of 265 — for an identical end state in the database.

Upload 50,000 holiday photos through the desktop client and you wait almost four hours. Copy the same files onto the server and run one scan and you are done in a minute. Both routes produce exactly the same state — we verified that in the database.

Nextcloud test: the setup

So the numbers can be placed in context, here is the test rig. Everything ran on a server with AMD EPYC cores and plenty of RAM, which means these measurements are best-case. On a small single-core VPS the times get worse, never better.

The configuration is deliberately close to stock: Redis and APCu came preconfigured with the official image, and nothing else was tuned. We wanted to know what somebody gets by following the standard instructions — not what is achievable after three days of optimisation.

Installation: uneventful, and that is a compliment

Installation is the part most experience reports describe at greatest length, and honestly the most boring one. Container started, short wait, done. No manual steps, no error messages, no manual database setup.

After the first start we had:

• 857 MB of program code on disk
• 60 MB data directory (without a single file of our own)
• 5.73 MB database across 126 tables
• 47 apps enabled out of the box

Those 47 apps are the first honest finding. A fresh Nextcloud is not a file store, it is a groupware suite complete with dashboard, activity stream, comments, voice message support and weather status. That is more than most people need — and every one of those apps runs on every single request.

Performance with many files: where exactly it tips

The most common worry before switching is: “does it get slow when there is a lot in it?” So we created four folders holding 100, 1,000, 5,000 and 20,000 files (26,164 in total including the rest) and measured the folder listing — once lean, once with exactly the property set the web interface actually requests.

Method: WebDAV PROPFIND with Depth: 1, one warm-up run, then 5 (lean) resp. 3 (full property set) measurements, mean value. Nextcloud 33.0.8, 20 Aug 2026. “As web UI” additionally requests fileid, permissions, size, has-preview, share-types, favorite, owner-id and more.

Two things sit in that table which never appear in feature lists.

First: up to 1,000 files essentially nothing happens. The difference between 100 and 1,000 files is 21 milliseconds — that is noise. Anyone testing their instance with a few hundred files is not measuring scaling at all.

Second: the full property set gets genuinely expensive beyond 5,000 files. At 20,000 files it is 1,543 instead of 927 milliseconds — a 66 per cent surcharge purely because the interface also asks about preview availability, sharing status and favourite markers. Measure with WebDAV tooling and infer the browser experience from it, and you will underestimate it systematically.

The base latency is the real story

To understand where those times come from, we measured against an empty folder:

Method: same PROPFIND procedure, plus a direct GET on /core/img/logo/logo.svg, which Apache serves without PHP. Nextcloud 34.0.3, 20 Aug 2026.

This is the heart of the whole test: an empty folder listing costs 243 milliseconds. A static file from the same server costs 1.9 milliseconds. A factor of 128 before a single file is involved.

That base charge applies to every request, because every request means a full PHP run with 47 loaded apps. File count is added on top. And from exactly that follows the most important finding of this test.

Sync speed: the factor that ruins migrations

We uploaded the same amount of data — 10 MB — two different ways:

Method: WebDAV PUT via curl inside the container (no network path), identical data volume, Nextcloud 33.0.8, 20 Aug 2026. The many-small-files figure comes from a single curl process using a persistent connection.

The same 10 megabytes take 0.4 seconds as one file and 133.6 seconds as 500 files — a factor of 334.

That is not a Nextcloud weakness in the narrow sense, it is the arithmetic from above: 500 files × roughly 310 milliseconds of PHP base cost per request ≈ 155 seconds. The data volume is almost irrelevant; the number of requests is everything.

The measurement error that nearly gave us a wrong number

The first run started a separate curl process per file and produced 3.2 files per second. Suspicion: that measures process startup, not the server.

So we ran the counter-test with one curl process and a persistent connection: 3.7 files per second. The difference is 15 per cent — connection reuse helps, but barely. The bottleneck is clearly in the server, not the client. Without that counter-test the article would have carried a plausible but unproven attribution of cause.

Parallelism helps, and cleanly so

Desktop clients do not upload serially, they use several connections at once. So we transferred 300 files with 1, 4 and 8 parallel streams:

Method: 300 files of 20 KB each, split evenly across n curl processes, each with a persistent connection, inside the container. Nextcloud 34.0.3, 20 Aug 2026.

The scaling is almost linear — a clear sign that CPU cores are the limiting factor here, not a lock in the database. That matches what we measured during the upload: the app container drew 84 per cent CPU, with MariaDB and Redis together under 16 per cent.

Practical consequence: on a single-core VPS, parallelism buys you little, because that one core is already saturated by a single stream. If you sync many small files, buy cores, not bandwidth.

The factor of 265: how to migrate properly

Now the finding that makes this Nextcloud test most useful in practice. We wrote 2,000 files directly into the data directory and then let Nextcloud index them once:

Method: 2,000 files of 20 KB each written directly to /var/www/html/data/admin/files/scan_bulk, then occ files:scan --path=.... WebDAV figure extrapolated from the serial measurement (2,000 ÷ 3.6). Nextcloud 34.0.3, 20 Aug 2026.

A factor of 265 against the serial WebDAV upload — and still a factor of 33 against eight parallel connections.

That sounds like a trick with a catch. So we checked in the database: are the entries equivalent?

Method: direct query against oc_filecache, filtered by path. Nextcloud 34.0.3, 20 Aug 2026.

No difference. Both routes produce complete database entries with size and mimetype. The files:scan route is not the inferior variant — it is the same state, 265 times faster.

For an initial migration that means concretely: do not push existing data through the desktop client. Place it into the data directory with rsync or scp, set ownership to the web server user, and run occ files:scan once. With 50,000 files that is the difference between an afternoon and a minute.

Important: this applies to the initial load. In day-to-day operation WebDAV is the right route, because only it carries shares, versioning and activities along correctly.

Upgrading 33 to 34: the part everybody fears

Major version upgrades are the most cited reason not to run Nextcloud yourself. So we did one — with 27,184 files and 50 apps in place.

First the backup, in maintenance mode:

Maintenance mode on, database dump, maintenance mode off: 1.10 seconds of total downtime. The dump was 5.6 MB.

That is an inconvenient number for the “backups make self-hosting so laborious” argument. On a small instance they are technically almost free.

Then the upgrade itself — swap the image, restart the container, Nextcloud does the rest by itself:

Method: docker compose up -d after the image change, then polling status.php every 5 seconds until installed:true, maintenance:false and needsDbUpgrade:false were all true simultaneously. 20 Aug 2026.

27.6 seconds, zero manual steps, not one disabled app. The upgrade visibly migrated all bundled apps to new versions and then ran an integrity check.

And performance afterwards? Identical:

Method: identical PROPFIND procedure before and after the upgrade, same data, same host. Deviations of 4–9 % are within measurement scatter.

No improvement, no regression. For a major version upgrade, “nothing changed” is the best possible outcome.

The caveat that belongs with it

Before this turns into “upgrades are harmless” — three honest limits of our test:

1. We jumped one version, 33 → 34. Nextcloud does not permit skipping multiple major versions; wait two years and you must upgrade several times in sequence.
2. We had no third-party store app installed when the upgrade ran. Those are, in experience, exactly the problem — numbers on that below.
3. Docker makes this easier than a manual installation. The image ships the matching PHP version. Install directly on the server and the PHP upgrade path becomes its own risk.

Where it grates: three things that genuinely got in the way

A hands-on test that finds only good things was not a test. Three points really slowed us down.

1. occ setupchecks hangs

The command that produces the admin warnings ran for minutes without a result and had to be killed. The log showed why: for the WebDAV check, Nextcloud calls itself over the configured address — and received 401, over and over, identifying as its own Nextcloud-Server-Crawler/34.0.3.

It is an instructive case: the check meant to tell you whether the installation is correctly reachable itself requires a correctly reachable installation. In a test environment without a clean third-party name, it blocks. No data lost, but a quarter of an hour gone.

2. The shipped state is not the recommended state

After installation, several values were simply not set that Nextcloud later nags about in the admin interface:

Method: occ config:list system on the freshly installed instance, Nextcloud 34.0.3, 20 Aug 2026.

The official Docker image takes caching off your hands — that is more than many guides suggest. But the remaining points stay manual. preview_max_x/preview_max_y especially: without those values Nextcloud generates previews at full resolution. We measured what that means in our article on Nextcloud costs — 85 per cent of preview storage can be saved with two configuration lines.

3. The program code grows faster than the data

Method: du -sm inside the container, table sizes via information_schema. 20 Aug 2026.

Talk alone brings 199 MB of code and 22 additional tables. Anyone planning a “lean file store” should know that a typical Nextcloud with a few apps quickly passes a gigabyte of program code — regardless of how many of your own files are in it.

The app store: the number to know before deciding

Nextcloud’s biggest selling point is extensibility. So we evaluated the complete app store — not the marketing page, the API.

Method: apps.nextcloud.com/api/v1/apps.json (31 MB) and .../platform/34.0.3/apps.json retrieved and counted on 20 Aug 2026.

Just under half of the app store does not work with the current Nextcloud version. And the view by last stable release makes it sharper:

Method: for each app the newest release without alpha/beta/rc/nightly in the version string, age calculated against 20 Aug 2026. Pre-releases were excluded, otherwise test uploads make a dead app look maintained.

Roughly 29 per cent of apps have had no stable release for over a year, or never had one. The active core is still large at 461 maintained apps — but the store figure of “753” describes a catalogue, not a selection.

The practical rule that follows is uncomfortable: every third-party app you install is an annual commitment. Nextcloud requires all apps to support the target version before an upgrade will proceed. A single abandoned app can pin an instance to an old version — and old versions receive no security updates.

Talk in the test: what actually works without an extra server

Installing Talk took 3.7 seconds and was entirely unremarkable. The interesting question is what is possible afterwards.

We did not take this from the product page but from the app’s source code. In lib/Config.php, getSignalingMode() decides as follows: if no signaling server is configured, SIGNALING_INTERNAL applies. On our fresh installation that was exactly the case — neither signaling_servers nor stun_servers were set.

Internal mode means peer-to-peer: every participant sends their video stream to every other participant. Bandwidth demand therefore does not rise linearly but multiplied by the participant count — with eight people, each client sends seven streams simultaneously.

This is the limit you need to know before procurement: without the High Performance Backend, Talk is intended for one-to-one and small group calls. A video conference with a whole department or school class needs the HPB — and that is part of the paid enterprise offering. We derived this in detail for the school context in Nextcloud for schools.

Put briefly: “Nextcloud is free” and “Nextcloud does video conferencing for 25 people” are two statements that do not hold at the same time.

Resource usage: pleasantly frugal

At idle, with 27,000 indexed files and 50 active apps:

Method: docker stats --no-stream, instance idle with no active users. Nextcloud 34.0.3, 20 Aug 2026.

Under load the picture shifts clearly in one direction: during the serial upload the app container drew 84 per cent CPU, MariaDB only 13 per cent, Redis just under 3 per cent.

Nextcloud is not a database-heavy application, it is a PHP-heavy one. For server selection that means a plan with lots of RAM and one core is the wrong shape. Cores are what count. Which plans price that how, we worked through with real figures in our Nextcloud hosting comparison.

Deleting, incidentally, was pleasingly fast: a folder with 500 files was in the trash in 0.40 seconds — where it continues to occupy space, something readily forgotten in storage planning.

What we did not test

To keep this Nextcloud test honest, the gaps stated explicitly:

• No desktop client, no mobile client. We measured over WebDAV, the same protocol the clients use — but not their conflict handling, selective sync logic or battery behaviour.
• No Collabora, no OnlyOffice. Both need their own service; that is a test in itself.
• No Talk video call with real participants. The statement about internal signaling comes from the source code and vendor documentation, not from a measurement with eight cameras.
• No long-term observation. One day of testing says nothing about database growth after two years, or the reliability of background jobs over months.
• No single-core VPS. Our figures are best-case on strong hardware. On small plans expect noticeably worse times.

An estimated number looks identical in a table to a measured one. So nothing appears here that we did not measure ourselves or substantiate from a primary source.

Verdict: who Nextcloud is worth it for — and who it is not

After a day of genuine operation the verdict is more differentiated than “good” or “bad” would allow.

Nextcloud convinces at:

• Upgrades. 27.6 seconds hands-off was considerably better than its reputation.
• Backups. 1.1 seconds of downtime for a consistent dump.
• Resources. Under 700 MB RAM at idle for a complete groupware suite.
• Large files. 24.7 MB/s is entirely sufficient.

Nextcloud disappoints at:

• Many small files. 3.6 files per second serially is a genuine everyday problem.
• Very large folders. Beyond 5,000 files the web interface becomes noticeably sluggish; at 20,000 it is 1.5 seconds.
• App store expectations. Only just over half is compatible with the current version.
• Self-diagnosis. occ setupchecks hung completely during the test.

Our recommendation, sorted by use case:

And the answer to the question behind every Nextcloud test — whether the effort pays off: operation is easier than its reputation suggests. Performance is worse than the feature list suggests. Know that before you start and you will rarely be disappointed.

Our own infrastructure runs on our own servers for exactly one reason: control, not cost. That self-hosting does not pay off financially on small installations is something we calculated ourselves in Nextcloud costs — even though it contradicts our own practice.

Frequently asked questions about the Nextcloud test

Is Nextcloud fast enough for daily use?

For normal folders with up to a few thousand files, yes — response times in our test sat between 250 and 400 milliseconds. From roughly 5,000 files per folder it becomes noticeably slower, and at 20,000 files the folder view in the web interface took 1.5 seconds. The limiting factor is processor cores, not memory or bandwidth.

How long does a Nextcloud upgrade to a new major version take?

In our test from version 33.0.8 to 34.0.3 it took 27.6 seconds until full availability, without any manual intervention and without a single app being disabled. Important: Nextcloud does not allow skipping multiple major versions, and third-party apps are the real risk — not the upgrade process itself.

Why is the Nextcloud upload so slow with many small files?

Because every individual file triggers a complete PHP request. We measured it: a PUT of a 20 KB file costs around 310 milliseconds, while a static file from the same server takes only 1.9 milliseconds. The data volume is almost irrelevant; the number of requests determines the duration. 10 MB as one file took 0.4 seconds, the same 10 MB as 500 files took 133.6 seconds.

What is the fastest way to migrate large amounts of data into Nextcloud?

Not via the desktop client, but by copying directly into the data directory and then running occ files:scan. In our test this route was 265 times faster than the serial WebDAV upload — with an identical result in the database, which we verified. For ongoing operation WebDAV remains the right route.

How many users can Nextcloud Talk handle without an extra server?

Without the High Performance Backend, Talk runs in internal signaling mode, meaning peer-to-peer — we verified this in the app’s source code. Every participant therefore sends their video stream to every other participant, which practically limits it to one-to-one and small group calls. Larger conferences require the paid HPB.

How much disk space does a Nextcloud installation need?

A fresh installation occupied 857 MB of program code in our test, plus a 60 MB data directory and a 5.73 MB database across 126 tables. After the upgrade to version 34 and installing Talk it was 1,390 MB of code and 153 tables. Talk alone accounts for 199 MB and 22 tables — so the program code grows independently of your own data.

How many apps in the Nextcloud app store are still maintained?

Of 753 apps in the store, 396 (52.6 %) were compatible with Nextcloud 34.0.3 on the test day. Broken down by last stable release: 61.2 % were updated within the last six months, 20.2 % have had no stable release for over two years, and 8.8 % never had one. Every third-party app you install can block a future upgrade.

How much work are backups with Nextcloud?

Considerably less than expected. Switching on maintenance mode, taking a database dump and switching maintenance mode off again took a total of 1.10 seconds on an instance holding 27,000 files; the dump was 5.6 MB. The real operational effort in self-hosting is not backups but major version updates and maintaining the installed apps.

Is self-hosting Nextcloud worth it financially?

Not on small installations. We calculated this in a dedicated article: for five users a managed offering costs around €51 per year, while your own VPS runs about €371 in infrastructure alone — before counting a single hour of work. The argument for self-hosting is control and data sovereignty, not price.

What is the biggest drawback of Nextcloud?

The base cost per request. A listing of a completely empty folder cost 243 milliseconds in our test, while a static file from the same server was delivered in 1.9 milliseconds. Every request runs a full PHP start with roughly 47 active apps. That explains both the slow upload of many small files and the noticeable sluggishness with large folders.