zram on Fedora vs. zswap on Ubuntu: A Practical Performance Comparison

When your system starts running out of physical RAM, it reaches for swap — a slower overflow space that keeps processes alive when memory is scarce. For decades, that meant writing data to a disk partition or file. Today, Fedora and Ubuntu have each taken a smarter approach: compressing memory pages in RAM before they ever hit storage. But they have implemented this idea in meaningfully different ways.

Fedora defaults to zram, a compressed swap device that exists entirely in RAM with no disk involvement at all. Ubuntu ships with a traditional swap file on disk, with the option — though not the default — of layering zswap on top as a compressed cache. These are not just configuration differences; they reflect different philosophies about safety, speed, and the hardware assumptions each distribution makes about its users.

How Each Technology Actually Works

To compare performance fairly, it helps to understand what each technology is doing at a mechanical level.

zram creates a virtual block device that lives in RAM. When the kernel wants to swap out an inactive memory page, it compresses that page using an algorithm (zstd is common in modern Fedora) and stores it in this in-memory device. The page never touches a disk. Reading it back is equally fast: decompress from RAM and you’re done. The entire round trip happens at memory speeds, which are orders of magnitude faster than any SSD.

zswap takes a different approach. It sits between the kernel’s swap system and the actual disk swap. When the kernel tries to write a page to disk, zswap intercepts it, compresses it, and holds it in a RAM pool. If the page is needed again soon, it’s decompressed straight from RAM — the disk is never consulted. Only when the RAM pool is full, or when a page hasn’t been touched for a long time, does zswap evict it to the actual swap file on disk. It is a cache layer, not a replacement for disk swap.

Fedora’s Implementation: zram by Default Since Fedora 33

Fedora adopted swap-on-zram as its default configuration starting with Fedora 33, released in late 2020. The mechanism is handled by zram-generator, a systemd generator written in Rust that creates and configures the zram device early in the boot sequence.

The 50%-of-RAM cap reflects a deliberate conservatism. Because compressed data takes roughly half its uncompressed size on average, a zram device sized at 50% of RAM will consume at most around 25% of physical RAM when fully loaded — leaving the rest available for actual workloads. The Fedora project notes that at the time of the switch, they considered 200% of RAM not unreasonable if compression ratios hold well, but chose the safer default to avoid swap thrashing in edge cases.

Importantly, Fedora’s choice also means hibernation (suspend-to-disk) is not supported out of the box. Since zram lives in RAM, its contents disappear when power is cut. This is a deliberate tradeoff: Fedora does not officially support hibernation, so the simplicity of a disk-free swap was considered more valuable.

Ubuntu’s Approach: Swapfile with Optional zswap

Ubuntu’s default setup is more conservative and more familiar. A plain swap file — typically /swap.img — is created at installation. There is no compression involved by default. Ubuntu ships with the zswap kernel module present and compiled in, but it is not enabled unless the user explicitly turns it on.

The Ubuntu community has discussed adopting zram or zswap as a default on several occasions. As of 2026, neither has been enabled by default in the main Ubuntu desktop image. Ubuntu 26.04 LTS (Noble Numbat) brings improved zswap support, but the base configuration remains a plain swap file. Users on systems where memory pressure is noticeable are encouraged to enable zswap manually, or install zram-tools to get zram instead.

Performance on the Desktop

For everyday desktop use — browsing, office applications, media playback — both approaches work well when memory pressure is moderate. The differences become visible at the edges: when RAM is nearly full and the system must rely heavily on swap.

zram’s advantage on the desktop is immediacy. Because there is no disk involved, swapping is dramatically faster than traditional approaches. On systems with slow HDDs or budget SSDs, this difference is stark: instead of seconds of waiting while the disk thrashes, the system compresses and decompresses in RAM with only a small CPU cost. For users on low-to-mid-range hardware with 4–8 GB of RAM, zram can make the difference between a system that remains usable and one that locks up under load.

zswap’s advantage on the desktop becomes apparent on systems with fast NVMe storage and heavier, more unpredictable workloads. A Linux developer running virtual machines, containers, and dozens of browser tabs may push well past the amount of data that comfortably fits in a zram device. In September 2025, linuxblog.io’s Hayden James published a detailed retrospective concluding that, after years of championing zram, he found zswap often outperforms it on modern systems with fast NVMe drives and workloads that regularly exceed 20 GB of memory demand. zswap’s ability to fall back gracefully to disk means that when the compressed pool is full, the system keeps running smoothly rather than invoking the OOM killer.

