BAM vs CRAM: Choosing a Read Alignment Format for Research Data

If you need a short answer now: use BAM for routine analysis and short term sharing, and switch to CRAM for long term archival or when you can keep the reference genome nearby. This guide is for bioinformaticians, lab data managers, and graduate students who generate or process resequencing data and want to make an informed choice between these two alignment formats. The decision affects your storage costs, transfer speeds, and ability to reproduce results years later. Weigh the tradeoffs carefully with the help of authoritative resources such as the NCBI Bookshelf and EMBL EBI Training.

Understanding the difference begins with the SAM format. SAM (Sequence Alignment/Map) is the human readable text version. BAM is its compressed, indexed binary sibling that has been the standard for over a decade. CRAM is a newer compression format designed to reduce file size even further by exploiting genomic reference sequences. The core tension is between portability and storage efficiency. BAM files are self contained: every aligned read stores its sequence and quality scores fully. CRAM files achieve 30 to 60% smaller size by encoding reads relative to a reference genome, optionally discarding original quality scores stored elsewhere. As you will see in the Galaxy Training Network materials, the choice often depends on your compute environment and data retention policies.

At a Glance

Decision Criteria

When to use BAM. If you submit data to public repositories such as the NCBI Sequence Read Archive, most require BAM or FASTQ. Many downstream tools in variant calling and RNA seq pipelines still depend on BAM input. When you share data with collaborators who may not have the correct reference genome version, BAM works without hassle. For quick interactive viewing in IGV or other browsers, BAM plus its .bai index loads faster than CRAM in many environments. BAM is also the safer choice for regulatory or clinical work where every base and quality score must be preserved exactly.

When to use CRAM. If you manage large volumes of resequencing data from the same reference genome (for example, many human whole genome samples aligned to GRCh38), CRAM can cut your storage budget by nearly half. Many sequencing centers now archive in CRAM and convert to BAM only for active analysis. The Bioconductor project provides packages (e.g., Rsamtools, GenomicAlignments) that handle CRAM seamlessly. If you run the same reference in your cloud environment, CRAM reduces egress costs and transfer time. Use CRAM when you have long term storage needs and a clear reference provenance policy.

When the choice is fuzzy. Hybrid scenarios are common. You might keep an active project in BAM for six months, then archive in CRAM. You can also keep lossy CRAM files that omit quality values for raw alignments and retain a small BAM subset for recalibration steps. The decision matrix ultimately weighs reference stability against portability.

Practical Workflow

Here is a step by step implementation sequence to convert and manage both formats safely.

1. Verify your reference genome. Before any conversion, ensure you have the exact reference genome (FASTA file) used during alignment. The CRAM specification relies on the reference sequence for compression. If you use a different version later, the CRAM file may become unreadable. Download the reference from a trusted source like Ensembl or UCSC and compute its MD5 checksum.

2. Convert BAM to CRAM using samtools. The command is straightforward:

   samtools view -C -T reference.fasta input.bam -o output.cram
   

   The -C flag tells samtools to produce CRAM. This process does not change the alignment information, it only re encodes the binary.

3. Validate the CRAM file. Run samtools quickcheck or re convert a few reads back to BAM and compare:

   samtools quickcheck output.cram && echo "Valid"
   samtools view output.cram -b | samtools quickcheck - && echo "Reversible"
   

4. Index the CRAM file. Use samtools index to create a .crai file. This enables random access just like .bai for BAM.

   samtools index output.cram
   

5. Plan for lossless storage. By default, samtools writes lossless CRAM (preserving all bases and qualities). To save more space (but lose information), add --output-level 0 (which allows lossy base quality compression) or --lossy-qscores. Use these only when you are certain you will never need original quality scores again.

6. Set up automated archival. In a production environment, write a script that runs after alignment and QC: keep BAM for the first 14 days, then convert to CRAM and move to cold storage. Log the reference checksum with the file.

