Collabora Online vs ONLYOFFICE: Measure RAM and Editing Latency

Collabora Online’s CODE 26.04 release, announced June 8, 2026, includes document interoperability and usability changes, but its release notes do not publish a controlled RAM or latency comparison against ONLYOFFICE Docs. For a useful decision, benchmark the exact builds you plan to deploy on the same host, with the same documents, browser, storage platform, and user actions. Vendor minimum requirements are planning guidance, not comparable performance results.

This reference procedure measures two separate things: server resource use and the time users perceive while opening and editing a document. It does not claim that one suite is universally faster. File complexity, integration, network path, fonts, and concurrent sessions can change the result.

What the published requirements can—and cannot—tell you

ONLYOFFICE’s current Docker requirements list at least 4 GB of RAM and 4 GB of swap, and its documentation says actual requirements vary with concurrent active users and document type and size. Its Docker troubleshooting guide says 2–4 GB of use can be normal for a few dozen active users. These are ONLYOFFICE-specific sizing notes, not a direct comparison with Collabora.

Collabora says hardware needs depend on the number of concurrent users; its FAQ also cautions that performance falls as concurrent use grows and depends on server resources. CODE and the supported Collabora Online product are distinct deployment choices. A small home CODE test does not predict a production subscription deployment, just as a test of ONLYOFFICE Community Edition does not automatically represent another edition or architecture. Record the edition, release, deployment method, and integration for each run.

As of October 2026, CODE 26.04 is a recent Collabora release. Its release notes describe improvements, including document interoperability, but do not quantify RAM per user or editing latency versus ONLYOFFICE. Treat that as a reason to test current, pinned builds; do not treat it as evidence of a speed advantage.

Build a fair, repeatable test

1. Use the same host and integration path. Give each suite the same CPU and memory limits, storage location, reverse proxy, TLS setup, and network route. If you run both containers together, they compete for the same resources; instead, stop one suite, measure it, then replace it with the other. Keep the host otherwise idle.
2. Pin the software versions. Record the exact image tag or release, edition, Docker version, host OS, browser version, and connected platform. Avoid floating tags such as latest during a comparison because the software could change between trials.
3. Prepare representative files. Include a small text document, a spreadsheet with formulas and charts, and the largest or most complex file your users commonly open. Use duplicate test copies, not production originals. Store them through the same document platform used in normal work.
4. Keep the client conditions steady. Use the same computer, browser, network connection, screen size, and browser extensions. Close unrelated tabs. For each trial, make sure the document is fully closed before starting a cold-open measurement; then run separate warm-open trials.
5. Define the timings before testing. Measure from the open action until the document is fully rendered and accepts editing. For editing latency, time a defined action—such as typing a short phrase and waiting until it appears for a second collaborator. Record the result of each run instead of relying on a single impression.

Measure server use and user-visible delay

Memory and CPU

Capture an idle baseline after the service has settled. Then record container memory and CPU while opening one file, editing it, and leaving it open. Repeat with several concurrent documents and users at the levels that match your expected workload. For Docker, docker stats --no-stream displays a point-in-time resource snapshot; use it repeatedly during each phase or collect a time series with your existing monitoring system. Record host-level available memory as well, because a container’s reported use alone does not show whether the whole machine is under pressure.

Report peak memory, average memory during the active phase, and idle memory after documents close. Keep the same sampling interval. Do not equate memory after one document with capacity for a team: sessions, file size, rendering complexity, and concurrent editing all matter. If the deployment supports Prometheus metrics, collect them consistently; Collabora documents Prometheus-compatible metrics and live session monitoring. For ONLYOFFICE, use its documented container diagnostics and resource guidance. Avoid comparing one product’s internal process metric with the other product’s whole-container total.

Open and edit latency

Run at least five cold opens and five warm opens for each representative file. Report the median and slowest observed time, not only the best result. A cold open includes work such as loading the document and rendering its initial view; a warm open may benefit from caches. Use the same definition of “ready” in both editors.

For collaboration delay, connect two browser sessions and measure from a specific edit in one session to the visible update in the other. Repeat the same action several times, both with no other open documents and under the intended concurrent load. This captures the combined effect of the editor, server, storage integration, and network. If the browser and server are on different networks, record round-trip conditions; network delay can dominate the editor’s own processing.

Read the results without overclaiming

Choose the suite that meets your latency target while leaving enough memory and CPU headroom at realistic concurrency. If results are close, prioritize document compatibility, integration support, operational familiarity, and licensing. Re-run the same test after a major upgrade or infrastructure change. For authoritative version-specific details, see Collabora’s CODE 26.04 release notes, Collabora Online FAQ and security and monitoring overview, plus ONLYOFFICE’s Community Edition Docker requirements and Docker troubleshooting and resource guidance. These sources describe each product separately; they are not a controlled head-to-head benchmark.