VSEARCH: a vectorized alternative to USEARCH for sequence clustering

What VSEARCH set out to be, and against what

VSEARCH was created with a stated aim: to create an alternative to the USEARCH tool developed by Robert C. Edgar. The design goals are listed explicitly in the project documentation, and they are worth reading as a specification rather than as marketing. Open source code under an appropriate open source licence. Free of charge. A 64-bit design that handles very large databases and much more than 4GB of memory. And then two performance claims: as accurate or more accurate than USEARCH, and as fast or faster.

Those last two are goals the project sets for itself, not independent measurements, so treat them as intent.

The implemented tool supports de novo and reference based chimera detection, clustering, full-length and prefix dereplication, rereplication, reverse complementation, masking, all-vs-all pairwise global alignment, exact and global alignment searching, shuffling, subsampling and sorting. It also handles FASTQ file analysis, filtering, conversion and merging of paired-end reads.

The users are amplicon and metabarcoding researchers, and the topics the project carries, from metagenomics and clustering to sequence-alignment and chimera, describe the domain accurately.

Vectorization and an exact aligner rather than a heuristic one

The name means vectorized search, and the mechanism is stated plainly: the tool takes advantage of parallelism in the form of SIMD vectorization as well as multiple threads to perform accurate alignments at high speed.

The second decision matters more for results than for speed. VSEARCH uses an optimal global aligner, full dynamic programming Needleman-Wunsch, in contrast to USEARCH which by default uses a heuristic seed and extend aligner. The project states that this usually results in more accurate alignments and overall improved sensitivity, recall, especially for alignments with gaps.

That is a real behavioural difference between the two tools, not just an implementation detail. A heuristic aligner is faster because it skips regions of the alignment matrix, and it can miss the optimal placement. The full dynamic programming aligner always finds the optimal global alignment under its scoring scheme, at a cost in time that the SIMD and threading work is designed to offset.

The consequence for a user is that results computed by the two tools are not necessarily identical, even on the same input, and a pipeline that changes aligner will change downstream clustering.

Building from the source release

The release page carries a source distribution, and the documented build sequence is short. You fetch the tarball, unpack it and configure with optimisation flags:

wget https://github.com/torognes/vsearch/releases/download/v2.32.0/vsearch-2.32.0.tar.gz
tar xzf vsearch-2.32.0.tar.gz
cd vsearch-2.32.0
./configure CFLAGS="-O3" CXXFLAGS="-O3"
make ARFLAGS="cr"
sudo make install

The documentation recommends running configure with the options CFLAGS="-O3" and CXXFLAGS="-O3", and the requirement is a GCC C++ compiler or clang plus make. The source distribution ships the generated build files, configure and Makefile.in among them, so GNU autoconf and automake are not needed for a release tarball. They are needed for a git checkout, which does not track those files, in which case you run ./autogen.sh first with autoconf 2.63 or later. The same applies after editing configure.ac or a Makefile.am.

You can also change the install location with the --prefix=DIR option to configure. If zlib and bzip2 are present on the system they are detected automatically and compressed input support is included, and that support can be switched off with --disable-zlib and --disable-bzip2. The manual pages are generated from markdown with pandoc, and a release tarball ships them ready-made while a git checkout needs pandoc present; configure reports whether it found pandoc, and --disable-manpages asks for that behaviour explicitly.

Out-of-tree builds and the Docker image

The project supports VPATH builds, where configure and make run from a separate, initially empty directory instead of the source tree. All object files, libraries and the final binary are then written under that build directory, leaving the source tree pristine, and several builds such as debug and release, or different cross-compilation targets, can coexist from a single checkout:

mkdir build && cd build
../configure CFLAGS="-O3" CXXFLAGS="-O3"
make ARFLAGS="cr"

That property is what makes the containerised build practical, and the repository ships a Dockerfile that does exactly this. The image is based on alpine:latest, installs the toolchain, runs the autogen and configure steps, builds, installs, and then removes the build tools it no longer needs:

FROM alpine:latest
WORKDIR /opt/vsearch
COPY . .
RUN apk add --no-cache \
        libstdc++ zlib-dev bzip2-dev \
        autoconf automake make g++ && \
    ./autogen.sh && \
    ./configure CFLAGS="-O2" CXXFLAGS="-O2" && \
    make clean && \
    make && \
    make install && \
    make clean && \
    apk del autoconf automake make g++ && \
    rm -rf /opt/vsearch
ENTRYPOINT ["/usr/local/bin/vsearch"]