7. Test integrity periodically. BAM files have a built in BGZF block level checksum. CRAM files do not. Compute an MD5 hash and store it in a sidecar file. Re verify every six months if the data is precious.

Common Mistakes

Mistake 1: Losing the reference genome. Researchers often archive a CRAM file but forget to store the exact reference FASTA. Months later, they cannot extract the reads. Always tether the reference checksum or better yet, store a copy of the reference alongside the CRAM file.

Mistake 2: Assuming all tools support CRAM natively. While most modern bioinformatics tools do, some older versions of freebayes, VarScan, or custom scripts still expect BAM. Before converting an entire project, test your full pipeline against a CRAM input.

Mistake 3: Using lossy compression for clinical data. In diagnostic settings, regulatory bodies may require that original quality scores be preserved. Lossy CRAM can remove them. Even if the variant calls appear identical, the provenance chain breaks.

Mistake 4: Not indexing after conversion. A CRAM file without a .crai index is essentially a sequential archive. Random access (e.g., viewing only a chromosome) becomes extremely slow. Always index.

Mistake 5: Storing CRAM on a network filesystem without blocking. Some network protocols handle large CRAM files poorly. Use local SSDs for active analysis and move to network storage only for archival.

Limits and Uncertainty

The efficiency of CRAM depends heavily on the reference. If you align to a highly divergent genome (e.g., a non model organism with many structural variants relative to the reference), compression gains shrink. In extreme cases, CRAM can be larger than BAM because the reference encoding overhead outweighs savings. Always test a small subset.

CRAM files produced by different versions of samtools may have subtle differences. The CRAM format specification allows multiple codecs (such as bzip2, rANS, or custom). When sharing CRAM files, enforce a specific samtools version to avoid compatibility issues. The EMBL EBI training materials recommend standardizing on samtools 1.10 or later.

Another uncertainty is long term software support. BAM has been stable for two decades, CRAM is younger. While the Global Alliance for Genomics and Health (GA4GH) endorses CRAM, some institutional IT policies still prohibit its use because they cannot interpret the format without the reference. Until a universal reference registry is widely adopted, BAM remains the lowest common denominator.

Frequently Asked Questions

Q: Can I convert CRAM back to BAM without losing information? A: Yes, if you used lossless encoding and have the correct reference. Use samtools view -b -T reference.fasta input.cram -o output.bam. Always validate the converted file.

Q: Does CRAM work for RNA seq alignments? A: Yes, but the compression benefit may be smaller because RNA seq alignments often have more spliced reads and multiple mapping loci. Still, CRAM is often 20-40% smaller than BAM for RNA seq.

Q: Should I use CRAM for single cell RNA seq data? A: It depends on your workflow. Many single cell pipelines (e.g., Cell Ranger, STARsolo) output BAM by default. You can convert to CRAM after processing, but be aware that some tools that operate on raw UMI corrected BAMs may not accept CRAM.

Q: What is the recommended way to share CRAM files with collaborators? A: Provide the CRAM file, its .crai index, and a checksum file. Also include a FASTA file of the reference genome used, or at least its MD5 hash and download URL. Some groups prefer to share a BAM version for simplicity.

References and Further Reading

• NCBI Bookshelf: SAM/BAM format specification
• EMBL EBI Training: Working with BAM/CRAM files
• Galaxy Training Network: Converting BAM to CRAM
• Bioconductor: Rsamtools for CRAM handling
• NCBI Sequence Read Archive submission guidelines
• samtools documentation
• CRAM format specification version 3
• GA4GH reference implementation for CRAM
• Comparison of BAM and CRAM on human genome data
• Best practices for archival storage of sequencing data

Related Articles

• RNA Sequencing Analysis: From FASTQ Files to Biological Questions
• RNA-seq Quality Control: What to Check Before Differential Expression
• How to Plan a Bulk RNA-seq Differential Expression Study
• Single-Cell RNA-seq Workflow: A Practical Analysis Roadmap
• Single-Cell RNA-seq Quality Control: Cells, Genes, and Mitochondrial Reads