Nextcloud vs ownCloud 2026: A Comparison With Real Measurements, Not Brochures

Nextcloud vs ownCloud is the comparison where nearly every article tells the same story: there was a dispute in 2016, the founder left, Nextcloud won, ownCloud is dead. That story is convenient, easy to tell — and wrong in one decisive respect.

So instead of copying another feature table, we installed, started, filled and measured ownCloud Infinite Scale ourselves on 18 September 2026. On the same server, with the same methodology as our Nextcloud test, so the numbers are actually comparable.

The key result first, because it shifts the basic assumption of the whole comparison:

ownCloud Infinite Scale started in 2.0 seconds to its first answered WebDAV request, used 255 MB of RAM, and runs as a single process with no third-party database. The classic ownCloud line that is supposedly dead shipped major version 11.0.0 on 30 July 2026 — with 11 security fixes.

Together these mean: anyone asking “Nextcloud vs ownCloud” today is not comparing two similar products but three different things — and most articles only know two of them.

Nextcloud vs ownCloud: what is actually competing here

The first mistake happens before the first argument — with the question of who is even competing. There are three products today, not two:

All three dates come from the respective GitHub release feeds, retrieved on 18 September 2026 — not from blog posts about those releases.

And here is the finding that invalidates most comparisons: almost every article treats “ownCloud” as PHP software with a database and compares that to Nextcloud. That describes ownCloud Classic. But the company’s strategic product has been oCIS for years — and that has almost nothing technically in common with Nextcloud. No PHP runtime, no MySQL database, no Apache. A comparison that misses this compares Nextcloud against a product the vendor itself no longer puts front and center.

The reverse is equally true, though: the widespread claim that “ownCloud Classic is discontinued” is also false. We checked instead of believing it.

Is ownCloud dead? The measurement says no

The phrase “ownCloud is dead” has been in forums for years. Measured against the owncloud/core repository, it does not hold:

• v11.0.0 was released on 30 July 2026 as a regular release, not a pre-release. The release notes literally say “Classic ownCloud Server 11.0.0 — the first major release of the 11.x line” and list 11 security fixes with a clear upgrade recommendation.
• In the 90 days before 18 September 2026, the first API page alone holds 100 commits. The most active human author is DeepDiver1975 with 30 commits — a developer involved since the early years.
• The most recent commit at retrieval time was from 16 September 2026, two days before this article.

The release also raises the minimum to PHP 8.3 and introduces new code-signing infrastructure (G2 PKI, ECDSA-P384/SHA-384). That is not caretaking, that is foundational work.

🔑 To be honest about it: activity in a repository is not proof of a healthy product strategy. It only proves code is being written. But it refutes the specific claim that “nothing is happening there” — and that claim underpins a lot of purchasing decisions.

For scale, the Nextcloud numbers, same method, same day: 36,837 stars, 5,225 forks, 3,643 open issues versus ownCloud Classic with 8,833 stars, 2,059 forks, 141 open issues and oCIS with 2,122 stars, 619 open issues. Nextcloud is unquestionably the bigger project with the bigger community. That is a real argument — just a different one from “the others are dead”.

The 2016 fork — and what actually came of it

In June 2016 Frank Karlitschek left ownCloud and founded Nextcloud. A large part of the core team went with him. The US entity of ownCloud shut down shortly after. So far the familiar story.

What gets told less often is part two: ownCloud continued in Nuremberg and made a radical decision — instead of evolving the PHP base, it was rewritten from scratch in Go. The result is oCIS, whose repository was created on 15 August 2019 according to GitHub. The rewrite has therefore been running for more than seven years.

Part three is almost never mentioned and is strategically the most important: since the 2023/2024 acquisition, ownCloud belongs to the US company Kiteworks (San Mateo, California). This is not a rumour but visible in the official documentation navigation: the oCIS docs are published under “Documentation for ownCloud (A Kiteworks Company)”, and owncloud.com carries several menu entries for a “Kiteworks Open Source Program Office for ownCloud”.

For a purchasing decision this matters more than any feature row:

• Nextcloud GmbH is a German company earning its revenue directly from the software you self-host.
• ownCloud is today the open-source arm of a US corporation whose main product is something else.

Anyone self-hosting for GDPR or sovereignty reasons — the normal case for German public authorities, schools and mid-sized companies — should know this. It says nothing about code quality, but a lot about whose priorities will drive the roadmap in five years. The licenses do not change because of it: oCIS is Apache-2.0, Classic and Nextcloud are AGPL-3.0, checked directly in the LICENSE files.

