Foldseek: structure search fast enough to query the predicted protein universe

Structure search at the scale of the predicted universe

Foldseek enables fast and sensitive comparisons of large structure sets, supporting monomer and multimer searches as well as clustering.

The problem it addresses is the arrival of predicted structures at scale. The second publication in the list is Barrio-Hernandez and colleagues, Clustering predicted structures at the scale of the known protein universe, published in Nature in 2023, and it is the clearest statement of why a structure search tool that is not fast is not much use. When the number of structures to compare is in the tens of millions, the cost is not the alignment but the candidate generation, and a tool that has to run the comparison the traditional way spends its time on candidates that will not match.

The approach Foldseek takes is to fold the three dimensional geometry into a compact representation, a 3Di vector per residue, and to compare those rather than the coordinates. That is the same idea the sequence search tools use, and the same reason the fourth publication exists, Kallenborn and colleagues on GPU-accelerated homology search with MMseqs2, which is the pre-print that brought that idea to the structure world.

The first publication, van Kempen and colleagues in Nature Biotechnology in 2023, is the one to read for the method itself, fast and accurate protein structure search with Foldseek. The fifth, Reifenrath and colleagues on LoL-align, covers sensitive and fast probabilistic protein structure alignment.

The intended user is a structural biologist or a computational biologist working with predicted structures, and the tool reaches them through a command line, a webserver, published databases and a Docker image. The primary language is C, the licence is GPL-3.0 with `LICENSE.md` at the root, the homepage is foldseek.com, and the default branch is `master` with the last push on 2026-09-09. The recent release tags are 10-941cd33 from 2025-01-19, 9-427df8a from 2024-05-09 and 8-ef4e960 from 2023-09-11.

Searching from sequence, without a structure for the query

The feature list ends with a sentence that changes what the tool is for. Foldseek runs on CPU, supports GPU acceleration for faster searches, and optionally allows ultra-fast and sensitive comparisons directly from protein sequence inputs using a language model, bypassing the need for structures.

That is a significant addition. The classical use case is: you have a structure, you want to know what it resembles in a database. The sequence-first use case is: you have a sequence, and you want its structural neighbours without ever folding it yourself. A language model predicts the fold, and the predicted geometry is what gets compared, so a predicted query can be matched against a set of predicted references in the same way a known structure would be.

The README carries a dedicated example for it, Fast Structure Search from FASTA input, and the database documentation has a matching entry, Create custom database from protein sequence (FASTA). The webserver offers the same thing for the AlphaFoldDB and PDB, and there is a separate section on the Foldseek-Multimer paper for the complex case, Kim and colleagues in Nature Methods in 2025, rapid and sensitive protein complex alignment with Foldseek-Multimer.

The Dockerfile gives a hint about how that works under the hood. The container installs a Rust toolchain through rustup, with a host target of `x86_64-unknown-linux-gnu` or `aarch64-unknown-linux-gnu` depending on the architecture, alongside CMake and the CUDA toolkit when the GPU flag is set. A Rust component inside a C project is not a scripting convenience, it is a model being run inside the search path.

So the tool now covers three shapes of question: find structures like this structure, find structures like this sequence, and find complexes like this complex. The clustering mode then collapses a large result set into representative members and their followers, which is what the Nature clustering paper does at the scale of the known protein universe.

Output formats, clustering modes and the StrucTTY viewer

The README's table of contents is long, and the shape of it tells you what the tool does in practice.

A search can output tab-separated results, superpositioned Cα only PDB files, or an interactive HTML report. Cluster results can be output as a tab-separated cluster file, a representative fasta, or an all-member fasta, which is a nice touch because clustering results are usually more useful as sequences you can re-query than as a list of identifiers. Multimer search has its own tab-separated output and a complex report, and multimer clustering mirrors the monomer clustering outputs.

Results can also be visualised with StrucTTY, and the alignment mode is a documented parameter, which tells you the tool is not only a matcher but also something you inspect afterwards.

For databases, the documentation covers creating custom databases and indexes, creating a custom database from protein sequence in FASTA form, and padding a database for fast GPU search. The last of those is worth understanding, because the GPU path and the CPU path have different performance characteristics and a database prepared for one is not optimal for the other.

The examples section collects the operations a user actually performs: faster search with GPU acceleration, fast structure search from FASTA input, rescoring alignments using TMscore, and query centered multiple sequence alignment. The rescoring one is a good example of the intended workflow. A fast prefilter produces candidate alignments, and then TMscore gives a more accurate measure of the ones that matter, so the tool is designed to be used in two stages rather than to give you one slow answer.

Installing: binaries, conda, and the GPU generation caveat

The installation section offers precompiled binaries for several platforms, and the one-line installs are the practical route.

For Linux on a machine with AVX2, the check is `cat /proc/cpuinfo | grep avx2` and the install is:

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

There are Linux ARM64, Linux AVX2 and GPU, and MacOS universal builds, and the Linux GPU build is documented as requiring glibc 2.17 or newer and an NVIDIA driver of 525.60.13 or newer. The conda route is:

conda install -c conda-forge -c bioconda foldseek

and other precompiled binaries are linked from mmseqs.com/foldseek.

The GPU note is the one to internalise before you install. The project recently added support for GPU-accelerated protein sequence and profile searches, which requires an NVIDIA GPU of the Ampere generation or newer for full speed, and also works at reduced speed for Turing-generation GPUs. The bioconda package and the precompiled binaries will not work on older GPU generations such as Volta or Pascal.

That is a hard boundary rather than a soft one, and it bites in a specific way. A cluster with a mix of GPU generations cannot run one binary for all of it, and a researcher whose only GPU is a Pascal card cannot use the GPU path at all. The CPU path remains available, which is the safe fallback and the one most installations will use.

