FreeBSD and ZFS for WordPress – Performance, Security, and Practical Benefits

A practical comparison of FreeBSD with ZFS and Linux as a hosting platform for WordPress. We analyze differences in the networking stack (kqueue vs epoll), MySQL/MariaDB optimization on ZFS, snapshot and rollback mechanisms, service isolation with Jails, VNET, and RCTL, as well as the real limitations of the FreeBSD ecosystem.

WordPress powers a huge portion of the internet, from small blogs to large-scale stores and enterprise websites. Nearly all of them run on Linux: the LAMP stack (Linux, Apache, MySQL, PHP) or LEMP (with Nginx), increasingly with Docker on board. It works well and is a proven standard. But it is worth knowing that it is not the only one.

FreeBSD with the ZFS filesystem is an alternative that is rarely discussed. A different kernel, a different isolation model, a different filesystem – and with the right configuration, concrete advantages in performance and security. CIS (Center for Internet Security) benchmarks for FreeBSD 14 confirm that a properly hardened system delivers excellent network performance and strong defensive mechanisms. The question is: is it worth it, and for whom?

Networking Stack: kqueue Versus epoll

For a CMS like WordPress, content serving speed is critical. WordPress generates HTML dynamically through PHP, but the server also has to handle a large number of static requests: images, CSS, JavaScript. What matters here is how the kernel handles I/O with a large number of concurrent connections.

Linux uses the epoll mechanism for this. FreeBSD has kqueue, and in this area the difference is clear.

Both mechanisms operate in O(1) time, so event scaling itself is comparable. The advantage of kqueue lies elsewhere: it offers a unified API for handling events from different sources, such as file descriptors, signals, and filesystem changes. Multiple updates can also be submitted in a single system call. epoll cannot do this, because there each change requires a separate epoll_ctl() call. In practice, with tens of thousands of concurrent connections (the classic C10K problem), kqueue generates lower CPU overhead.

One more thing worth mentioning: epoll cannot notify about changes in regular disk files and requires the data to already be in the page cache. kqueue does not have this limitation.

Web Server Comparison on FreeBSD

The choice of web server determines whether you can actually leverage FreeBSD’s networking potential.

Particularly interesting is the interaction between Nginx and FreeBSD in the context of zero-copy. Thanks to the sendfile call with the SF_NODISKIO flag, the server can stream data from the ZFS page cache (ARC) directly to the network socket, bypassing userspace entirely. This drastically reduces CPU load and is highly significant for WooCommerce stores that need to survive sudden traffic spikes.

FreeBSD also offers kernel accept filters (e.g., accf_http). These delay waking the web server process until the client has sent a complete HTTP request. Fewer unnecessary context switches, greater stability under load.

PHP on FreeBSD: No Revolution

When it comes to raw PHP performance, the differences between FreeBSD and a well-optimized Linux are small, on the order of 1–3% in synthetic benchmarks. There is no revolution here.

Things get more interesting at a deeper level. Tests on AMD Threadripper processors showed that FreeBSD handles kernel-level multithreading significantly better. Semaphore operations run up to twice as fast, and context switching can be up to 15 times faster than on Linux. However, in a typical WordPress environment, this advantage is largely masked by the nature of PHP processing itself.

This is why proper PHP-FPM tuning becomes critical. Setting the profile to pm = ondemand instead of the default dynamic avoids allocating unnecessary processes and limits RAM waste.

MySQL/MariaDB Optimization on ZFS

The database is the most common bottleneck in any WordPress installation. On Linux, with traditional filesystems (ext4, XFS) on hardware RAID, the administrator must ensure block size synchronization to avoid write amplification. This is an additional layer of complexity.

ZFS approaches this entirely differently thanks to its Copy-on-Write (CoW) mechanism. Updating a record does not overwrite old data. The system writes new data to free sectors and atomically updates the pointers. The write either completes fully or does not happen at all. There are no intermediate states, no corrupted pages.

However, to fully exploit this, several MySQL/MariaDB features that ZFS handles better at its own level need to be disabled:

What does this mean in practice? Tests on AWS EBS infrastructure (presented by Percona, among others) showed that MySQL tuned this way on ZFS reduced total query execution time by approximately 22% compared to ext4 on RAID10. The biggest gains were in DELETE operations (about 40% faster) and INSERT (about 15%).

Compression is worth adding to the picture. Instead of using MySQL’s built-in compression, it is better to enable native LZ4 at the ZFS level (compression=lz4). Modern CPUs decompress an LZ4 stream with virtually no overhead, and the effect is doubled read speeds and up to 50% reduction in disk space usage. At cloud storage prices, this is a real saving.

To be fair, more recent Percona tests from 2021 show that the performance gap between ZFS and ext4 has narrowed. With proper tuning on both sides, results can be comparable. Today, ZFS’s advantage lies more in its additional features (compression, snapshots, data integrity) than in raw speed.

Snapshots, Clones, and Bookmarks: Data Management on ZFS

Traditional WordPress backups – even with tools like Duplicator or WP Staging – rely on exporting the database and files, which takes minutes or longer. During this time, users may modify data, risking an inconsistent backup. ZFS solves this problem at the filesystem level.

Snapshots

The zfs snapshot command captures the exact state of an entire filesystem. It takes a fraction of a second and at the moment of creation consumes no additional disk space. Only when data starts to change does the snapshot begin to “grow,” preserving old blocks.

Crucially, a snapshot is immutable. It cannot be modified or encrypted, making it an effective defense against ransomware. If a WordPress update goes wrong, a single zfs rollback command restores the server to its pre-failure state.

Clones

Testing changes in a pre-production environment (staging) usually requires copying the entire database, often many gigabytes of data. This takes time and wastes disk space.