Architecture: the difference that explains everything else

This is where the products genuinely diverge — and it is not a matter of taste but of construction.

Nextcloud is a PHP application. Every request spawns PHP work that talks to a database. Its composer.json requires PHP ≥ 8.3 and nearly twenty extensions (gd, curl, pdo, zip, xml and more). Add a web server, a database and in practice always Redis. It is a proven, well-understood stack — but it is several services that must fit together.

oCIS is a single Go binary. We looked inside the running container rather than trusting marketing:

$ docker exec ocis-test ps aux
PID   USER       TIME  COMMAND
    1 ocis-use   0:02  ocis server

One process. And inside that one process, ocis list reports 34 internal services: proxy, graph, idp, idm, webdav, ocdav, search, thumbnails, sharing, postprocessing, nats and others. It is a microservice architecture bundled into one process for normal operation — and separable across machines when needed. Hence “Infinite Scale”.

The numbers from the running system, all measured by us on 18 September 2026:

Methodology: docker stats --no-stream, docker exec … netstat -tln, ocis list. Host: 12 cores, 22 GB RAM, Docker 29.2.1.

Two things stand out.

First: 73 open ports sounds like a security problem — but it is not. We counted: 72 of them listen on 127.0.0.1, only port 9200 is bound third-partyly. This is exactly the design we describe as correct in our article on IT security vulnerabilities — services nobody needs from outside belong on the loopback interface. Had we quoted only the port count, it would have become a false report. A port count without its bind address is not a statement about security.

Second: memory did not rise after 1,200 uploads, it fell slightly (255 → 250 MB). With a PHP application you would expect otherwise, because process pools and caches grow along.

No database server — but not “no database”

The often-quoted line “oCIS needs no database” is only true with a caveat, and the caveat belongs with it. We looked into the data directory:

data/storage/users/spaces/…/nodes/cb/df/52/e3/…/f00193.txt
data/nats/jetstream/$G/streams/KV_postprocessing/msgs/index.db

There is no MySQL or PostgreSQL server, that much is true. Metadata lives in the “decomposed filesystem” right next to the files, spread across a multi-level directory structure. But there really are four index.db files — embedded stores of the internal NATS messaging system.

The honest phrasing is therefore: oCIS needs no separate database server to operate, back up and patch. Operationally that is a genuine advantage — but it is not the same as “stores everything in plain files”.

For backups this has a practical consequence pointing the opposite way from what you might expect: with Nextcloud you back up files and database, and the two must be consistent in time. With oCIS you back up one directory — but you must catch a consistent state while NATS streams are being written in the background. Simpler, not trivial.

Startup time: 2 seconds — and the trap behind it

We timed from docker compose up to the first answered request. The first run produced a misleading result, and the detour teaches more than the number.

First measurement: HTTP 200 on the start page after 1.76 seconds. Looks like a fantastic figure. But it was a false reading — at that same moment the WebDAV interface still returned 401, and persistently so, not just briefly.

The cause was not slowness but a default: oCIS ships with basic auth disabled. Only with PROXY_ENABLE_BASIC_AUTH=true did the API respond. After that:

🔑 Two lessons sit in there. The first is methodological: a service answering on its start page is not ready — it is reachable. We describe exactly this distinction in our Nextcloud test as well; here it nearly turned into a far too flattering number.

The second is substantive and speaks for oCIS: shipping with basic auth off is the safer default. Passwords in the Authorization header are attractive to automated attacks; the intended path is OpenID Connect. Nextcloud permits basic auth over WebDAV by default. For us it meant five minutes of searching — for a production server it is the vendor making the right call.

For context: a Nextcloud stack (PHP-FPM, database, Redis, web server) typically needs considerably longer than two seconds to a usable interface. We deliberately give no comparison figure here, because we did not start both systems on the same day under identical conditions. A copied number looks identical in a table to a measured one.

Upload speed: the direct comparison

Now to the question that decides everyday satisfaction: how fast do many small files land in the system? In our Nextcloud test this was the most painful point — 3.6 files per second over WebDAV.

To make the comparison hold, we matched the methodology: 500 files of 20 KB each, a single curl process with a persistent connection, exactly as before.

