Estimating sequencing data size correctly is the difference between a storage budget that holds and one that quietly doubles every couple of years, and it starts with a fact that is easy to state and easy to underestimate: an individual sequencing file is not large by modern standards, but sequencing data accumulates, and the accumulation is what becomes a capital problem. A single whole-genome sample produces files that a workstation can hold. A program running a few hundred whole genomes a year and retaining them produces, within a few years, a volume that requires deliberate infrastructure and a real budget line. The mistake is sizing storage against the file in front of you rather than the total those files will become.
This article gives the numbers to do the sizing properly: what each sequencing file type contains and how big it typically is, how sizes vary by application from panels to whole genomes, what compression can recover, and, most importantly, how to convert your run volume into an annual growth rate and a multi-year forecast. A caution runs through all of it, and it is worth stating plainly at the outset: these sizes vary widely by sequencing depth, read length, platform, and analysis pipeline, so every figure here is a representative range to plan against, not a specification. Measure your own files to calibrate, and treat the numbers as a starting point.
Key Takeaways
|
File Types and What Each Contains
Sequencing produces a sequence of file types as the data moves from raw output to interpreted result, and each is a different size because each contains different information. Understanding what each holds is the basis for deciding which to keep, because the retention decision is really a decision about which of these files to store and for how long.
- FASTQ is the raw output: the nucleotide sequences and a quality score for every base. It is large because it holds everything the instrument read, unaligned. It is the most complete record and the most expensive to store.
- BAM is the aligned data: the same reads mapped to a reference genome, with their alignments and quality information. A BAM can regenerate the original FASTQ, so it preserves the full information at a somewhat smaller size.
- CRAM is a more compressed form of the aligned data, storing the same information as a BAM in substantially less space by encoding it more efficiently against the reference. It is lossless with respect to the aligned data.
- VCF is the called variants: only the positions where the sample differs from the reference, which is a tiny fraction of the genome. It is small, but going from aligned data to a VCF discards information, so a VCF cannot regenerate the data it came from.
That last point drives the retention logic. Because a VCF is small but lossy and the aligned data is large but complete, the central retention question is how much of the large, complete data to keep against the possibility of reanalysis, versus relying on the small, interpreted result. That decision is developed in Data Retention, Backup, and Archiving Policy for Sequencing Labs.
Typical Sizes by Application
The single biggest determinant of file size is what you sequenced, because the amount of data scales with how much of the genome the assay covers and how deeply. A targeted gene panel reads a small set of genes and produces small files; a whole genome reads everything and produces large ones, and the difference spans several orders of magnitude. The table below gives representative sizes for common applications, with the strong caveat that these vary widely with depth, read length, platform, and pipeline.
Application | FASTQ (raw) | BAM (aligned) | CRAM | VCF |
Gene panel | MB to low GB | tens to hundreds of MB | smaller still | ~1 MB |
Whole exome | a few GB | ~5 to 15 GB | smaller | tens of MB |
30x whole genome | ~100 to 200 GB | ~80 to 100 GB | ~30 to 60 GB | ~1 GB |
Table 1. Representative file sizes by application and file type for short-read sequencing. These are planning ranges, not specifications, and vary substantially with depth, read length, platform, and pipeline. Measure your own outputs to calibrate.
Why These Numbers Vary So MuchThe ranges above are wide on purpose, because the true figures depend on variables that differ from lab to lab. Sequencing depth is the largest: a 30x genome holds roughly the data of a 30x, and a 100x tumor sample several times more. Read length, platform chemistry, and whether the FASTQ is compressed all move the raw size. On the aligned side, the pipeline, the reference, and the compression settings all matter. Treat any single number, including the ones here, with suspicion until you have measured your own files under your own pipeline. The purpose of these ranges is to let you forecast before you have that data, not to substitute for measuring it. |
CRAM and Compression Trade-Offs
Because the aligned data is the largest thing most labs retain long term, compressing it is the single most effective way to slow storage growth, and the CRAM format is how most sequencing labs do it. A study of CRAM compression across sequencing platforms found that CRAM reduces aligned file size by roughly 40 to 70% relative to BAM depending on the platform, and does so losslessly with respect to the aligned data, meaning it does not alter downstream variant calls. For a lab retaining aligned data at scale, converting BAM to CRAM can nearly halve the largest component of the storage bill without giving anything up analytically.
The trade-off is not in the data but in the access: CRAM stores the aligned data by encoding it against the reference genome, so working with a CRAM requires the matching reference, and reading it carries a modest additional processing cost compared with a BAM. For long-term retention, where files are stored far more often than they are read, that trade is strongly favorable, which is why CRAM has become the standard for archival sequencing storage. The practical implication for forecasting is that a lab planning to retain aligned data should forecast at CRAM sizes, not BAM sizes, and build the conversion into its workflow.
Lab Quality Management Certificate
The Lab Quality Management certificate is more than training—it’s a professional advantage.
Gain critical skills and IACET-approved CEUs that make a measurable difference.
Converting Run Volume to Annual Growth
The forecast that actually matters is not the size of one sample but the storage your program adds per year, and it is a straightforward calculation once the per-sample size is known. Multiply the storage retained per sample, which depends on which files you keep, by your annual sample volume, and you have the yearly storage increment. The critical move most labs miss is that this increment repeats and accumulates: each year adds its increment on top of every prior year under full retention, so the total grows year over year even at constant volume, as established in the broader data management guidance.
The per-sample retained size depends entirely on your retention choice. A lab keeping full raw and aligned data retains far more per sample than one keeping only compressed aligned data and variants. Using a representative figure of roughly 250 GB per whole genome for full retention, or roughly half that if raw data is dropped and aligned data is stored as CRAM, the annual increment for a few hundred genomes a year runs into the tens of terabytes. The exact per-sample number is yours to measure; the method is what matters, and it is the method that turns a vague worry about storage into a budget line.
Interested in life sciences?
Building a Five-Year Storage Forecast
Extending the annual increment across a retention period is what reveals the capital-scale reality the hook describes, and it is worth doing explicitly because the accumulated total is so much larger than the annual figure that intuition consistently underestimates it. The table below shows a five-year forecast at a representative full-retention footprint, illustrating how a manageable per-sample size becomes a substantial multi-year total. Substitute your own per-sample size and volume to build your version.
Whole Genomes / Year | Per Year (full retention) | 5-Year Cumulative | 5-Year with CRAM |
100 | ~25 TB | ~125 TB | ~65 TB |
200 | ~50 TB | ~250 TB | ~130 TB |
500 | ~125 TB | ~625 TB | ~325 TB |
Table 2. A five-year storage forecast at a representative full-retention footprint of roughly 250 GB per whole genome, with the CRAM column showing the effect of dropping raw data and storing aligned data compressed. Figures are illustrative planning values; substitute your own measured per-sample size and volume.
The hook makes the point concrete. A single whole genome, at a couple of hundred gigabytes, is a file you barely think about. Two hundred whole genomes a year retained for a decade is on the order of half a petabyte, which is unambiguously a capital project requiring planned infrastructure, a real budget, and a retention policy to contain it. The table also shows the two levers that control the outcome: retention policy, which determines how many years accumulate, and compression, which roughly halves the footprint. Both are covered as decisions in Managing NGS Data: Storage, Compute, Retention, and Staffing, and the way this storage cost sits within the total program budget is in How Much Does NGS Cost? Budgeting Instruments, Reagents, and Sequencing. The full operational picture of running a sequencing program is in Next-Generation Sequencing in the Lab: A Manager’s Guide to Building, Budgeting, and Scaling NGS Capacity.
This article was produced under Lab Manager's AI Editorial Guidelines.