A ZFS clone is an editable copy of a snapshot that initially consumes no additional space. It shares blocks with the original, and new space is allocated only for changed data. You can instantly spin up a full-sized test environment, run a destructive migration or test a new plugin version, and then simply delete the clone.

Bookmarks

When replicating snapshots to an offsite location, a problem arises: old snapshots accumulate on the primary server and cannot be deleted because replication chains depend on them.

ZFS bookmarks solve this elegantly. They do not reserve space for data – they only store pointers (GUID identifiers and transaction log numbers). This means you can delete heavy, outdated snapshots on the primary server while continuing incremental replication to the backup location.

FreeBSD Jails: Isolation Instead of Containerization

WordPress falls victim to attacks most often through vulnerable plugins, not through core vulnerabilities. A typical scenario: an attacker gains remote code execution (RCE) through a neglected plugin. At that point, what matters is whether the infrastructure can effectively isolate the intruder.

On Linux, the standard is Docker or Podman, optionally with Kubernetes orchestration. These tools operate in userspace and introduce their own layer of complexity – and sometimes their own vulnerabilities.

FreeBSD takes a different approach. Jails are kernel-level virtualization (OS-level virtualization), conceptually closer to chroot on steroids than to containers in the Docker sense. A Jail behaves like a closed, autonomous system but is isolated directly by the host kernel.

How Jail Isolation Works

Even if an attacker gains root privileges inside a Jail, the FreeBSD kernel automatically blocks them from, among other things:

• Dynamically loading system modules.
• Direct hardware access and raw socket communication.
• System calls that modify host-level global settings.

This is not a matter of configuration. These restrictions are hard-coded into the kernel. The Jail administrator is simply not the same root as on the host.

Jail management can be automated with frameworks like BastilleBSD, eliminating the need for heavy Kubernetes-style tooling. Jails natively integrate with ZFS, so creating a new Jail from a snapshot is a matter of seconds.

Network Segmentation: VNET

Each Jail can be assigned its own fully isolated networking stack through the VNET mechanism. This means separate routing tables, a separate loopback interface, and a separate firewall (pf or ipfw). Even if an attacker broke through the Jail isolation itself, they would still need to breach the virtual network topology to reach the host.

Resource Management: RCTL and RACCT

In shared hosting, the “noisy neighbor” problem is a regular occurrence. A single WooCommerce store with inefficient SQL queries can paralyze all other sites on the server.

FreeBSD has the RACCT/RCTL framework for this. Once enabled in the kernel configuration (kern.racct.enable=1), the administrator can impose precise resource limits on individual Jails in real time, without restarting services:

• Limit CPU to 80%: rctl -a jail:NAME:pcpu:deny=80
• Limit RAM to 1 GB: rctl -a jail:NAME:memoryuse:deny=1G

The /etc/rctl.conf configuration file can be secured (chmod 600) so that shared hosting clients cannot inspect the limits set for them.

Linux has its own counterpart: cgroups (unified and mature in version v2). Docker and systemd use them automatically, which in practice means that on Linux resource limiting is built into everyday tools and does not require additional kernel configuration. RCTL does the same thing, but at a lower level of abstraction. FreeBSD’s advantage here is not the limiting mechanism itself, but the fact that RCTL works directly with Jails and ZFS as a coherent, integrated stack – without the need to layer separate components on top of one another (Docker + cgroups + overlay filesystem).

VPS Providers with FreeBSD Support

FreeBSD is a niche among cloud and hosting providers. Below is a short overview of the ones we trust and actively use to deploy FreeBSD servers for WordPress and WooCommerce. We deliberately skip the popular Contabo – our tests revealed instability in the FreeBSD network stack on their platform.

Challenges and Limitations

This article would be incomplete without discussing what keeps FreeBSD, despite its strengths, from dominating the hosting market.

No management panels. cPanel, DirectAdmin, and other popular hosting panels are designed for Linux. Their FreeBSD equivalents either do not exist or are poorly maintained (e.g., Plesk abandoned development of its FreeBSD tool). FreeBSD administration relies primarily on the terminal and shell scripts. There is no GUI for configuring VNET or the pf firewall – everything is done from the console.

Shortage of specialists. The job market is dominated by engineers who know Linux, Docker, and Kubernetes. People who can administer FreeBSD at a production level are far fewer. For agencies and enterprises building teams, this is a serious barrier.

Smaller software ecosystem. Many popular DevOps and monitoring tools (Prometheus exporters, Ansible modules, Terraform providers) are developed with Linux in mind. On FreeBSD, some of them require additional configuration, and others simply do not work. The same applies to hardware drivers, especially for newer network cards and NVMe controllers. Before choosing FreeBSD, it is worth checking whether your entire planned toolchain is compatible.

Conclusion

FreeBSD with ZFS is a solution that offers real advantages over the standard Linux stack in specific scenarios.

First, database performance. ZFS with properly tuned InnoDB shortens query execution times, and native LZ4 compression can save up to 50% of disk space without sacrificing read speed.

Second, security. FreeBSD Jails with VNET create kernel-level isolation far deeper than standard containers. Even after a WordPress compromise, the attacker remains effectively contained.

Third, data management. ZFS snapshots, clones, and bookmarks take backups and staging environments to an entirely different level: they are instant, consistent, and resilient to ransomware.

In the budget shared hosting market, FreeBSD has no place – Linux with cPanel and specialized distributions like CloudLinux (with CageFS, LVE, and MySQL Governor) is simply easier and cheaper to maintain. However, for demanding business environments such as large WooCommerce stores, financial institution websites, or platforms handling hundreds of thousands of SQL queries, FreeBSD-based infrastructure offers a level of security and stability that is difficult to achieve on a standard stack.

If it were not for Linux’s dominance in the hosting and cloud ecosystem, FreeBSD would absolutely be our first-choice operating system!