dada2 infers exact sequence variants from amplicon reads instead of clustering them

Exact variants rather than clustered units, and why that argument was published

The package's one-line description in the README is precise about what it does: exact sample inference from high-throughput amplicon data, resolving real variants differing by as little as one nucleotide.

That distinction is the project's central claim, and it is not a new one, because the evidence is in the publication list rather than in the README prose. Four papers are linked, and the third is the argument: Exact sequence variants should replace operational taxonomic units in marker-gene data analysis, published in ISMEJ in 2017.

The framing of that title matters. It is not that exact variants are a better implementation of OTUs, it is that they should replace them as the unit of analysis. An operational taxonomic unit is a cluster of sequences defined by a similarity threshold, which means the unit a sample is assigned to depends on a parameter the analyst chose, and two analyses of the same data with different thresholds produce different units. An exact sequence variant is a specific sequence, so the unit is a property of the data rather than of the settings.

The first paper in the list is the one that introduced the package: DADA2, High resolution sample inference from Illumina amplicon data, in Nature Methods in 2016. The fourth extends the same idea to a specific marker, High-throughput amplicon sequencing of the full-length 16S rRNA gene with single-nucleotide resolution in Nucleic Acids Research in 2019.

The second paper sits alongside and is arguably the one most practitioners will use: the Bioconductor workflow for microbiome data analysis, from raw reads to community analyses, published in F1000 Research in 2016. A workflow paper rather than a methods paper, which tells you the project was designed to be a step in an existing analysis pipeline rather than a pipeline of its own.

The primary language is R, the licence is LGPL-3.0, the default branch is master, and the homepage is benjjneb.github.io/dada2. The topics list covers amplicon, bioconductor, bioinformatics, metabarcoding, metagenomics, microbiome and taxonomy.

Installation through Bioconductor, with a source path for the newest features

The installation instructions are short, and they give two routes with an explicit reason for choosing the second.

The package binaries are available through Bioconductor, and the README gives the R snippet that installs it:

## try http:// if https:// URLs are not supported
if (!requireNamespace("BiocManager", quietly=TRUE))
    install.packages("BiocManager")
BiocManager::install("dada2")

The first two lines bootstrap BiocManager if it is missing, and the third installs the package. The comment about trying http:// if https:// URLs are not supported is a practical note for people behind a proxy that blocks TLS, and it is the kind of thing that only appears in documentation written by someone who has hit it.

The second route is installing from source, and the README gives the reason: to get the latest and greatest new features. The instructions are on a separate page, dada-installation.html on the project site.

Those two routes are not equivalent, and the reason is worth understanding. Bioconductor is a distribution with release branches tied to R versions, so a Bioconductor install gives you a package version that was frozen and tested against a specific R release. A source install gives you the development version, which means the newest features and also the newest breakage. For a published analysis, the binary route is the one that matches what other people will run; for exploratory work at the edge of the package's capability, the source route is worth the extra setup.

This is also where the versioning detail in the repository metadata becomes relevant. The recent releases listed are v1.26 from 2022-11-03, v1.20 from 2021-06-30 and v1.18 from 2020-12-07, and the last push to the repository was on 2026-07-31. So the tagged releases stop in 2022 while work continues on the branch, which is the normal Bioconductor pattern for a package in long-term maintenance, and it is why the README points you at the issue tracker for what is coming next.

The package layout: R code, compiled sources, data, man pages and vignettes

The top-level entries describe a conventional R package with a few things worth noting.

There is an R/ directory for the package code, a src/ directory for compiled sources, and inst/ for installed artefacts. A src/ directory in an R package means part of the package is compiled rather than interpreted, which for an amplicon inference package is not a detail. DADA2's inference algorithm and its sequence alignment are the kind of work that is written in C++ and called from R, and the performance characteristics of the package follow from that division.

There is a data/ directory, which is where small example datasets shipped with a package live, and a vignettes/ directory. The vignettes are the most interesting part of the layout for a new user, because they are the executable documentation: a vignette is a document that is rebuilt when the package is built, so the code in it is run and its output checked. For a package whose pipeline takes a long time to run on real data, vignettes with small datasets give a reader something they can actually execute.

The man/ directory holds the Rd documentation that becomes the package manual, and the README links to that manual as the dada2 R package manual hosted on Bioconductor, pointing at the manual for Bioconductor 3.6. That is a versioned link, which tells you the manual moves with the release branch and that a link for a newer branch would be a different URL.

