Downloading Sequencing Data from SRA and ENA: prefetch and fasterq-dump

Every reanalysis starts with the same unglamorous question: how do you turn an accession like SRR1234567 from a paper's methods section into actual FASTQ files sitting on your disk? The public archives hold petabytes of raw reads, but they hand them to you in a compressed, indexed container rather than the plain FASTQ your aligner wants. Getting from one to the other trips up more beginners than any downstream step, usually because they reach for the wrong tool or fight a slow download that could have been an FTP one-liner. This guide walks the two workflows that actually matter in 2025-2026: the official SRA Toolkit path (prefetch then fasterq-dump) and the direct ENA shortcuts that skip the toolkit entirely.

The Archives: SRA, ENA, and What an Accession Means

The Sequence Read Archive (SRA, hosted by NCBI) and the European Nucleotide Archive (ENA, hosted by EMBL-EBI) are two nodes of the same global network, the International Nucleotide Sequence Database Collaboration. Along with Japan's DDBJ, they mirror each other's submissions, so a run deposited at SRA also appears at ENA within a day or two. That mirroring is the single most useful fact in this whole post: if one archive is slow or serving an awkward format, the other very likely has the identical data in a friendlier one.

Accessions follow a strict prefix grammar worth memorizing. A SRR (or ENA's ERR, DDBJ's DRR) prefix is a single sequencing run — one FASTQ set. SRX/ERX is an experiment, SRS a sample, and SRP/PRJNA/PRJEB a whole study or BioProject. When a paper cites PRJNA000000, that is a project containing many runs; you resolve it to the list of SRR run accessions before downloading anything.

Installing the SRA Toolkit

The SRA Toolkit is a set of C++ command-line utilities from NCBI. The cleanest install is through conda, keeping it isolated in its own environment exactly as you would for any other tool.

conda create -n bu-sra --override-channels -c conda-forge -c bioconda sra-tools
conda activate bu-sra
prefetch --version
fasterq-dump --version

The one non-obvious step is the first-run configuration. Run vdb-config --interactive (or the newer vdb-config --prefetch-to-cwd flag) once to set where downloads land and to accept the cloud-access defaults. If you skip this, prefetch may drop .sra files into a hidden cache directory under your home folder and quietly fill your $HOME quota on a shared cluster.

Step One: prefetch the .sra Container

The recommended NCBI workflow is deliberately two steps. First, prefetch downloads the compressed .sra container — a single indexed file — using a resumable transfer protocol. Second, fasterq-dump unpacks that local container into FASTQ. Splitting the job this way means a dropped connection only costs you the download, not the expensive unpacking, and prefetch can resume a partial .sra instead of starting over.

prefetch SRR1234567 --output-directory ./sra_data

This writes ./sra_data/SRR1234567/SRR1234567.sra. To grab every run in a study, feed prefetch a list. You get that list from the archive's metadata rather than guessing accession numbers:

# resolve a project to its run accessions, then prefetch each
prefetch --option-file accession_list.txt

By default prefetch refuses files larger than 20G as a safety brake. For large whole-genome runs, raise it explicitly with --max-size 100G or the download silently stops short. This is a common cause of a .sra that unpacks into a truncated FASTQ.

Step Two: fasterq-dump to FASTQ

fasterq-dump is the modern replacement for the old fastq-dump. It is multithreaded, and it now runs in split-3 mode by default: paired mates go to _1/_2 files and any unpaired orphan reads land in a third file automatically — a genuine improvement over the legacy tool, where forgetting --split-3 silently interleaved or dropped mates.

fasterq-dump ./sra_data/SRR1234567/SRR1234567.sra \
  --split-3 \
  --threads 6 \
  --outdir ./fastq \
  --progress

For paired-end libraries this produces SRR1234567_1.fastq and SRR1234567_2.fastq. Passing --split-3 explicitly is redundant with the current default but makes scripts self-documenting; avoid --split-files instead, since it distributes reads by position rather than by biological pairing and does not handle orphans the same way. Note the resource cost: fasterq-dump needs scratch space up to 10× the final FASTQ size for its temporary files in the worst case (the NCBI rule of thumb is 8× to 10×), controlled by --temp. On a full-size run that temp directory can be tens of gigabytes, so point --temp at fast local storage, not a network mount.

The output is uncompressed FASTQ, which is bulky. Pipe it straight into pigz or gzip to save space, since every downstream tool reads .fastq.gz transparently:

fasterq-dump SRR1234567 --threads 6 --outdir ./fastq
pigz ./fastq/SRR1234567_*.fastq

If you want the theory behind why paired-end reads come in _1/_2 files and what those quality strings encode, our post on FASTA and FASTQ file formats covers it.

The ENA Shortcut: Skip the Toolkit Entirely