That is a factor of 4.8 in favour of oCIS. The difference is not measurement noise but the expected effect of the architecture: with Nextcloud every file costs a full PHP request including database writes, while with oCIS a running Go process handles the request directly.

A second run with 200 files of 2 KB each and a separate curl process per file produced 11.8 files/s at a 85.6 ms median — slower, because process startup and TLS handshake are measured along. Both runs together give a consistent picture.

⚠️ One of our own measurement errors belongs here, because it nearly made it into the article. During the first run I counted in between how many files had arrived and concluded “about 0.3 files per second” — a catastrophic figure. The end timestamp of the same run then said 13 files/s. Both could not be true.

Instead of picking the nicer number, I repeated the run with proper instrumentation (per-file timing, median and maximum instead of just total time). Result: 11.8/s, maximum 114 ms, so no outliers. My intermediate figure was simply wrong — I had confused my sampling interval with the runtime. 🔑 Two instruments that contradict each other are an invitation to measure a third time — not to pick the more pleasant result.

What this comparison does not show: Nextcloud has an escape hatch for initial population, occ files:scan, measured at 953 files/s. Anyone migrating data copies it onto the server and has it scanned — in which case Nextcloud is faster at moving in than oCIS over WebDAV. The oCIS advantage applies to ongoing operation, where every file arrives over the protocol anyway.

Spaces: the concept Nextcloud does not have in this form

The most striking functional difference is called Spaces. We queried the API:

$ curl … /graph/v1.0/me/drives
personal | Admin  | quota: 0
virtual  | Shares | quota: None

In Nextcloud every file belongs to a person. A team folder is technically one user’s folder that they share. When that person leaves the company, the data hangs off an account that ought to be removed — a problem every administrator knows.

oCIS additionally knows Spaces as containers in their own right: a project area belongs to the project, not to Ms Müller. Members come and go, the space remains. For organisations above a certain size this is not a convenience feature but a structural advantage — and it is particularly relevant in education, where users rotate every school year (see our article on Nextcloud for schools).

In fairness: Nextcloud has an answer in group folders (Team Folders). It is functionally closer than the oCIS sales pitch admits — but it is a retrofitted app, whereas Spaces are anchored in the data model.

Feature scope: the clearest point for Nextcloud

Up to here much of this reads in favour of oCIS. On feature scope the picture flips clearly — and not by a small margin.

Nextcloud Hub is an office suite today: files, calendar, contacts, mail, Talk (video), Deck (kanban), Notes, Forms, Collectives, office integration, an assistant with local AI models. The app store holds hundreds of extensions. You can run Nextcloud as a replacement for Microsoft 365 — that is explicitly the goal.

oCIS is a file platform. Very good at files, sharing, search and spaces, connected to Collabora or OnlyOffice for documents. Calendar and contacts are not part of the core; there is no video conferencing application. That is not an oversight but a decision — the company sells a platform for files, not an intranet.

The consequence for your selection is uncomfortably simple:

• If you want groupware where calendar, chat and tasks come along, oCIS has nothing to compare. Then it is Nextcloud.
• If you want fast, robust file storage for many users and have calendars elsewhere anyway, oCIS gives you less software with more calm.

The inverse also holds: Nextcloud’s large feature scope is the reason for most operational problems. Every app is code that must come along at a major upgrade. Our experience upgrading from 33 to 34 is in the Nextcloud test — the apps were the laborious part, not the core.

Migration: the path from ownCloud to Nextcloud (and back)

ownCloud Classic → Nextcloud is the best-supported path because both share the same ancestry. Nextcloud has provided documentation and a migration step through the upgrade procedure for years. Coming from ownCloud 10, you have realistic chances of moving without data loss.

ownCloud Classic → oCIS is, despite the shared vendor name, the harder path. They are different programs with a different data model; tools exist, but there is no in-place upgrade button.

Nextcloud → oCIS effectively runs over the clients or copy tools, not over a database migration.

For all three paths the same sober advice applies, from our own experience: do a trial run with a copy, take checksums beforehand, compare file counts afterwards. And do not estimate the time from data volume but from the number of files — the measurements above show why.

Which system when? An honest recommendation

Nextcloud, if:

• calendar, contacts, video or tasks should come along
• the user count is manageable and breadth of features matters
• a large community and plenty of tutorials are important
• a German vendor without a corporate parent is preferred

ownCloud Infinite Scale, if:

