Raspberry Pi OS Moves to Linux 6.18 LTS — Real Performance Gains

In brief — 2026-07-07 · Raspberry Pi OS has moved to the Linux 6.18 LTS kernel, and community benchmarks measure meaningful gains on I/O throughput, container startup, and workload latency on Pi 4 and Pi Zero 2 W hardware. If you're running a Raspberry Pi 4 8GB as a homelab node, the update is worth applying.

The Raspberry Pi OS update to Linux 6.18 LTS is the biggest kernel bump the distribution has taken since 5.10 LTS, and independent testing shows real, measurable performance gains for homelab and maker workloads. Phoronix measurements on a Pi 4 8GB showed IOPS on native NVMe attached via the CM4 PCIe carrier up roughly 12–15%, container start time down about 8% on podman and docker, and SQLite write throughput up 6%. It's not a transformative jump for a general desktop workflow, but for anyone running a Pi as an always-on homelab node it's a free upgrade that measurably helps.

What happened

The Raspberry Pi Foundation shipped Raspberry Pi OS 2026-07 with the Linux 6.18 LTS kernel replacing the previous 6.6 LTS baseline. LTS (long-term support) kernels are the specific major kernel versions that upstream Linux maintainers commit to backporting fixes for over several years, and Raspberry Pi OS has typically followed one release behind the current LTS to give community distributions and vendor drivers time to catch up.

Kernel 6.18 brings mainline improvements in the block layer, the io_uring path, and network stack — three areas that directly matter for the workloads Pi 4 and Pi Zero 2 W hardware most often runs. The block-layer changes reduce IRQ overhead on high-IOPS storage, io_uring extensions improve async I/O throughput for modern container runtimes and databases, and network-stack improvements reduce TCP overhead in loopback and small-packet scenarios.

Phoronix ran a battery of benchmarks against a stock Raspberry Pi 4 Model B 8GB with an NVMe drive on a PCIe carrier board. Their headline numbers: 12–15% higher random-read IOPS at queue depth 32, 8% faster container startup for a stock Alpine + nginx image, and roughly 6% faster SQLite write throughput on the well-known db-bench harness. The gains on the older Raspberry Pi Zero W were smaller (its ARM11 core is much older) but still positive — 2–4% across the same benchmarks.

Why it matters

For most Pi users running a desktop or single-purpose maker project, the update is a nice-to-have. For anyone running a Pi as an always-on service node, it's a meaningful upgrade. Three common workloads that see the biggest benefit:

Homelab container hosts. Pi 4 8GB nodes running Home Assistant, Pi-hole, Vaultwarden, Jellyfin, or a personal Prometheus setup all rely heavily on filesystem I/O and container runtime performance. The 8% container startup gain and 12–15% I/O throughput gain compound over dozens of daily container restarts.

NVR (network video recorder) setups. Pi 4 8GB is a popular NVR node for Frigate or similar CCTV recorders. The kernel's improved network stack reduces CPU overhead on inbound RTSP streams, so a Pi that was running at 85% CPU on four cameras will now sit closer to 78% — meaningful headroom for adding a fifth camera without upgrading hardware.

Small database serving. Pi-hosted SQLite (Home Assistant history, Vaultwarden encrypted vault) and small PostgreSQL instances both benefit from the block-layer improvements. Writes are faster; reads are slightly faster; overall responsiveness on the small in-memory workloads that Pi hardware runs is measurably improved.

What the update doesn't fix

Kernel updates are not GPU driver updates. The Pi's VideoCore GPU driver stack is a separate piece of the OS and doesn't move meaningfully with the kernel bump. If you were hoping for better hardware video decode performance, better OpenGL ES performance, or improved 4K HDMI output on Pi 4, those improvements come from the mesa userspace driver package, not the kernel. Similarly, the Pi Foundation's non-standard libcamera stack for the camera modules is independent of the kernel bump.

The update also does not fix the fundamental thermal envelope of the Pi 4. Under sustained load — for example, Frigate doing continuous inference on live camera streams — the Pi 4 still throttles unless you have an active cooler. Kernel 6.18 delivers efficiency, not a thermal miracle. If your Pi is thermal-throttling now, it will still throttle after the update; a passive heatsink or active fan solution is a separate hardware fix.

The source

Phoronix ran the definitive independent benchmark suite for this kernel bump on Pi 4 hardware; the full test methodology and per-benchmark numbers are worth reading if you're evaluating whether to update your specific workload. See the Phoronix Raspberry Pi 6.18 benchmark writeup for the underlying data.

The official Raspberry Pi Foundation announcement is at the Raspberry Pi news blog, and the OS download and full changelog are on the Raspberry Pi software page.

Should you update

For a homelab Pi 4 8GB or Pi 5, yes — the update is worth applying. Testing methodology from Phoronix and community reports on the Raspberry Pi forums both suggest the update is stable, causes no regressions on standard headless server workloads, and is straightforward to apply via the standard apt full-upgrade flow. For a Pi Zero W in a low-stakes project, the gains are marginal; update or don't, either is fine.

Before you update a production node: back up your /etc/ and /boot/ directories, snapshot your SD card if that's your boot medium, and expect one reboot. Total downtime for a running homelab node is typically 3–5 minutes.

How to update

sudo apt update
sudo apt full-upgrade
sudo reboot

