Compare: Overview · Feature Matrix · Cost · Benchmark · Alternatives
Full feature matrixFind out which pipeline answers your research question.
Four mechanisms explain most of where spcfy differs from a generic pipeline. The matrix further down puts them, and everything else, next to MAP, mBRAVE, MetaWorks, QIIME2, nf-core/ampliseq and Apscale.
Hit selection that accounts for coverage
A BLAST search returns hundreds of hits, and the highest raw identity can be a mislabelled record or a short partial match. SPARK weighs three things. Grade-%, which takes half its own value from how well the hit covers your query, counts for 67%. How specific the assignment is, species before genus before family, counts for 30%. How many of the top 500 hits agree counts for 3%, a tie-breaker. The alt hit stays on the row, so ambiguity stays visible instead of being resolved silently.
No single database decides alone
For CO1, each sequence is identified three times over: a BLAST search against BOLD, a BLAST search against NCBI, and a naive Bayesian classifier trained on MIDORI2. The three results get reconciled into a graded consensus. If BOLD and NCBI both say Homo sapiens and the classifier only resolves Homo, spcfy reports the species with a grade of B, not the genus with an A: depth is worth more than a clean grade. The classifier's job is to arbitrate between the two searches, not to outvote them.
A portable identity for any amplicon
SPIN stands for spcfy Index Number, built on the same idea as a Barcode Index Number in BOLD: an algorithmically defined unit that tracks a biological entity, whether or not it carries a formal species name. Unlike a BIN it is not limited to CO1. OTU labels are usually per-project, the same organism is OTU_42 here and OTU_17 there. spcfy clusters every OTU and ESV it has ever produced into SPINs, using SWARM, VSEARCH and an in-house algorithm. Each SPIN carries a stable id and the metadata of its members, so merging two reports joins them on that id and shows which reads are shared between which samples, across time, sites or labs, without re-processing anything.
Clustering follows the marker
Most data is clustered into OTUs: VSEARCH's centroid-based algorithm for 16S bacterial, ITS and very large CO1 jobs, SWARM's more deterministic algorithm for most CO1 jobs. Centroids collapse sequences above 97% similarity into one cluster, which is also what absorbs most PCR and sequencing noise. For 12S and 16S vertebrate data, the markers used on water eDNA, spcfy denoises into ESVs with UNOISE3 instead. SPIN works across both, and every tool version is recorded in your report.
Looking for a QIIME2 alternative?
If you already run QIIME2/DADA2 and are comparing alternatives because you don't want to operate the orchestration yourself, spcfy is the closest thing to a hosted equivalent, not a feature clone. It covers demultiplexing through taxonomy assignment out of the box, on curated per-marker databases, without you managing compute, database versions or parameter drift. What you give up is swapping in your own denoising or classification method. If that control matters more than the upkeep, QIIME2 stays the right tool. spcfy is for labs that do not want to run the analysis themselves at all.
Reference data behind each marker
These run on every analysis of that marker. Evidence is weighed together, but each search or classification happens against one reference at a time.
classifier trained on MIDORI2 lrRNA
NCBI (the only marker with
a consensus taxonomy)
classifier trained on MIDORI2 srRNA
NCBI
NCBI
NCBI
classifier trained on UNITE
NCBI
Two different operations sit behind this. BOLD, SILVA and NCBI are searched with BLAST, which reports percent identity, coverage and an E-value that spcfy combines into Grade-%. A classifier is not a database: it is a naive Bayesian model trained on a tree of sequences, which places your sequence on that tree and reports how much statistical support each branch has. How good that support is depends on how many sequences were available to train each node. Private reference databases are a separate feature, in development.
Markers & databases per tool
No tool covers everything equally, support does not equal validated annotation. Other established tools sit off to the side by design: OBITools, VSEARCH, Barque, Mothur, PEMA, none is a hosted no-code platform.
| Tool | Markers targeted | Databases (validated / typical) |
|---|---|---|
| spcfy | CO1 · 16S (bacterial & vertebrate) · ITS2 (fungal & plant) · 12S curated; any other marker via NCBI | curated per marker, you maintain none of them; cross-database consensus for CO1 (BOLD · MIDORI2 · NCBI). Bring-your-own DB in development. |
| MAP | CO1 (long-read focus) | BOLD, BIN-based |
| mBRAVE | CO1 (barcode markers) | BOLD reference libraries, BIN-based |
| MetaWorks | marker-agnostic (COI, 16S, ITS, …) | you supply per marker (RDP-trained classifiers) |
| QIIME2 / DADA2 | marker-agnostic | you supply: SILVA, UNITE, GTDB, BOLD, … |
| nf-core/ampliseq | marker-agnostic | you supply per marker & version |
| Apscale | marker-agnostic (metabarcoding) | you supply / own DB |
"Marker-agnostic" means the framework can process any amplicon if you provide and maintain the correct database, classifier and thresholds, not that it ships validated for each marker. spcfy will also take any marker, routed to NCBI. The difference is what comes with it: for five markers the references are curated and maintained for you, and for CO1 there is a consensus across three of them that you would otherwise have to build. That maintenance is the hidden cost on the cost page.
Analysis pipelines & platforms
spcfy, QIIME2, MAP and nf-core/ampliseq shown by default, the most-asked-about set. Expand for mBRAVE, MetaWorks and Apscale too.
| Capability | spcfy | QIIME2 | MAP | nf-core/ ampliseq | mBRAVE | MetaWorks | Apscale |
|---|---|---|---|---|---|---|---|
| Access & operation | |||||||
| Hosted, no compute of your own | ● | – | – | – | ● | – | – |
| Self-hostable / runs locally | on requestnot a standard tier | ● | ● | ● | – | ● | ● |
| No-code operation | ● | – | –CLI | – | partly | – | partly |
| Free / open source | –commercial | ● | ● | ● | ● | ● | ● |
| Analysis capabilities | |||||||
| Long-read data (ONT) | ●all markers, trimmed FASTQ input | – | ● | – | to 1500 bp | – | – |
| Short-read data (Illumina) | ● | ● | ● | ● | ● | ● | ● |
| Clustering approach | OTU (VSEARCH or SWARM) ESV (UNOISE3) for 12S & 16S vertebrate | ASV (DADA2) or OTU | BIN (COI 658bp) | ASV (DADA2) or OTU | BIN (COI 658bp) | ASV (DADA2) | OTU (VSEARCH) |
| Parameters you set yourself | twosingletons, read length | ● | ● | ● | partly | ● | ● |
| Coverage-aware hit selection (SPARK) | ● | – | – | – | – | – | – |
| Cross-database consensus taxonomy | ●CO1 today | – | – | – | – | – | – |
| Portable identity across runs (SPIN) | ● | – | BIN only | – | BIN only | – | – |
| Bring your own curated database | in development | ● | ● | ● | ? | ● | own DB |
| Governance & comparability | |||||||
| Locked audit trail (pipeline / DB version) | ● | manual | manual | ● | partly | manual | manual |
| Compare across projects / time / labs | ● | – | – | – | partly | – | – |
| Full export of your data, no lock-in | ●tables, OTU FASTA, your FASTQs | ● | ● | ● | partly | ● | ● |
| Natural-language querying | alpha · spcfAIinbound or via MCP | – | – | – | – | – | – |
| Speed & experience | |||||||
| Fast turnaround, hands-off | ●hours for typical runs | –your compute | 36h**one ONT run, one machine | –your compute | slower | –your compute | –your compute |
| Usability (no bioinformatics needed) | ●preprint: "user-friendly" | – | – | – | challenging UI | – | partly |
Compare: Overview · Feature Matrix · Cost · Benchmark · Alternatives