De Novo Genome Assembly: Choosing an Assembler

Choosing a de novo genome assembler is largely a question of read type. Short reads, long reads, and PacBio HiFi reads each expose different information about a genome’s structure, and each has assemblers built specifically around its error profile and read length. Getting this choice wrong does not usually produce an obviously broken assembly — it produces one that looks plausible but is fragmented across every repetitive region, which is exactly where a lot of biologically interesting content (transposable elements, gene family expansions, structural variants) lives.

This guide walks through the main assembler families by read type, why long reads changed what is achievable through repeats, the now-standard hybrid and polishing workflows, and how to actually judge whether an assembly succeeded once you have one — contiguity and completeness metrics, not just “did the software finish.”

What “de novo” means here

De novo assembly reconstructs a genome sequence directly from overlapping sequencing reads, with no reference genome to guide the process — as opposed to reference-guided (mapping-based) assembly, which aligns reads to an existing related genome and is a different problem with different tools. De novo assembly is necessary for novel species, highly divergent strains, or any case where you specifically want to detect structural variation the reference would mask. The core difficulty is repeats: any sequence element that occurs more than once in the genome creates ambiguity about how reads spanning it should be joined back together, and how an assembler resolves that ambiguity is the single biggest differentiator between tools and read types.

Short-read assemblers: SPAdes and the Illumina era

Illumina short-read sequencing produces highly accurate reads (well under 1% error) but short ones — typically 100–300 base pairs. SPAdes is the assembler most commonly used for isolate bacterial and small-genome short-read assembly, built around a multi-k-mer de Bruijn graph approach with dedicated repeat-resolution algorithms, and it ships with specialized pipelines for different applications: --isolate for cleanly sequenced bacterial isolates, --sc for single-cell data, --meta for metagenomes, --plasmid for plasmid recovery, and --rna for transcriptome assembly.

The structural limitation of short-read assembly is not accuracy, it is read length relative to repeat length. If a repetitive element (an rRNA operon, a transposon, a duplicated gene copy) is longer than the read — and often longer than the fragment’s insert size too — the assembler cannot tell which copy a given read actually came from, so the graph breaks at that repeat and the assembly fragments into contigs bounded by repeat junctions. This is a structural ceiling on short-read assembly, not a software bug: no amount of short-read depth resolves a repeat that is longer than the read.

In practice this means short-read-only de novo assemblies of anything larger or more repeat-rich than a compact bacterial genome (most eukaryotic genomes, repeat-dense bacterial genomes with multiple near-identical rRNA operons, anything with recent duplications) come out as thousands of contigs rather than a small number of chromosome-scale pieces. The assembly can still be useful — gene-content analysis, SNP calling against contigs — but it is not a contiguous representation of genome structure.

Long-read assemblers: Flye, Canu, and hifiasm

Long-read sequencing (Oxford Nanopore, PacBio) produces reads from a few kilobases to hundreds of kilobases, which routinely span repetitive elements that break short-read assemblies. A single long read carrying unique flanking sequence on both sides of a repeat tells the assembler unambiguously which copy it belongs to and what comes after it — this is the mechanical reason long reads dramatically improve contiguity, not a general “better data” claim. The tradeoff has historically been higher per-base error rates than short reads, which is why the assembler landscape here is split by how it handles that error.

• Flye — a widely used general-purpose long-read assembler for both Oxford Nanopore and PacBio data, built around an iterative repeat graph that resolves repeats without requiring a separate error-correction step before assembly. It is a common default choice when working with noisier long reads (standard ONT, PacBio CLR) across bacterial and eukaryotic genomes.
• Canu — one of the earlier widely adopted long-read assemblers, using overlap-based correction, trimming, and assembly stages. It remains in use, particularly on Oxford Nanopore data, though many current workflows have moved toward Flye or hifiasm depending on read type; treat “which one is currently preferred” as something that shifts with each tool’s release cadence rather than fixed.
• hifiasm — built specifically for PacBio HiFi reads (long reads with short-read-level accuracy, roughly 99.9%+), and now also supporting Oxford Nanopore R10 data via an --ont mode. Because HiFi reads combine length with high per-base accuracy, hifiasm can resolve repeats and distinguish haplotypes directly from the read set, producing haplotype-resolved assemblies without a separate polishing pass in many cases. It is the standard choice specifically for HiFi data, not a general substitute for Flye/Canu on noisier long-read data.

None of these should be read as a permanent “best tool” ranking. Long-read assembler development moves quickly — new releases change resource requirements, accuracy, and which read types are supported (hifiasm’s ONT support is itself a recent addition) — so check each tool’s current documentation and recent benchmarking for your specific organism and read chemistry before committing, rather than assuming last year’s recommendation still holds.

Hybrid and long-read-plus-polishing approaches

Two related but distinct strategies now dominate real projects, and it is worth keeping them separate:

Hybrid assembly combines short and long reads within the assembly step itself — long reads provide the scaffolding/contiguity through repeats, short reads contribute base-level accuracy. This was more necessary when long-read error rates were routinely several percent; it is used less often now that PacBio HiFi reads are highly accurate on their own, but remains relevant for lower-accuracy long-read data or when maximizing per-base accuracy from limited long-read depth.

Long-read assembly plus polishing is now the more common pattern for a purely long-read project: assemble from long reads alone (for contiguity), then run one or more polishing rounds using either the long reads themselves or a separate short-read dataset to correct residual base-level errors, particularly in homopolymer runs and other error-prone motifs that vary by sequencing chemistry. For HiFi-based assemblies the accuracy gap this closes is small; for standard ONT-based assemblies it is often a required step, not an optional refinement.

