What problem are you trying to solve?

Focus on the what and why of the need you have, not the how you'd like it solved.

MongoDB Server cannot be built or run on the RISC-V 64-bit architecture (riscv64, rv64gc, little-endian, Linux). The build system has no riscv64 target wiring for the allocator, libunwind, or the bundled SpiderMonkey, and community distributions that package MongoDB (e.g. openEuler) explicitly exclude riscv64 (ExclusiveArch: x86_64 aarch64). As a result, teams that
standardize on RISC-V hardware have no way to deploy MongoDB on it, and must either run MongoDB on a different architecture or choose a different database.

What would you like to see happen?

Describe the desired outcome or enhancement.

We would like MongoDB Server to officially support (or at minimum, accept community contributions toward supporting) the riscv64 architecture on Linux, so that mongod/mongos build and pass the standard test suites on riscv64 hardware, similar to how x86_64 and aarch64 are supported today.

Notably, much of the groundwork already exists in the v8.0 source tree: SConstruct already registers riscv64 in processor_macros; WiredTiger carries RISCV64_HOST, fence-based memory barriers, and a riscv64 CRC32 implementation (WT-12201, WT-12525); IntelRDFPMathLib maps riscv64 to its EFI2 path; bundled gperftools and libunwind contain __riscv branches; and the bundled mozjs extract includes a riscv64 backend (the mongo build uses mozjs with --disable-jit, so only a pre-generated platform/riscv64/linux directory is missing). The remaining work is small, well-scoped changes in mongo core (pause.h, stacktrace_somap.cpp), build-system wiring, and per-component pre-generated platform files.

Why is this important to you or your team?

Explain how the request adds value or solves a business need.

Our team is adopting RISC-V server hardware, and MongoDB is our preferred database. Without riscv64 support we cannot deploy MongoDB in that environment, which forces a split infrastructure (different architectures for databases vs. compute) or a migration to an alternative database — both of which carry significant cost and operational risk.

Porting MongoDB to riscv64 would let us (and other teams in the same situation, including the growing RISC-V server ecosystem) standardize on a single architecture. We are willing to do the engineering work ourselves and submit pull requests; we are asking first whether MongoDB would welcome this contribution and what the acceptance criteria would be (supported versions, toolchain, test suites, CI expectations).

What steps, if any, are you taking today to manage this problem?

1. We completed a full source-level analysis of MongoDB v8.0.0 and produced a porting checklist identifying every architecture-dependent component (core code, SConstruct, WiredTiger, mozjs, libunwind, tcmalloc, other bundled third-party libraries).

2. We confirmed there is no existing riscv64 port to reuse: no riscv tickets in the MongoDB JIRA (only WT-12201/WT-12525, which touched RISC-V barrier instructions in WiredTiger), no riscv branch or patches in community packaging.

3. We are preparing the build environment (riscv64 machine / qemu-user + GCC >= 11.3 toolchain) to attempt a first build.

4. We are posting this idea to coordinate with MongoDB before writing code, so the work lands in a form the team can accept.