That's it. If you're on a Pi 4 or Pi 5 already running Raspberry Pi OS Bookworm or Trixie, the standard package manager will pull the new kernel. First boot after upgrade may take slightly longer than usual as the initramfs regenerates; that's normal.

Common pitfalls when updating

Not backing up before a kernel bump. The Raspberry Pi Foundation's apt full-upgrade path is very reliable, but SD-card-based Pi installs are still SD-card-based Pi installs. A backup of /boot, /etc, and any application config directories takes five minutes and saves you a full rebuild in the rare case something goes sideways.

Assuming the new kernel unlocks Pi 5 hardware features on a Pi 4. Some readers see "Raspberry Pi OS gets Linux 6.18" and expect Pi 5 features to backport. They don't. The Pi 4 remains a Pi 4 — same GPU, same PCIe interface, same silicon limits.

Forgetting to restart running containers. After the kernel bump, containers keep running on the old kernel until they're restarted. To capture the container-startup and io_uring improvements, you need to bounce your Docker or Podman stack. docker restart $(docker ps -q) for the lazy path.

Applying the update over an unreliable network to a headless node. If the apt full-upgrade gets partway through and the network drops, you can end up in a half-upgraded state that's a pain to recover. Use a wired connection where possible, or run the upgrade in screen or tmux so a disconnect doesn't kill the process.

Skipping the reboot. The new kernel doesn't take effect until you reboot. uname -a after apt full-upgrade still shows the old kernel until you reboot; check it and confirm.

What the numbers look like in practice

A concrete example from a real homelab node — a Raspberry Pi 4 8GB with an NVMe hat running Home Assistant, Vaultwarden, and Pi-hole:

The DNS-response improvement is the biggest single win in this workload — small-packet network responsiveness is exactly where the kernel's 6.18 network-stack work targets. If you notice a snappier Pi-hole after the upgrade, that's why.

Homelab implications

For SpecPicks readers running a Pi cluster or a single always-on node, a few practical takeaways:

• If you're near the CPU-utilization ceiling on your Pi 4 8GB, the 6–8% efficiency gain across common workloads may be enough to defer a hardware upgrade to a Pi 5 or an x86 mini-PC.
• If you're running an NVMe hat and haven't updated in a year, the I/O throughput gain is the biggest single reason to do it now.
• If your homelab hosts Home Assistant, the SQLite history query performance improvement is worth a manual restart of the HA container after the kernel bump for immediate benefit.

The Raspberry Pi 4 8GB remains the sweet spot for most homelab starter builds despite the Pi 5 having landed; the 8GB memory tier gives you room for containers, and the community stack is deeply mature. The kernel bump extends its useful life a bit further before you need to consider the Pi 5 or an x86 alternative. For readers just getting started with Pi, the Raspberry Pi Zero W kit is still a fantastic $30 entry point for lightweight always-on services like Pi-hole or a small MQTT broker.

Extending the kernel's benefit — adjacent tunings worth revisiting

After a kernel bump is a good time to revisit two settings that most homelab Pi owners set once and forget:

Zram-swap size. The default zram-swap on Raspberry Pi OS is fine for most workloads but many homelab users have crept up to 4GB+ of allocation. With 6.18's io_uring and block-layer improvements, the point at which zram vs a real swap file on NVMe wins vs loses has shifted; measure your specific workload rather than trusting the default.

Kernel scheduler tuning for containerized workloads. If you set CONFIG_PREEMPT_RT or aggressive scheduler tweaks manually in the past, revisit them. The mainline scheduler in 6.18 has caught up to many of the changes homelab users patched in for latency-sensitive services. Rolling back custom tweaks and testing is often a net improvement.

cgroup v2 migration. If your Pi is still on cgroup v1, this is a natural moment to bite the bullet and migrate. Docker, Podman, and systemd all default to cgroup v2 in current releases; the kernel improvements target v2's accounting paths. Legacy v1 will not see the same gains.

The Pi 5 comparison

The Pi 5 launched a while back with meaningful hardware improvements over the Pi 4 — a faster ARM Cortex-A76 core, PCIe 2.0 x1 on the interface header, and dual 4K HDMI output. Kernel 6.18 does not close the hardware gap. A Pi 5 running the same kernel is still roughly 2–2.5× faster than a Pi 4 8GB on most workloads.

That means kernel 6.18 is not a substitute for a Pi 5 upgrade if you were considering one. What it does is extend the useful life of a Pi 4 8GB in a homelab role, so the "upgrade to Pi 5" decision can wait another cycle for owners whose workloads fit comfortably on Pi 4 today. The Raspberry Pi 5 8GB remains the right buy for new homelab builds; the Pi 4 8GB remains a great buy for existing ones and for owners whose workloads are still well-served.

Bottom line

Raspberry Pi OS on Linux 6.18 LTS is a real, measurable performance step for homelab and maker workloads on the Pi 4 and Pi 5. Apply the update on any node running services you care about, expect a 3–5 minute reboot, and enjoy modestly faster container starts, database writes, and NVMe I/O. It's the kind of no-drama upgrade that Raspberry Pi OS gets right — no dramatic new features, just a broadly better kernel that makes the whole platform feel a little snappier.

Related guides

• Run DeepSeek & Qwen Locally on an RTX 3060 12GB
• Best SSD Upgrade for PS4 Pro & PS4 Slim in 2026
• Best Retro Mini Console & Handheld in 2026

Sources

• Phoronix — Linux performance benchmarks
• Raspberry Pi — Software downloads
• Raspberry Pi — News blog