Picking the right MMseqs2 build before a large sequence search

Many-against-many searching for very large sequence sets

MMseqs2 stands for Many-against-Many sequence searching, and that expansion sets the design: queries and database sequences travel through one shared pipeline instead of being handed to an aligner one query at a time. The suite exists for protein and nucleotide sets so large that per-query alignment becomes the bottleneck, and it is written in C++ for Linux, MacOS and, as a beta build routed through cygwin, Windows.

Its audience is not a general application developer but the people who process sequence data at scale: metagenomics pipelines, taxonomy assignment, and anyone collapsing redundant sequences into representative clusters. Repository topics say the same thing in one line, covering clustering, profiles, taxonomy and metagenomics rather than a single task.

Speed is stated as ratios against named baselines, and those numbers are the project's own. Read closely, 10000 times faster than BLAST carries no sensitivity condition at all, at 100 times its speed sensitivity is described as almost the same, and profile searches reach PSI-BLAST sensitivity at over 400 times its speed. Five papers support the claims, spanning 2017 to 2025, and the top-level layout holds no benchmark harness to check them.

What the repository tree says about how it is built

Read from the repository layout, the core sources sit in `src/` with bundled dependencies in `lib/`, CMake logic in `cmake/`, and a top-level `CMakeLists.txt` that ties them together. A `data/` directory sits next to `util/`, whose helper scripts include `bash-completion.sh`, the file the README tells Linux and MacOS users to source from their bash profile. `examples/` ships exactly two files, `examples/DB.fasta` and `examples/QUERY.fasta`, and that pair is the whole example set the repository commits: one query side, one database side.

Container builds mirror that split. `Dockerfile` takes TARGETARCH and APP as build arguments, sets the app name to mmseqs, and selects a builder image out of `ghcr.io/steineggerlab/build-containers`, a different registry owner than `ghcr.io/soedinglab/mmseqs2`, the application image users are told to pull. Automation is configured twice, in `azure-pipelines.yml` and in `.cirrus.yml`, while the build badge at the top of the README points at a pipeline hosted on `dev.azure.com` under the account themartinsteinegger rather than the soedinglab organisation.

Pick the CPU build before you download anything

MMseqs2 wants a 64-bit AMD or Intel system, and the README narrows that into three checks: architecture first, then SSE4.1, then AVX2. An SSE2 build exists for very old machines, SSE4.1 is the recommended floor, and the AVX2 tarball is marked fastest, so picking the wrong one buys nothing and costs throughput. ARM64 and PPC64LE with POWER8 ISA or newer work as well, and the macOS archive is universal across Apple Silicon and Intel Macs.

Run these on Linux before choosing a download:

uname -a | grep x86_64
cat /proc/cpuinfo | grep sse4_1
cat /proc/cpuinfo | grep avx2

On MacOS the two feature checks are spelled through sysctl instead:

sysctl -a | grep machdep.cpu.features | grep SSE4.1
sysctl -a | grep machdep.cpu.leaf7_features | grep AVX2

Empty output from the sse4_1 grep means only the SSE2 build will run. Output for sse4_1 but nothing for avx2 points at the SSE4.1 tarball, and a matching avx2 line points at the fastest one. Windows users get no such choice, since the cygwin build is the only documented route.

Five installation routes, none of them one size fits all

Compiling from source is the long route, while a statically compiled binary, Homebrew, conda and Docker are the short ones. Three of them are a single line each, and none needs a compiler:

brew install mmseqs2
conda install -c conda-forge -c bioconda mmseqs2
docker pull ghcr.io/soedinglab/mmseqs2

Static tarballs unpack into a mmseqs/bin directory that you add to PATH yourself. The archive name states which instruction set you are getting, and the AVX2 one is labelled fastest:

wget https://mmseqs.com/latest/mmseqs-linux-avx2.tar.gz; tar xvfz mmseqs-linux-avx2.tar.gz; export PATH=$(pwd)/mmseqs/bin/:$PATH

Those recipes stop once a binary sits on PATH. For actual searches, the README routes readers to the GitHub Wiki, to a PDF user guide linked as `userguide.pdf`, and to wiki tutorials built around real data, with anything unanswered going to the GitHub issue tracker.

32-bit identifiers run out at 2^32 sequences

Database identifiers default to 32-bit integers, which makes the ceiling a build-time decision rather than a runtime one. Anyone whose sequence count could exceed 2^32 flips a CMake flag:

