SLES 15 vs. RHEL 9: Enterprise Server Performance Compared

There is no universal performance winner between SUSE Linux Enterprise Server 15 and Red Hat Enterprise Linux 9. A defensible answer depends on the exact service pack or minor release, hardware, kernel updates, tuning profile, application stack, and workload. The current SUSE SLES 15 SP7 tuning guide and Red Hat's RHEL 9 documentation describe tuning capabilities; they do not establish a controlled, general-purpose head-to-head speed result.

This distinction matters because the SLES 15 SP7 documentation identifies a Linux 6.4 kernel base, while Red Hat documents RHEL 9 as based on kernel 5.14 and notes that it backports newer changes into its kernel stream. Those version labels alone do not predict which distribution will run a database, web service, or virtual machine faster. Treat them as product facts, then benchmark the workload you actually plan to operate.

What can be verified about SLES 15 and RHEL 9?

Before comparing machines, record the exact installed versions and active profile on each. For example, collect cat /etc/os-release, uname -r, and sudo tuned-adm active. Use the version output rather than the marketing name “SLES 15” or “RHEL 9” as your test label.

Does SLES 15 SP7's newer kernel base make it faster than RHEL 9?

Not by itself. Kernel base versions are not a benchmark score. Red Hat maintains a stable major-release kernel stream and backports selected fixes and features; therefore, a RHEL 9 kernel reporting 5.14 can contain functionality from newer upstream releases. SUSE also maintains and updates its own supported kernel stream. Application behavior depends on the exact fixes, drivers, hardware support, configuration, and the code path the workload exercises.

Action: record the full kernel package version and release level for both test systems. When investigating a feature or driver, check each vendor's release notes and support matrix for that exact release instead of comparing only the first two numbers from uname -r.

Are the default TuneD profiles equivalent?

No equivalence should be assumed. TuneD exists in both ecosystems, but the installed profile set, automatic recommendation, profile contents, and local overrides may differ. SUSE's SLES 15 SP7 guide describes profile recommendations based on system configuration. Red Hat's RHEL 9 documentation also says automatic profile selection depends on machine type and system settings. Even when both hosts report a profile with the same name, verify what it changes before treating the configurations as identical.

Action: run sudo tuned-adm active and sudo tuned-adm list on each host. Save the output and any custom profile files. For a “default installation” comparison, retain each vendor's supported default and document it. For a “best attainable performance” comparison, tune each operating system separately using vendor guidance, then report the profiles and settings used.

Do not apply every performance profile at once. Profiles can conflict—for example, a throughput-oriented storage setting can be undermined by another setting that increases disk spindown. Change one relevant variable at a time, confirm that the service remains stable, and keep a rollback record.

Which system is likely to perform better for your workload?

The workload usually matters more than a broad distribution label. These are test priorities, not promises about which vendor will win:

• CPU-bound applications: use the production compiler, runtime, libraries, and security settings. Measure completed work per second and CPU time. A microbenchmark can help explain a difference, but it cannot replace an application test.
• Databases and memory-heavy services: use a representative database version, schema, working-set size, concurrency, and persistence policy. Track transactions per second alongside median and tail latency; a higher average rate can conceal slower requests.
• Storage-intensive services: keep the same drive model, controller firmware, filesystem, mount options, data set, and queue depth. Measure the actual read/write mix and latency distribution, not just peak sequential throughput.
• Network services: keep the NIC, firmware, switch path, MTU, offload settings, and client load consistent. Measure application throughput and latency under the expected connection count.
• Virtual machines or containers: compare on the same hypervisor or container stack, with the same CPU and memory allocation, host policies, guest profile, and image. Include density and resource contention if that reflects production.
• Power-sensitive systems: report energy per completed unit of work, not only peak speed. A system that consumes less power while taking longer may not use less total energy for a batch job.

If you do not know where time is going, profile the application or monitor CPU, memory pressure, I/O wait, network saturation, and run queues before tuning. Otherwise, a faster CPU profile will not fix a storage bottleneck.

How should you run a fair comparison?

First decide which question you are answering. “Which system is faster immediately after installation?” is different from “Which system is faster after supported production tuning?” Do not compare one distribution's tuned configuration against another's defaults and call the result an operating-system comparison.

1. Match the platform: use identical server models where possible, with the same CPU stepping, memory population, BIOS/firmware, storage, NIC, and power limits.
2. Freeze the software details: note the SLES service pack and update level, RHEL minor release and update level, kernel package, application version, runtime/compiler, firmware, and relevant security mitigations.
3. Control configuration: record TuneD profiles, CPU governor or power mode, NUMA and huge-page settings, filesystem and mount options, and application parameters. Keep them at defaults for an out-of-box test or tune both systems intentionally for an optimized test.
4. Use production-like data and load: make the test long enough to reach steady behavior and include the concurrency and data size that matter. Define cache state and warm-up procedure so each run starts comparably.
5. Repeat and report variation: alternate test order when possible, repeat the runs, and show the median plus run-to-run spread. Report throughput together with p95/p99 latency, resource consumption, and errors where relevant.
6. Keep a reproducible record: publish the system configuration, benchmark version, commands or scripts, tuning differences, and raw results. If a result is for a public standardized benchmark, follow that benchmark's current reporting rules.

SPEC's CPU 2017 rules require full disclosure of performance-relevant conditions and enough configuration detail to reproduce a public result. That is a useful standard even when you are testing an internal workload. A benchmark with a single unexplained score is not enough to tell whether a result came from the operating system, compiler flags, BIOS settings, or different hardware.

What is known, what depends on your setup, and what remains unproven?

• Known: current SLES 15 SP7 and RHEL 9 documentation describes different kernel streams and TuneD-based performance configuration. Both vendors document tools for workload-specific tuning.
• Depends on the environment: throughput, latency, power use, boot time, VM density, driver behavior, and the effort required to keep tuning consistent. These vary by hardware, application, release level, and operational policy.
• Not established by the documentation reviewed: that SLES 15 is categorically faster than RHEL 9, that RHEL 9 is categorically faster than SLES 15, or that one kernel base version guarantees a performance advantage for every workload.

Choose the distribution that meets your certification, support, lifecycle, and operational requirements, then validate performance with a controlled proof of concept. If the measured difference is smaller than the run-to-run variation, treat the systems as tied for that workload and decide using supportability, compatibility, and administration needs.

Official references

• SUSE: SLES 15 SP7 System Analysis and Tuning Guide
• SUSE: SLES 15 SP7 Release Notes
• Red Hat: Managing, Monitoring, and Updating the RHEL 9 Kernel
• Red Hat: Getting Started with TuneD in RHEL 9
• Red Hat: Customizing TuneD Profiles
• SPEC: CPU 2017 Run and Reporting Rules
• SPEC: CPU 2017 Overview and Fair Use