Which pattern applies depends on what data you actually have going in, which is why read-type-first assembler selection (rather than “pick the newest tool”) is the right framing for this whole decision.

Assessing assembly quality: did the assembler actually work?

An assembly finishing without an error is not evidence it is good. Two complementary categories of metric are the standard way to judge one:

Contiguity

Contiguity describes how much of the genome ended up in large, continuous pieces versus scattered across many short ones. The standard summary statistic is N50: sort contigs (or scaffolds) by length, and N50 is the length of the contig at which 50% of the total assembly length is contained in contigs of that length or longer. A higher N50 relative to expected genome/chromosome size generally indicates better contiguity, though N50 should be read alongside total assembly size and contig count, not in isolation — a small number of very long contigs and a long tail of short ones can both contribute to the same N50 figure.

Completeness

BUSCO (Benchmarking Universal Single-Copy Orthologs) assesses completeness independently of contiguity, by searching the assembly for a curated set of near-universal single-copy orthologous genes expected in the assembly’s broad lineage (drawn from OrthoDB reference datasets) and reporting each as complete, duplicated (a red flag for haplotype-duplication artifacts or contamination in a supposedly haploid assembly), fragmented, or missing. A high percentage of complete single-copy BUSCOs indicates the assembly captured most of the expected gene space; a high duplicated rate is a specific, useful diagnostic that a contiguity metric alone would not surface.

Running both together, rather than either alone, is the practical standard: a fragmented assembly (poor N50) can still be gene-complete for many downstream purposes, while a highly contiguous assembly can still be missing or duplicating substantial gene content if the underlying reads or assembly parameters were wrong for the sample.

A practical read-type checklist

• Short reads only, small/simple genome (e.g. a bacterial isolate): SPAdes is a reasonable default; expect fragmentation at rRNA operons and other repeats.
• Standard long reads (ONT, PacBio CLR), noisier data: Flye or Canu, generally followed by a polishing step against short reads if base-level accuracy matters for your downstream use.
• PacBio HiFi reads: hifiasm is the purpose-built choice, often without a separate polishing round.
• Mixed short- and long-read data, or long reads with a higher error rate than you want to carry into the final assembly: a hybrid approach or a long-read-first assembly with short-read polishing.
• Whatever you choose: report both a contiguity metric (N50, contig count) and a completeness metric (BUSCO) alongside the assembly, and re-check current tool documentation before committing — this is a fast-moving area and yesterday’s recommended default is not a permanent one.

Once an assembly is finished, submission conventions and downstream data handling follow the same infrastructure regardless of which assembler produced it — see GenBank for assembled sequence deposition and submitting sequence data to NCBI SRA for the underlying raw reads, which are typically deposited alongside or before the assembly itself. Read alignments generated during polishing or downstream analysis are commonly stored in the formats compared in SAM vs BAM vs CRAM. For the sequencing side of this decision — choosing a platform before you ever reach assembly — see Illumina vs Nanopore and the broader next-generation sequencing service buying guide. Assembly choices also feed directly into the data management planning covered in genome projects and research data management, and researchers new to the field generally may find the orientation in What Is Bioinformatics? useful context.

Frequently asked questions

What is the difference between de novo assembly and reference-guided assembly?

De novo assembly builds a genome sequence from scratch out of overlapping reads, with no existing genome to guide it. Reference-guided (mapping) approaches align reads to an existing related genome instead of assembling independently — a different, generally less computationally demanding problem, but one that cannot discover structural differences the reference doesn’t already represent.

Do I need long reads to do de novo assembly at all?

No — short-read-only assembly with a tool like SPAdes is standard and sufficient for many purposes, particularly small, low-repeat-content genomes such as many bacterial isolates. Long reads become important specifically when you need contiguity through repetitive regions that are longer than your short reads, which is most of the time for eukaryotic genomes and repeat-dense microbial genomes.

Can SPAdes assemble long reads?

SPAdes was built primarily for Illumina (and IonTorrent) short reads, but most of its pipelines accept supplementary PacBio or Oxford Nanopore long reads as additional input for hybrid assembly. It is not the tool of choice for a long-read-only project — Flye, Canu, or hifiasm are built for that role depending on read type.

How do I choose between Flye, Canu, and hifiasm?

Start from the read type you actually have: hifiasm for PacBio HiFi data specifically; Flye or Canu for standard (noisier) Oxford Nanopore or PacBio CLR reads, with Flye generally the more common current default for that category. Because all three tools update regularly, check each project’s current documentation and recent independent benchmarks for your organism before finalizing a choice rather than relying on a fixed ranking.

What does a BUSCO “duplicated” result mean?

A high duplicated rate for genes expected to be single-copy usually indicates the assembly has split what should be one haplotype’s sequence into separate, redundant contigs — common in unresolved heterozygous regions, contamination, or an assembly that hasn’t properly collapsed a diploid genome to a single representative sequence. It’s a specific diagnostic that a contiguity metric like N50 will not reveal on its own.

Is there a single “best” genome assembler?

No, and treating this as a fast-moving area is the correct default rather than an exception. The right assembler depends on read type (short, standard long-read, or HiFi), genome repeat content, and project goals (speed vs. haplotype resolution vs. maximum accuracy), and the specific tools considered best-in-class for each category have changed multiple times as sequencing chemistries and assembly algorithms have improved. Re-check current documentation and recent benchmarks rather than assuming a past recommendation still holds.