Here is the part most tutorials bury. ENA stores submitted reads as already-gzipped FASTQ, served over plain HTTPS and FTP. That means you can often skip prefetch, fasterq-dump, and the whole .sra round-trip and just download the finished .fastq.gz with wget or curl. No toolkit, no unpacking, no temp-space math.

The ENA path is predictable. For a run SRR1234567, the files live under a directory keyed by the accession, and you can query the exact URLs from ENA's file-report API:

curl "https://www.ebi.ac.uk/ena/portal/api/filereport?accession=SRR1234567&result=read_run&fields=fastq_ftp&format=tsv"

That returns semicolon-separated FTP paths for the R1 and R2 files. Feed them to wget:

wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR123/007/SRR1234567/SRR1234567_1.fastq.gz
wget ftp://ftp.sra.ebi.ac.uk/vol1/fastq/SRR123/007/SRR1234567/SRR1234567_2.fastq.gz

There is one important caveat: ENA serves the reads as the submitter uploaded them. Usually that is honest raw FASTQ, but occasionally a submitter uploaded pre-trimmed or otherwise processed reads, and the SRA-normalized version from fasterq-dump can differ subtly (read naming, technical reads, or spot layout). For most reanalyses this does not matter; when exact provenance matters, prefer the SRA Toolkit path so you know precisely which normalization you got.

Aspera for When FTP Crawls

For large transfers across continents, TCP-based FTP saturates poorly and a transatlantic download can crawl. Both archives support Aspera (ascp), a UDP-based protocol that fills high-latency links far more efficiently — often several times faster than wget for multi-gigabyte files. The ENA file-report API can return fastq_aspera paths alongside the FTP ones.

ascp -QT -l 300m -P33001 \
  -i $ASPERA_KEY \
  [email protected]:/vol1/fastq/SRR123/007/SRR1234567/SRR1234567_1.fastq.gz .

The -l 300m caps bandwidth at 300 Mbps, -QT enables fair-transfer and disables encryption overhead, and -i points at the public Aspera key shipped with the client. Aspera setup is fiddlier than wget, so reserve it for genuinely large jobs or slow links where the speedup pays back the setup cost.

Doing It at Scale with nf-core/fetchngs

Downloading three runs by hand is fine. Downloading three hundred, resolving projects to runs, retrying failures, and emitting a tidy samplesheet is a pipeline job. nf-core/fetchngs is a Nextflow workflow built for exactly this: give it a list of accessions at any level — SRR, PRJNA, GSE GEO series, even ENA ERR — and it resolves them, downloads via the fastest available route, and writes a ready-to-use samplesheet plus a full metadata table.

nextflow run nf-core/fetchngs \
  --input accessions.csv \
  --outdir ./results \
  -profile docker

Because it is Nextflow, it resumes cleanly after a failure with -resume and parallelizes across many runs. If you have not used Nextflow before, start with our Nextflow install guide; the same reproducibility argument applies to any large download, since a manually assembled samplesheet is exactly the kind of hand-transcription that introduces silent errors.

Verifying What You Downloaded

A download that "worked" can still be wrong. Two cheap checks catch most problems. First, confirm read counts match between mates — R1 and R2 must have identical numbers of reads for a paired library, or your aligner will error or misbehave:

echo $(zcat SRR1234567_1.fastq.gz | wc -l) / 4 | bc
echo $(zcat SRR1234567_2.fastq.gz | wc -l) / 4 | bc

Second, run the files through a QC report before trusting them. A truncated download shows up immediately as a broken read count or a mangled tail. Our walkthrough of read QC and trimming with FastQC and fastp is the natural next step, and it doubles as a download sanity check.

Practical Takeaways

• Resolve project accessions (PRJNA, SRP) to their run list first; you download runs (SRR/ERR), never a whole study in one call.
• The canonical NCBI path is two steps: prefetch fetches a resumable .sra, then fasterq-dump --split-files --threads N unpacks it to FASTQ.
• Raise prefetch --max-size above the default 20G for large genomes, or downloads truncate silently.
• For a fast, toolkit-free grab, pull already-gzipped FASTQ straight from ENA over FTP with wget; query exact URLs from the ENA file-report API.
• Use Aspera (ascp) only for large or transatlantic transfers where the setup cost pays back in speed.
• For hundreds of runs, let nf-core/fetchngs resolve, download, and write a samplesheet instead of scripting it by hand.

Once your FASTQ files pass that QC pass, you are ready for the real work. Whether that is quantification, alignment, or variant calling, everything downstream assumes clean, correctly paired reads — so it is worth getting this first step right. If you need the toolkit set up cleanly first, our guide on conda environments and Bioconda channels covers the isolated-environment approach used throughout this post.