SRA: the Raw Sequencing Read Archive

By the end of this lesson you will know what actually lives in the Sequence Read Archive — the unassembled reads straight off a sequencer — how its four-level accession hierarchy is organised, and when a BRCA1 project needs those raw reads instead of a clean reference like NM_007294.

Every database in this module so far has handed you a finished sequence: GenBank's submissions, RefSeq's NM_007294, the variants in ClinVar. SRA (the Sequence Read Archive, NCBI's sra database) stores the opposite — the primary output of a sequencing machine, before anyone assembled or aligned it. It is the largest public database NCBI runs, measured in tens of petabytes, and it is where reproducible genomics begins.

Reads, not sequences

A read is one short stretch of DNA or RNA that a sequencer reported in a single measurement — a few hundred bases for Illumina, thousands to millions for a Nanopore or PacBio run. A single experiment produces millions of them, and on their own they are just fragments: overlapping, error-carrying, in no particular order.

SRA archives those fragments verbatim, together with each base's quality score (a number saying how confident the machine was in that call). Nothing is cleaned, aligned, or collapsed. That rawness is the entire point — SRA is a primary database: it preserves exactly what the instrument emitted, so anyone can re-run the analysis from scratch and check your work.

The study → experiment → sample → run hierarchy

A sequencing project is not one object but a nested set, and SRA gives each level its own accession. Reading from the top down:

The SRR run is the accession you will handle most: it names the reads themselves, the thing you download. An SRX experiment can hold several SRR runs (the same library sequenced more than once); an SRP study gathers many experiments and samples together.

Above all of these sit two INSDC-wide identifiers: the BioProject (PRJNA…) and BioSample (SAMN…). The SRP study links up to a BioProject; the SRS sample links up to a BioSample. So a BRCA1 tumour-sequencing project might be one BioProject at the top, resolving down through study, sample and experiment to the SRR runs holding the reads for each patient.

When you need raw reads, not a reference

Here is the decision that matters. If your question is "what does the standard BRCA1 transcript look like?", you want the curated reference — NM_007294 from RefSeq — and SRA is the wrong place entirely. A reference is one clean, agreed sequence; that is what you align against.

You reach for SRA when the question is about specific samples and how they differ from that reference:

• Variant calling — does this patient carry a pathogenic BRCA1 change? You align their SRR reads to NC_000017 and look for differences.
• Expression — how strongly is BRCA1 transcribed in these tumours? RNA-seq reads from SRA, counted per gene.
• Reanalysis — you distrust a published result, so you pull the authors' original SRR runs and redo the pipeline yourself.

In every case the reference tells you the baseline and the raw reads tell you what this biological sample actually did. You almost always need both.

Finding and pulling the reads

Because SRA is an Entrez member, the same E-utilities from the module index reach it — just point db at "sra":

from Bio import Entrez
Entrez.email = "[email protected]"      # NCBI wants an identity
Entrez.api_key = "YOUR_KEY"           # lifts you to 10 req/s

# Runs from BRCA1 RNA-seq studies
handle = Entrez.esearch(db="sra", term="BRCA1[Gene] AND RNA-Seq[Strategy]")
print(Entrez.read(handle)["Count"])   # how many matching records

That gets you the metadata — which runs exist. Getting the reads is a separate, heavier job: an SRR run can be gigabytes, so you do not fetch it through EFetch. You use the dedicated sra-toolkit (prefetch then fasterq-dump) to turn an accession into local FASTQ files. That practical workflow — and why pulling the same run from ENA over plain HTTPS is often faster — is a guide of its own: Downloading from SRA and ENA with fasterq-dump.

ENA holds the same reads

One last thing to internalise. Everything in SRA is mirrored in the ENA (the European Nucleotide Archive at EMBL-EBI), because both are INSDC members exchanging data daily. The SRR run you find on NCBI has a twin on ENA under an ERR accession, holding the identical reads. That gives you a choice of where to download from, and ENA often serves ready-made FASTQ files directly (more on ENA: the European Nucleotide Archive). For now, just remember that "raw reads" and "one archive" are not the same thing: the reads live in two places, under two prefixes, by design.