The DESCRIPTION and NAMESPACE files are the package metadata and the export declarations. The.Rbuildignore file controls what is left out of the built tarball, and.travis.yml is the older hosted continuous integration configuration that predates GitHub Actions, matching the era of the 2022 releases. There is also a NEWS file, which is the conventional changelog location for an R package.

The README points to the DADA2 website for the most detailed and up-to-date documentation, and that split is deliberate: the package ships the reference manual, and the site carries the tutorial walkthrough of the DADA2 pipeline on paired end Illumina Miseq data.

Where the documentation actually lives, and how features get planned

Four documentation locations are given, and they have different jobs.

The first is the DADA2 website, which the README calls the source of the most detailed and up-to-date documentation. The second is the tutorial walkthrough of the DADA2 pipeline on paired end Illumina Miseq data, which is the document a new user should follow. The third is the R package manual on Bioconductor, which is the reference for the functions. The fourth is the front page of the site, described as further documentation.

Two things are conspicuously absent from the repository. There is no pipeline documentation in the README itself, and there is no changelog entry in the README either. Both live elsewhere, the walkthrough on the site and the changelog in the NEWS file. For a package this old in release terms, that means the version history is in the installed package rather than on the web front page.

The feature planning process is the most unusual thing the README describes, and it deserves a mention because it tells you how the project is governed. Planned feature improvements are publicly catalogued at the main DADA2 development site on GitHub, specifically on the Issues page. If the feature you are hoping for is not listed, you are welcome to add it as a feature request issue on that page, and the request will be publicly available and listed on the page.

So the roadmap is the issue tracker, and it is bidirectional: users search it to see whether something is planned, and they add to it when it is not. Bugs and difficulties in using DADA2 are also welcome on the same tracker, which means the same queue carries both the feature backlog and the defect reports.

That arrangement has an obvious benefit for a package whose releases come infrequently through Bioconductor. The Bioconductor release cycle is slow by design, because packages have to be tested against many R versions, so a feature you request today might be years from a tagged release. With the tracker public and current, at least you can see the state of the work.

Where dada2 sits in a marker gene analysis, and what it leaves to other tools

The workflow paper in the list is the one that describes the package in context, and its title is informative in a way the methods paper's title is not. A Bioconductor workflow for microbiome data analysis, from raw reads to community analyses, is a workflow paper, and the phrase from raw reads to community analyses describes a pipeline with more than one stage.

Read that way, dada2 is the stage that turns reads into something you can count, and the community analysis stage sits downstream of it. The package's own description fits: it resolves real variants differing by as little as one nucleotide, which is the operation that has to happen before any count-based community analysis is meaningful, because the counts are counts of variants and not counts of clusters.

That division has a practical consequence for anyone evaluating the package. If your question is how many reads of each taxon are in each sample, the package is the part that gets you there with single-nucleotide resolution. If your question is about differential abundance between groups, or about alpha and beta diversity, or about how the community differs between conditions, that is the community analysis stage, which is not this package. The README does not claim to cover it, and the vignette list and the tutorial are about the pipeline rather than about the downstream statistics.

The same logic applies in the other direction. dada2 does not do the sequencing, it does not demultiplex a flow cell, and it does not build the community tables. Those are upstream and downstream steps in a workflow that other packages in the same ecosystem cover. The topics list mentions metabarcoding and metagenomics alongside amplicon, which places the package in the amplicon branch of that space rather than at the centre of it.

For a team evaluating this, the practical question is therefore not whether dada2 is good at variant inference, which the publications make a reasonable case for, but whether the rest of their workflow is already in the Bioconductor ecosystem, because a package that resolves variants at single-nucleotide resolution is only useful if the counts it produces flow into analysis built for that resolution.

Editorial conclusion

Adopt dada2 if you are analysing amplicon sequencing data and want the analysis to be built around exact sequence variants rather than clustered OTUs, because the package's whole argument in the published literature is that the exact variant is the correct unit for marker gene data. Do not adopt it without checking the version you get, since the Bioconductor binaries are the route the README recommends and the newest tagged release listed here is 1.26 from 2022-11-03, so what you install may differ from what you read about. Verify first that the Bioconductor release you install matches your R version, since Bioconductor ships packages in versioned branches, that the system tools the source install needs are present if you build from source rather than take the binaries, and that the vignettes in the package cover the pipeline step you are running, because the README sends you to the website for the detailed walkthrough rather than documenting the pipeline itself.

Frequently asked questions

Official sources

1. benjjneb/dada2 on GitHub
2. License: LGPL-3.0
3. Project website
4. README
5. Releases