ext4 vs XFS vs btrfs on a VPS: Choosing a Filesystem by Workload

Almost every VPS image ships ext4 by default, and for most workloads that is the right call. But “default” and “optimal” diverge the moment your workload has a strong profile: many small random writes, huge sequential files, or a need for snapshots and rollback. This guide compares ext4, XFS, and btrfs on the workloads you actually run on a VPS and gives you a decision rule instead of a benchmark spreadsheet. If you are choosing a new host, our VPS comparison table shows which providers let you pick the filesystem at provisioning time.

The Three Candidates in One Table

Filesystem	Strengths	Weaknesses	Best for
ext4	Mature, boring, universally supported; fast small-file metadata; low overhead	No native snapshots; single-threaded metadata ops can bottleneck	Web servers, app roots, small databases, general-purpose root FS
XFS	Excellent parallel throughput; scales to huge filesystems and files; robust under crashes	Cannot shrink; COW off by default; weaker small-file/random-write metadata	Large sequential files, media, backups, artifact storage, high-core workloads
btrfs	Snapshots, subvolumes, send/receive replication, checksums, compression	COW overhead on random writes; more moving parts; historically finicky under heavy pressure	Root FS with pre-update snapshots, backup targets, containers

ext4: The Safe Default, and When It Stays Right

ext4 wins on boringness, which is a feature. It is the most battle-tested filesystem in the Linux world, its metadata layout favors exactly the access pattern of a web application (many small files, moderate concurrency), and it has essentially no tuning requirements. For a WordPress site, an app root, or a MySQL data directory on a small VPS, ext4 is hard to beat — especially because database engines do their own caching, so filesystem-level tricks rarely help and COW overhead would only hurt.

Two mount options are worth setting regardless: noatime (skip atime updates on reads) and discard or a weekly fstrim timer so the host’s SSD knows which blocks are free. That is the entire ext4 optimization story on a VPS.

XFS: Throughput for Big Files and Many Cores

XFS was designed for large filesystems with heavy parallel I/O, and its allocation groups let multiple CPUs allocate and write concurrently. That makes it the right choice when the workload is sequential and big: video and audio files, database backups, log archives, Docker volumes for object storage. On a benchmark like fio’s 1 MiB sequential write, XFS routinely posts meaningfully higher throughput than ext4 on the same disk, and the gap grows with core count.

# Quick fio comparison (run on an unmounted test volume!) fio --name=seqw --rw=write --bs=1M --size=2G \ --ioengine=libaio --direct=1 --numjobs=4 \ --filename=/mnt/test/fio.file --group_reporting

The trade-off: XFS historically underperforms ext4 on small-file random workloads, and you cannot shrink an XFS filesystem. On a VPS where you size the disk once and grow it via the provider's panel, "cannot shrink" rarely matters — but it does mean you should not allocate a huge XFS volume "just in case".

btrfs: Snapshots Change Your Backup Strategy

btrfs earns its place on a VPS with exactly one feature: cheap, instant snapshots. A snapshot before every apt upgrade or deploy gives you a rollback path that no other filesystem on this list offers, and btrfs send/receive makes incremental off-site replication elegant. If you have ever restored a broken server from a full disk image and wished for something faster, btrfs subvolumes are that something.

# Snapshot the root subvolume before a risky change btrfs subvolume snapshot / /.snapshots/pre-upgrade-$(date +%F) # Roll back if the upgrade goes sideways btrfs subvolume delete /@root btrfs subvolume snapshot /.snapshots/pre-upgrade-2026-08-18 /@root

The cost is copy-on-write: every overwrite becomes a new allocation, so random-write workloads (a busy database, a mail spool) pay a measurable penalty unless you mark those files nodatacow. On a 2 GB VPS running MySQL, putting the data directory on btrfs without nodatacow can add visible latency under load. Rule of thumb: btrfs for the root filesystem and anything you want snapshots of; keep hot databases on a separate ext4 or XFS volume — or use chattr +C on the database directory before first write.

A Decision Rule, Not a Benchmark War

General web hosting, small databases, "just make it work": ext4. Nothing on this list beats it for simplicity and predictable small-file performance.
Large files, backups, media, high-core parallel I/O: XFS. Pick it for the volumes where throughput is the point.
Root filesystem on a box you tinker with, or a backup target: btrfs. Snapshots turn "I broke it" into a 5-second rollback.
Production databases on shared VPS storage: ext4 or XFS with noatime, and let the database do its own caching. Avoid COW filesystems unless you disable COW on the data files.

One honest caveat: on a VPS, the host's shared I/O and network filesystem (or lack of one) usually dwarf the differences between these three. A 20% filesystem delta is invisible next to a noisy neighbor on the same hypervisor. So benchmark with fio if you enjoy it, but choose by workload profile — and re-check benchmarks on the actual host, not on a laptop.

If you are provisioning a new server and the provider's image only offers ext4, do not lose sleep: it is the right default for most sites, and you can always add a btrfs subvolume for snapshots or an XFS volume for backups later. Our storage and disk options comparison lists which providers expose raw volumes and custom filesystem choices, and the provider ranking is a good place to start if you want NVMe-backed storage where these choices actually show up in benchmarks.