Note the image uses -O2 rather than the -O3 the documentation recommends for a normal build, and that the entrypoint is the vsearch binary itself, so the container is invoked as a tool rather than as a shell.

Where VSEARCH stops short of USEARCH

The compatibility story is good but not complete, and the gaps are specific.

Most of the nucleotide based commands and options in USEARCH version 7 are supported, as well as some in version 8. The same option names as in USEARCH version 7 are used deliberately, in order to make VSEARCH an almost drop-in replacement. The word almost is in the documentation.

Two features are explicitly missing. VSEARCH does not support amino acid sequences, and it does not support local alignments. The project notes that these features may be added in the future. That is the hard boundary for adoption, and it is not a matter of quality: a protein pipeline or a local alignment workflow cannot be ported here at all.

There is also a platform asymmetry to keep in mind. Prebuilt binaries exist for GNU/Linux on x86_64, POWER8, ARMv8, little-endian 64-bit RISC-V and little-endian 64-bit MIPS, for macOS 10.9 or later on Intel and Apple Silicon, and for 64-bit Windows 7 or higher on x86_64. The compatibility table marks MIPS 64 LE on GNU/Linux as not tested, and shows no macOS or Windows binary for ARMv8, POWER8, RISC-V or MIPS.

SIMD coverage and the performance caveat on rarer architectures

The acceleration story is architecture specific, and the project is careful about it. VSEARCH contains native SIMD code for three processor architectures: SSE2 and SSSE3 for x86, AltiVec with VMX and VSX for POWER, and Neon for ARM.

For everything else, the tool uses the SIMD Everywhere, SIMDe, library to enable building on riscv64, mips64el and other little-endian architectures, and the documentation states plainly that the performance may be lower than a native implementation. On RISC-V and MIPS you therefore get a working binary with vectorisation emulated through a compatibility layer, not the same throughput as an x86 or ARM machine.

That matters when you are sizing a cluster or a pipeline runtime across heterogeneous hardware, which is the normal situation in this field.

The source compiles correctly with gcc versions 4.8.5 to 14.0 and with llvm-clang 3.8 to 19.0, and it should also compile on FreeBSD and NetBSD systems. On Debian and similar Linux distributions the packages needed are autoconf, automake, g++, libbz2-dev, make and zlib1g-dev, with libsimde-dev added for riscv64 or mips64el builds. Compiled input handling is straightforward: VSEARCH can read input query and database files compressed with gzip or bzip2 when those libraries are available.

A first search, the licence and the release cadence

The documented example is a global alignment search. Given a query file and a database file, VSEARCH identifies sequences in database.fsa that are at least 90% identical on the plus strand to the queries in queries.fsa and writes the results to alnout.txt:

./vsearch --usearch_global queries.fsa --db database.fsa --id 0.9 --alnout alnout.txt

The output goes to the file named by --alnout, and the identity threshold is set with --id, so the first thing to do with any new data is to change the threshold and the output name deliberately rather than by habit.

On the licence, this is a case where the label on the repository is unhelpful. GitHub classifies it as a custom licence it cannot categorise, and the repository root carries three files: LICENSE.txt, LICENSE_GNU_GPL3.txt and a CITATION.cff. The presence of a GNU GPL v3 file alongside the main licence file suggests a dual arrangement, but the project does not summarise it in the README, so read LICENSE.txt before you ship VSEARCH inside a commercial pipeline. The repository also carries LIBRARY_API.md and an api_examples/ directory, which indicates a library interface exists alongside the command line tool, and the api_examples directory is the place to look for how it is meant to be called.

On releases, the tags are frequent and the version numbering is a plain decimal scheme: v2.32.0 published on 2026-09-18, v2.31.0 on 2026-04-29 and v2.30.6 on 2026-03-27. The last push to the repository was on 2026-10-10 and the repository is not archived, so bug fixes land on master between tagged versions. Help is available in the online documentation, in the manual pages installed by make install where you start with man vsearch, and on the VSEARCH Web Forum.

Editorial conclusion

Adopt VSEARCH if you are working with nucleotide amplicon data and want an exact global aligner, a 64-bit design that handles databases much larger than 4GB, and a tool that can be built from source with the same option names as USEARCH 7. Do not adopt it if your pipeline depends on amino acid sequences or local alignments, since neither is supported, or if you need a single algorithm for both protein and nucleotide work. Before switching an existing pipeline over, check the option names against your current USEARCH version, because the project states that most USEARCH 7 commands are supported along with some from version 8 rather than all of them, and confirm the alignment mode your analysis expects, since VSEARCH uses exact global alignment by default where USEARCH defaults to a heuristic.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. torognes/vsearch on GitHub