-DMMSEQS_INT64_IDS=1

The same switch is available precompiled, in a tarball named `mmseqs-linux-avx2-64bit.tar.gz`, which the README labels a static AVX2 build with support for more than 2^32 sequences. Its warning is the part worth reading twice: 2x more memory is needed even for smaller DBs, so the penalty does not wait until a database is genuinely enormous.

That turns the choice into a hardware budget decision. A workstation with RAM to spare can compile the flag and stop thinking about identifier width, while a shared cluster with a fixed per-node memory cap cannot, and for small collections the default build is both simpler and lighter.

GPU search splits hardware support into two tiers

MMseqs2-GPU ships as its own mostly-static AVX2 build with two hard prerequisites, glibc >= 2.29 and an nvidia driver of 525.60.13 or newer. Ampere generation or newer runs at full speed, Turing generation runs at reduced speed, and Volta or Pascal cards do not work with the bioconda or precompiled binaries at all. AMD support is preview quality: ROCm on CDNA2 generation or newer, reachable only through the `master-rocm7` Docker tag, because ROCm is left out of the conda and precompiled builds.

The Dockerfile turns that hardware split into two compile target lists whose first eight entries match exactly:

ARG CUDA_ARCH_AMD64=75-real;80-real;86-real;89-real;90-real;100-real;103-real;120
ARG CUDA_ARCH_ARM64=75-real;80-real;86-real;89-real;90-real;100-real;103-real;120;121-real

AMD64 stops after eight entries, at a bare 120, and ARM64 continues to a ninth, 121-real, while on both lines that final value drops the -real suffix the earlier entries carry. A GPU generation that exists only on ARM64 hardware therefore gets a compiled kernel on one architecture and none on the other. Turning any of this on takes the GPU build argument, which defaults to 0, so an ordinary docker build hands you the CPU suite unless the CUDA variant is requested by name.

C in the language breakdown, C++ in the README

Two descriptions of this codebase disagree. GitHub files the repository under C, while the README puts the implementation language at C++, and a third signal points elsewhere again, because the arm64 branch of the Dockerfile passes Rust toolchain flags to CMake, naming a stable Rust toolchain and an aarch64 Rust target. Nowhere in the README is a Rust component described, so the language breakdown, the project description and the build script give three different pictures of what the hot path is made of.

Branch activity is the second thing to read before planning around the suite. The last push to master was on 2026-09-23, yet the newest named release, 18-8cc5c, is dated 2025-07-27, and the two before it, 17-b804f and 16-747c6, landed in January 2025 and November 2024. Work on master is therefore well ahead of the most recent tag, which means anyone pinning the release tag and anyone tracking master run different code, with no documented compatibility bridge between the two.

Sensitivity wording is where the speed claims stop

Three ratios are stated against named tools, none of them vague: 10000 times faster than BLAST, almost the same sensitivity at 100 times the speed, profile searches at PSI-BLAST sensitivity with over 400 times its speed. Each number belongs to a different regime, and only one of the three claims parity rather than near parity. That ranking decides how much the speed is worth. For collapsing redundant sets, the 2018 Nature Communications paper on clustering protein sequence sets in linear time describes the case where a small sensitivity loss costs least, and a 2021 Bioinformatics paper covers fast and sensitive taxonomic assignment to metagenomic contigs. Confirming one uncertain homology call is the opposite case.

There are setups where MMseqs2 is plainly the wrong choice. Windows support is beta and arrives through cygwin rather than a native build. A machine reporting no SSE4.1 leaves only the SSE2 build, the slowest of the five. And a cluster whose GPUs are Volta or Pascal generation cannot use the bioconda or precompiled binaries at all, which forces a source build on the machines least able to spare the effort.

Editorial conclusion

MMseqs2 fits pipelines where one query is not the unit of work: metagenomic taxonomy assignment, clustering redundant sequences, or profile search across a database that stalls a per-query aligner. It does not fit a handful of sequences on unfamiliar hardware, and its Windows build stays beta through cygwin. Before adopting it, check three concrete things: that your CPU reports SSE4.1 or AVX2 so you avoid the SSE2 build, that your database will stay under 2^32 sequences, and that the workflow command you need is named in the current userguide.pdf.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. soedinglab/MMseqs2 on GitHub