• it really is only about files, but a lot of them
• team structures matter more than personal folders (Spaces)
• operations should be lean: one process, no database server
• many small files occur in daily work (factor 4.8 in our measurement)
• OpenID Connect is already in place

ownCloud Classic, if:

• an existing ownCloud 10 installation is running and stable
• version 11.0.0 covers the maintenance need for the time being

In no case should ownCloud Classic be the choice for a new installation. Not because it is dead — demonstrably it is not — but because the vendor is visibly betting its future on oCIS. Starting a new installation on a codebase that is no longer central to its own maker is an avoidable risk.

What we did not measure

So it is clear how far these numbers reach:

• No long-term test. oCIS ran for hours, not weeks. Our data says nothing about stability in continuous operation.
• No desktop or mobile clients. We measured over WebDAV — the same protocol, but not the clients’ conflict handling.
• No same-day Nextcloud counter-test. The Nextcloud figures are from 20 August 2026 on the same server with the same methodology, but not in the same run.
• No multi-node operation. The “infinite” in Infinite Scale means distribution across many machines. We tested one container — so the central marketing claim remains unverified.
• No load from real users. One curl process is not a staff of 60 working simultaneously.

Frequently asked questions

Is ownCloud dead?

No. ownCloud Classic 11.0.0 was released on 30 July 2026 with 11 security fixes, and the owncloud/core repository holds at least 100 commits in the 90 days before 18 September 2026, the latest from 16 September 2026. The company exists as the open-source arm of Kiteworks. That said, Nextcloud is the significantly larger project (36,837 versus 8,833 stars), and ownCloud’s strategic product today is Infinite Scale, not Classic.

What is the difference between Nextcloud and ownCloud?

Nextcloud is a 2016 fork of ownCloud that grew into a complete office suite: files plus calendar, contacts, video and tasks. ownCloud exists in two forms — Classic (PHP, built like Nextcloud) and Infinite Scale (fully rewritten in Go, a pure file platform with Spaces). Depending on the article, “Nextcloud vs ownCloud” means one or the other, which is what makes most comparisons unusable.

Is oCIS faster than Nextcloud?

For many small files, yes, and clearly so. We measured with identical methodology: 500 files of 20 KB took 28.3 seconds (17.7 files/s) on oCIS 8.2.0 versus 133.6 seconds (3.7 files/s) on Nextcloud 33.0.8 — a factor of 4.8. For initial population, however, Nextcloud has occ files:scan at 953 files/s, which beats any WebDAV path.

Does ownCloud Infinite Scale need a database?

No separate database server — no MySQL, no PostgreSQL. Metadata lives in the “decomposed filesystem” next to the files. It is not entirely database-free though: the data directory contains four embedded index.db files belonging to the internal NATS messaging system. The operational advantage is real, but the phrase “needs no database” is imprecise.

How much RAM does oCIS need?

In our measurement 255 MB at idle and 250 MB after 1,200 uploaded files — consumption did not rise under load. The Docker image is 323 MB, and exactly one process runs in the container, bundling 34 internal services.

Can you migrate from ownCloud to Nextcloud?

Yes, and it is the best-supported path because both originate from the same PHP codebase; Nextcloud documents the procedure. Considerably more work is required, of all routes, for ownCloud Classic to ownCloud Infinite Scale — despite the shared vendor name they are different programs with a different data model and no in-place upgrade.

Who owns ownCloud?

Since the 2023/2024 acquisition, ownCloud belongs to the US company Kiteworks, headquartered in San Mateo, California. This is visible directly in the official documentation, published as “Documentation for ownCloud (A Kiteworks Company)”. Nextcloud, by contrast, is an independent German company — for decisions where digital sovereignty matters, this difference is often more important than any feature list.

Conclusion

Nextcloud vs ownCloud in 2026 is not a question of winner and loser but of two different goals.

Nextcloud has clearly won the contest for feature scope and community — four times the stars, a suite rather than an application, an independent German company behind it.

ownCloud went in a different direction and is technically convincing there: one process, 255 MB, two second startup, factor 4.8 on uploading many small files, Spaces as a real data model.

The claim that “ownCloud is dead” is refuted — by a major release seven weeks before this article and by a hundred commits in the last quarter. The more interesting question is not whether ownCloud is alive but who owns it and whose priorities will shape the coming years.

And the most honest sentence at the end is the one about our own measurement: we tested one container on one server. The central marketing claim of Infinite Scale — scaling across many machines — we therefore did not verify. What we did not measure, we do not claim.