# DIAMOND builds with cmake and links sqlite3, zstd and zlib by default > DIAMOND is a C++ sequence aligner for protein and translated DNA searches that is BLAST compatible, and the two things an adopter checks first are its alignment sensitivity profile and its build dependencies. The container recipe is short enough to read as documentation: g++, cmake, zlib1g-dev, libzstd-dev and libsqlite3-dev, then a release build with make -j on every core. **bbuchfink/diamond** — Accelerated BLAST compatible local sequence aligner. - Repository: https://github.com/bbuchfink/diamond - Stars: 1,335 · Forks: 207 - Language: C++ - License: GPL-3.0 - Published: 2026-10-17 · Updated: 2026-10-17 · Language: en - Canonical page: https://hysenlabs.com/projects/bbuchfink-diamond ## The speed claim is a range, and the range is the point The key features list opens with a number rather than a capability, and the shape of the number is informative. DIAMOND is described as a sequence aligner for protein and translated DNA searches, designed for high performance analysis of big sequence data. The first feature is pairwise alignment of proteins and translated DNA at 100x to 10,000x speed of BLAST. A range that wide is not a single benchmark. It means the advantage varies enormously with what you are searching and against what, which in practice follows from query size, database size, the sensitivity settings and the sequence composition. A database of a few thousand closely related sequences is not the workload that produces five figures of speedup, and a large diverse database with permissive sensitivity is. The feature that often matters more in practice is the fourth: low resource requirements and suitability for running on standard desktops or laptops. An aligner suitable for a laptop can shorten the feedback loop. The other three features are where the tool has grown beyond search. Clustering protein sequences is listed with high sensitivity and scalability, including linear-time scaling and parallelization across many compute nodes, which is a different algorithm from pairwise alignment and is backed by a separate publication. Frameshift alignments for long read analysis address the case where a sequencing error shifts the reading frame and a fixed-frame aligner cannot see the homology. Output formats include BLAST pairwise, tabular and XML, plus taxonomic classification, which is the compatibility surface that lets it replace BLAST in an existing pipeline. ## The Dockerfile tells you what the binary links against The container recipe is more informative than a dependency list would be, because it shows the build rather than naming packages abstractly. The build stage is `ubuntu:latest` with a noninteractive frontend and a set of packages installed in one layer: ```bash apt-get install -y g++ automake cmake zlib1g-dev git libzstd-dev libsqlite3-dev ``` That list is the answer to what DIAMOND needs. The build stage installs a C++ compiler, autotools, CMake, git, and development packages for zlib, zstd and sqlite3. The recipe installs the sqlite3 development package before compiling DIAMOND. The build itself is a release CMake configure followed by a parallel make: ```bash cmake -DCMAKE_BUILD_TYPE=Release .. make -j $(nproc --all) && make install ``` `nproc --all` rather than `nproc` means it uses all detected cores including SMT siblings, which is a reasonable default for a build that saturates a core on most files. The runtime stage copies exactly one file, `/usr/local/bin/diamond`, into a fresh `ubuntu:latest` with no additional packages, and sets `ENTRYPOINT ["diamond"]` with `CMD ["help"]`. So the image is small and the default command prints help rather than starting something. That is also a design that fails loudly in a useful way. If the binary dynamically links libsqlite3, zlib or libzstd, the runtime stage is missing them and the image will not work, which means either the libraries are linked statically or the recipe is incomplete. Nothing in the README resolves it, so if you build the image yourself, run it and find out before you rely on it. The repository has a `CMakeLists.txt` at the root as the build definition, a `.cirrus.yml` for Cirrus CI, a `CITATION.cff` for citation metadata, and a `TRADEMARKS` file alongside the LICENSE. ## DeepClust is a different algorithm, not a faster mode The publication list is the clearest statement of what DIAMOND has become, and one entry changed the citation guidance. The most recent is Buchfink, Barbé, Ashkenazy, Reuter, Kennedy and Drost, Clustering the protein universe of life using DIAMOND DeepClust, in Nature Methods volume 23, pages 724 to 727, in 2026. Then Buchfink, Reuter and Drost, Sensitive protein alignments at tree-of-life scale using DIAMOND, in Nature Methods 18, 366 to 368, in 2021. And then the instruction that will save you an awkward footnote: the original publication, Buchfink, Xie and Huson, Fast and sensitive protein alignment using DIAMOND in Nature Methods 12, 59 to 60 in 2015, is to be cited only until version v0.9.25. The README directs users to cite the original 2015 methods paper only until version v0.9.25, lists the 2021 paper on protein alignments and the 2026 paper on clustering, and identifies the latter as the original publication to cite until v0.9.25. The DeepClust publication also tells you something about scale. Clustering the protein universe of life is an operation on an entire reference database, and the feature list's claim of linear-time scaling and parallelization across many compute nodes is the property that makes it tractable. If your use case is clustering rather than pairwise search, you are using a different tool from the one most people install DIAMOND for, and the citation is the giveaway. The project also maintains a `diamond-data` repository hosting the coat of arms image and a `citations.json` file that feeds a dynamic citation-count badge in the README, which is a small piece of automation for a bioinformatics project. ## Distribution: conda, containers, Galaxy and a manual build Four distribution routes are advertised, and choosing between them is mostly a question of who maintains the environment. Bioconda is the badge in the README and the package is `diamond` in the `bioconda` channel. The README includes Bioconda badges for the diamond package. The repository contains the Dockerfile described above, while a downloads badge in the README points at the GitHub releases. The European Galaxy server hosts DIAMOND as a tool, linked with a `bg_diamond` tool id, which means you can run it inside Galaxy without installing anything. That matters for people whose groups run analyses through a shared server rather than on their own machines. The fourth is building from source with CMake, which the CI badge confirms is exercised, with a workflow named `cmake.yml`. There is also a wiki at the repository, and the README points to it for the online documentation rather than duplicating it. Support and community run through GitHub: the issue tracker for malfunctions and GitHub Discussions for questions, comments and feature requests, plus live support on Discord, which the README invites directly with the line Don't be too shy to ask! The project states plainly that DIAMOND is actively supported and developed software. The maintenance record supports that. The repository is not archived, the last push was on 2026-09-29, and the recent releases are v2.2.8 on 2026-09-20, v2.2.7 on 2026-09-14 and v2.2.6 on 2026-09-02, which is a fortnightly patch cadence. ## The comparison that matters is sensitivity, not speed DIAMOND is compatible with BLAST in its output, and it is not equivalent to BLAST in its results. Understanding that difference is the whole evaluation. The description calls it an accelerated BLAST compatible local sequence aligner, and the compatibility word is doing specific work. BLAST pairwise, tabular and XML output formats are supported, so a pipeline that parses DIAMOND output can consume it with the code it already has. That provides output-format compatibility, but whether existing scripts can use it unchanged still depends on how they parse the output. It is not algorithmic equivalence. The README gives a speed range but does not explain which implementation choices produce it. The settings that produce a fast run and the settings that produce a complete one are not the same run, and the tool's sensitivity is described in its own publication as the subject of study, not asserted as BLAST-identical. The practical consequences for a pipeline are specific. If your downstream analysis counts hits, a missed homolog changes the count. If you assemble a metagenome, a missed gene changes the assembly. If you simply annotate a handful of sequences and eyeball the top hits, the difference is unlikely to matter and the speed is a pure win. Those are different use cases and the README does not draw the line for you. The other comparison is against the alternatives. Other accelerated aligners exist, and against a metagenomic scale database a profiler will tell you which one is faster on your data, since speed ratios depend on database composition. The specific claim in the README about linear-time clustering scaling with parallelization across compute nodes is the one that has no obvious equivalent elsewhere, and it is the one to test first if clustering is what you need. ## Conclusion DIAMOND fits a metagenomics or protein-search pipeline where BLAST is the bottleneck and you have downstream tooling that already parses BLAST tabular output. Evaluate sensitivity for your specific sequence type, because the README states a speed range but does not claim identical hits. Verify first whether your existing parameter set transfers, since the compatibility is with the output format and the command surface rather than a guarantee of identical hits. ## FAQ ### What is DIAMOND used for? It is a sequence aligner for protein and translated DNA searches, designed for high performance on big sequence data. It also does protein sequence clustering with linear-time scaling and parallelization across compute nodes, frameshift alignments for long read analysis, and taxonomic classification. ### How do I build DIAMOND from source? With CMake. The Dockerfile installs g++, automake, cmake, zlib1g-dev, libzstd-dev and libsqlite3-dev, then runs `cmake -DCMAKE_BUILD_TYPE=Release ..` followed by `make -j $(nproc --all) && make install`. The build definition is the CMakeLists.txt at the repository root. ### Which paper should I cite when using DIAMOND? The README states that the original 2015 Nature Methods paper is to be cited only until version v0.9.25. The relevant references are the 2021 Nature Methods paper on sensitive protein alignments at tree-of-life scale for the aligner, and the 2026 Nature Methods paper on DIAMOND DeepClust for clustering. ### Where can I get DIAMOND as a package? On Bioconda as `diamond` in the bioconda channel, as a Docker image, through the European Galaxy server as tool `bg_diamond`, or by building from source. A downloads badge in the README points at the GitHub releases. ### Is DIAMOND output compatible with BLAST? The output formats include BLAST pairwise, tabular and XML, so existing scripts that parse BLAST output can consume DIAMOND output. The README describes the tool as BLAST compatible in that interface sense, at 100x to 10,000x the speed of BLAST for pairwise alignment. ### What license is DIAMOND released under? GPL-3.0, with the LICENSE file at the repository root and a separate TRADEMARKS file. The project is maintained by Dr. Benjamin J. Buchfink, supported by the Max Planck Society for the Advancement of Science. ## Sources - [bbuchfink/diamond on GitHub](https://github.com/bbuchfink/diamond) - [Issues](https://github.com/bbuchfink/diamond/issues) - [License: GPL-3.0](https://github.com/bbuchfink/diamond/blob/master/LICENSE) - [README](https://github.com/bbuchfink/diamond/blob/master/README.md) - [Releases](https://github.com/bbuchfink/diamond/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bbuchfink-diamond