Hibernation is another desktop consideration. zswap works alongside a disk-based swap file, which means suspend-to-disk works exactly as expected. zram users on Fedora who need hibernation must configure a separate swap file in addition to zram — a workaround, but not the default.

Performance on the Server

Server workloads introduce different pressures. Memory use tends to be steady and predictable (database buffers, web server workers, containerized services) rather than bursty. Disk I/O patterns matter more, and administrative predictability is valued over cutting-edge defaults.

zram on servers has a specific and well-established use case: VPS instances and cloud virtual machines with 1–2 GB of RAM and slow disk I/O. In these environments, zram prevents the kernel from swapping to disk at all, keeping latency consistent. A July 2025 guide for Ubuntu 24.04 VPS deployment noted that on instances where RAM is constrained and disk performance is not particularly fast, zram can produce a noticeable improvement in responsiveness. The compressed pool effectively doubles or triples the usable working set for lightweight workloads like small Node.js applications, PHP servers, or personal Git instances.

However, on servers with 32 GB or more of RAM — common in production — zram’s benefits narrow. These systems rarely experience heavy swap pressure under normal operation, and when they do, it is often a sign that more RAM is needed rather than that compression will save the day. Adding a large zram device on a high-memory server also introduces a small but real CPU overhead that may not be welcome on latency-sensitive services.

zswap on servers aligns naturally with the traditional Linux server model: a swap partition or file provides a reliable safety net, and zswap reduces the I/O cost of hitting it. Ubuntu Server’s default of a plain swapfile is well-understood by sysadmins. Layering zswap on top is straightforward and does not disrupt existing tooling, monitoring, or expectations around hibernation and crash recovery. For servers running workloads with burst memory demand — batch processing jobs, build servers, analytics pipelines — zswap’s ability to absorb spikes in RAM and then write cold pages to the (fast NVMe) disk is often a better fit than a fixed-size zram device that may be exhausted by a particularly large job.

Side-by-Side Comparison

Compression Algorithms: zstd vs. lz4

The choice of compression algorithm matters almost as much as the choice of technology. Fedora’s zram defaults to zstd, which offers a significantly better compression ratio than older algorithms like LZO at a modest CPU cost. Ubuntu’s zswap, when enabled, defaults to lz4, which compresses and decompresses extremely quickly with lower CPU overhead, at the cost of a somewhat larger compressed footprint.

In practice, zstd means Fedora’s zram pool holds more data before it fills — a meaningful advantage on memory-constrained systems. lz4 means Ubuntu’s zswap adds less latency when the CPU is already busy, which suits high-throughput server environments where CPU cycles are precious. Both algorithms are supported by both technologies; these are defaults, not hard constraints.

Which Should You Use?

If you are on Fedora, zram is already configured and working. For most desktops and small VPS instances, you will not need to change anything. If you run memory-intensive workloads that regularly exceed your physical RAM by a large margin — or if you need hibernation — consider adding a small swap file alongside zram and enabling zswap instead, or simply increasing the zram pool size via /etc/systemd/zram-generator.conf.

If you are on Ubuntu and experiencing slow performance under memory pressure, the single most impactful change is to enable zswap. This can be done by adding zswap.enabled=1 to your kernel parameters in /etc/default/grub and running update-grub. Alternatively, install zram-tools to adopt the zram model instead — many Ubuntu users find the Fedora approach appealing even on Ubuntu hardware.

For servers, the answer depends on your storage. A VPS with 2 GB of RAM and a slow spinning disk is an ideal zram candidate regardless of distribution. A bare-metal server with 64 GB of RAM and NVMe storage will likely see more benefit from careful swappiness tuning (vm.swappiness=10) than from either compression technology.

The Broader Trend

Memory compression is increasingly the norm rather than the exception across operating systems. Windows has used memory compression since Windows 10, and macOS has had it since Mavericks in 2013. Android and ChromeOS have shipped with zram enabled for years. The Linux desktop is catching up: Fedora led the way in 2020, Pop!_OS followed, and pressure continues to mount on Debian-based distributions to enable some form of compression by default.

The debate between zram and zswap is ultimately a debate between two well-engineered solutions to the same problem, each with different assumptions about the hardware it runs on and the workloads it serves. Fedora’s bet on zram reflects confidence in modern CPUs and a desire to eliminate disk I/O from the swap path entirely. Ubuntu’s caution reflects the breadth of its deployment targets — from low-end ARM boards to high-memory cloud instances — and a preference for the known behaviour of disk-backed swap as a safety net.

As NVMe storage becomes ubiquitous and RAM remains comparatively expensive, the conversation will continue to evolve. For now, both approaches represent a substantial improvement over the plain disk swap that most Linux systems used just five years ago.