We’re happy to announce that Percona Server for MongoDB (PSMDB) 8.0.28-12 extends platform support to RHEL 10 and its derivatives (Oracle Linux 10, Rocky Linux 10, AlmaLinux 10, and other RHEL-compatible distributions) for both x86_64 and ARM (aarch64) architectures. This release also adds support for Debian 13 “Trixie” on x86_64 and ARM64. We’ll continue to support that for 8.0, 8.3, and newer releases.
This is an important step for anyone planning infrastructure refreshes around the latest Linux releases, and it’s especially notable for teams evaluating ARM to cut infrastructure spend without sacrificing performance.
Starting with this release, Percona Server for MongoDB packages are available for:
Additionally, starting this release, we’ve included Software Bills of Materials (SBOMs) and Vulnerability Exploitability Exchange (VEX) for every release. SBOMs improve software supply chain transparency by documenting the components and dependencies included in a build. They are generated automatically as part of the release pipeline in the industry-standard CycloneDX format. OpenVEX files are published on GitHub Pages and provide the exploitability status of known vulnerabilities. For comprehensive information, refer to our [documentation](../sbom.md).
To learn more, see the full release notes of Percona Server for MongoDB 8.0.28-12.
As of this writing (August 2026), upstream MongoDB Community/Enterprise Server does not yet officially package or support Debian 13. Trixie isn’t in MongoDB’s supported platforms list, and the documented community workaround is to install the Debian 12 “Bookworm” build on Trixie hosts, since a native Trixie server build hasn’t landed yet. PSMDB closes that gap now, with native Debian 13 packages rather than a buggy Bookworm build running out-of-distro.
We have heard multiple times from you directly, via our forum, or on Reddit about the Interest in ARM for database workloads. Over the last few years, adoption has moved well past the experimental phase to resilient production readiness. Our adoption telemetry data show nearly 3x as many ARM instances over the last 12 months!
I can see a number of benefits and reasons why our community users and customers adopted ARM over AMD or Intel CPU architectures:
(Note: The above figures come from third-party blogs and vendor case studies rather than peer-reviewed benchmarks. Treat them as directional evidence that ARM is worth evaluating, not a guarantee of results for your specific workload. For the official recommendation based on your workload, reach out to Percona)
Netflix has publicly stated that it saves over $15 million annually after migrating video encoding workloads to Graviton, while also seeing faster processing times, and other large-scale AWS customers have reported double-digit percentage reductions in compute costs after moving meaningful portions of their backend fleets to ARM (byteiota; sanj.dev).
One RHEL 10 detail to keep in mind when planning a migration: Red Hat raised the CPU baseline for x86_64 to the x86-64-v3 microarchitecture level, meaning the processor needs to support instruction sets such as AVX2 (Red Hat, RHEL 10 architecture documentation; vInfrastructure Blog). On the ARM side, RHEL 10 targets the ARMv8.0-A baseline (Red Hat documentation). This applies equally to Oracle Linux 10, Rocky Linux 10, and AlmaLinux 10, since they build from the same upstream sources. I highly recommend checking your current infrastructure before planning the move, especially for older bare-metal fleets.
In general, but especially on ARM, remember that performance is workload-dependent. Some code paths and workloads leaning on x64-specific instruction extensions may not see the same gains as throughput-oriented, multi-threaded workloads on ARM. Benchmarking your own query patterns and index-heavy operations before a full cutover is essential. General benchmarks are a good signal, not a guarantee.
Migrating a production MongoDB deployment to a different infrastructure is a project with real decision points. There are a number of questions to answer around: Hardware or instance selection, driver and tooling compatibility, benchmarking against your actual workload, and a rollback plan. The Percona Services team helps customers plan and execute exactly this kind of migration. We start from initial architecture assessment and proof-of-concept benchmarking and go through to production cutover and post-migration tuning.
If you’re weighing a move to ARM, or just want to get onto RHEL 10 or Debian 13 without surprises, reach out to Percona to talk through your environment.
Resources
RELATED POSTS