The build system is Azure Pipelines, with a Dockerfile for reproducible container builds, and the repository carries a `CMakeLists.txt` at the root with the `src/`, `lib/` and `util/` directories holding the C implementation, plus `data/`, `example/` and a `regression/` directory.

Memory is the constraint that decides who can run this

The memory requirements section is the most practically important part of the README, and it is unusually precise.

For optimal software performance there are three options based on your RAM and search requirements. The first is with Cα info, which is the default, and the formula to calculate RAM is `(6 bytes Cα + 1 3Di byte + 1 AA byte) * (database residues)`. The README gives the scale directly: the 54M AFDB50 entries require 151GB.

So a search against the whole AlphaFold database is a 151GB job, and that is the number to plan a cluster around.

The second option is without Cα info, and it is a single flag. By disabling `--sort-by-structure-bits 0`, the RAM requirement reduces to 35GB, and the README is honest that this alters hit ranking. That is the trade in a sentence: you can fit the database in a normal server's memory, and you accept that the ordering of the results is no longer the same as the default.

The third option is in the section that the README truncates, and the fact that there is a third suggests the answer is a middle ground rather than the two extremes.

This is where the clustering mode becomes interesting, because clustering and searching have different memory profiles. A search has to consider the whole database; a clustering run works on a result set and on the structures that survive into it, and the representative fasta and all-member fasta outputs are designed for exactly that kind of staged use.

The practical planning question is therefore not whether Foldseek is fast, it is what you can hold in memory. A group with a 256GB node can search AFDB50 with the default settings, a group with 64GB can search it with the structure bits disabled and a changed ranking, and a group with a workstation cannot search it at all.

Building the container yourself

The Dockerfile in the repository is a cross-compilation image, and reading it tells you what the build actually needs.

The builder stage starts from `debian:bookworm-slim` and installs the toolchain: build-essential, curl, xxd, git and cmake, plus zlib1g-dev, libbz2-dev and libatomic1, and the crossbuild packages for the target architecture. When the `GPU` build argument is 1, it adds the NVIDIA CUDA repository for Debian 12 and installs cuda-nvcc, cuda-cudart-dev, libcublas-dev and ninja-build.

The architecture handling is explicit. On arm64 the build uses aarch64-linux-gnu-gcc and g++ with `-DHAVE_ARM8=1`, and on x86_64 the AVX2 build configures with `-DHAVE_AVX2=1`, `-DHAVE_MPI=0`, `-DHAVE_TESTS=0` and `-DFORCE_STATIC_DEPS=1`, and uses Ninja as the generator. The presence of `-DHAVE_MPI=0` shows that there is an MPI build option, which is what you would enable for a multi-node cluster search.

The Rust toolchain is installed with rustup using a minimal profile and a default host of `${ARCH}-unknown-linux-gnu`, which is the language model component that the sequence search path needs.

For a user who only wants to run Foldseek, none of this matters, because the precompiled binaries and the conda package cover the common cases. This section matters for a cluster administrator who needs a build tuned to their hardware, or for a platform that is not in the precompiled matrix.

The `example/` directory with files such as `1tim.pdb.gz` and `8tim.pdb.gz` is a small test corpus, and the `regression/` directory is the test harness that the CI build runs, which is where you would look if you were changing the comparison code and wanted to know whether the results moved.

Where Foldseek is the wrong tool

There are three cases where Foldseek is the wrong answer, and the first is about the question rather than the data.

The first is when you need a detailed, interpretable alignment of two structures. Foldseek is built to find candidates quickly across enormous sets, and the alignment it returns is a summary. When the question is why two specific domains are the same fold, a dedicated structural alignment tool that gives you a superposition you can read is a better instrument, and the `TMscore` rescoring example in the README is the concession to that: use the fast search to narrow it down, then compute a proper score.

The second is a small structure collection. The overhead of a tool designed for millions of structures is not justified for a few hundred, and a simpler alignment or comparison tool will give you a more interpretable answer in less time.

The third is the hardware. A cluster without AVX2, a workstation without the memory for the database, or a GPU generation the binaries do not support, all of which put the tool out of reach for reasons that have nothing to do with whether it is a good tool.

The alternative approach, and the one to weigh against, is a sequence based search. Searching sequences with a fast homology tool tells you which proteins are evolutionarily related, and it works on a laptop, and it is what most structural questions are actually asking. Foldseek's advantage is the cases where sequence similarity and structural similarity diverge, which is common in the predicted structure era, where remote homologues and folds shared by unrelated sequences are exactly the interesting results. The difference in approach is that a sequence search answers a narrower question much more cheaply, and Foldseek answers the structural question directly at a cost in memory and hardware.

For a researcher deciding which to use, the practical test is simple. If the folds you care about are shared by sequences that a homology search would miss, Foldseek earns its memory. If not, the sequence search is the cheaper answer to the same question.

Editorial conclusion

Adopt Foldseek if your question is whether two predicted structures are the same fold, at a scale where an alignment tool cannot keep up, because that is the case the publications cover and the case the tool is built for. Do not adopt it if you need motif level detail on a handful of structures, where a dedicated alignment tool is easier to interpret, and do not plan on running it against the full AlphaFold database on a machine with a laptop's memory. Verify three things first: the memory formula for your database size, which the README gives as 6 bytes Cα plus one 3Di byte plus one amino acid byte per residue, whether your GPU is supported by the binary you install, since the precompiled builds and the conda package do not work on Volta or Pascal, and whether the structure bits option is acceptable for your use, since disabling it cuts the memory requirement sharply but changes hit ranking.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. steineggerlab/foldseek on GitHub