What is DESeq2 used for?

DESeq2 is an R/Bioconductor package for differential gene expression analysis of RNA-seq count data. It models raw counts with a negative binomial distribution, estimates size factors to normalize for sequencing depth and library composition, shrinks dispersion estimates (and, with lfcShrink, log fold-changes), and returns a per-gene table of log2 fold-changes, p-values, and Benjamini-Hochberg adjusted p-values.

What input does DESeq2 need?

Two things: a matrix of raw, un-normalized integer counts (genes as rows, samples as columns) and a sample table describing each column, such as condition, batch, timepoint, or sex. Counts usually come from featureCounts, HTSeq, or Salmon/Kallisto estimates imported with tximport. Do not feed DESeq2 TPM, FPKM, or already-normalized values, its model expects raw counts.

How do I choose the DESeq2 design formula?

The design formula lists the variables that explain your counts, with the variable of interest last, for example ~ batch + condition. Anything you want to control for (batch, donor, sex, timepoint) goes earlier in the formula. Getting this wrong is the most common cause of misleading results, so the design and the contrast should be agreed with your bioinformatician before the run.

DESeq2 vs edgeR: which should I use?

Both model counts with a negative binomial distribution and generally agree on strong signals. DESeq2 shrinks dispersion estimates and offers fold-change shrinkage through lfcShrink, which helps with small sample numbers and noisy low-count genes; edgeR's quasi-likelihood workflow is a common alternative and is fast on large designs. Most labs pick one, document it, and stay consistent so results stay comparable across studies.

Why do my DESeq2 results change when I re-run them?

Usually because something upstream changed: a different annotation or reference build, a new package version, a filtered sample, or an edited sample sheet. Reproducibility depends on pinning the count matrix, the annotation, the package versions, the design formula, and the contrast. Bridge Horizon records all of those automatically for every run, so a re-run months later returns the same numbers.

Can I run DESeq2 from an existing count matrix or a GEO dataset?

Yes. If you already have counts from a collaborator, a core facility, or a public dataset such as GEO, SRA, or recount3, you can start at the differential expression step instead of re-processing FASTQs. Bridge Horizon logs the input matrix, the sample sheet, the package versions, the design, and the contrasts so the analysis is as traceable as one started from raw reads.

Do I need to know R to run DESeq2?

No. On Bridge Horizon, a bioinformatician validates the DESeq2 workflow once and bench scientists run it through a guided interface: pick the count matrix, describe the samples, choose the contrast, and run. The underlying analysis is the same code, with every parameter recorded.

What cutoffs should I use for significant genes?

A common starting point is an adjusted p-value below 0.05, sometimes combined with a log2 fold-change threshold such as 1. The right cutoff depends on your sample size, effect sizes, and how the gene list will be used downstream. Whatever you pick, record it with the run so reviewers can see how the list was produced.

DESeq2 differential expression

Run DESeq2 differential expression analysis reproducibly

A practical guide to differential gene expression with DESeq2: what it needs, how the design formula works, and how to run it on Bridge Horizon so every result stays traceable.

What DESeq2 does, in plain terms

DESeq2 takes a matrix of raw RNA-seq counts and a table describing your samples, and tells you which genes differ between conditions. It normalizes for sequencing depth, models count variability, shrinks noisy estimates, and returns log2 fold-changes with p-values adjusted for multiple testing.

Two decisions drive the result more than anything else: the design formula, which lists the variables that explain your counts with the variable of interest last, and the contrast, which states exactly which groups are being compared. Everything else is bookkeeping, but that bookkeeping is where reproducibility is usually lost.

On Bridge Horizon, the count matrix, sample sheet, design, contrast, package versions, and outputs are captured as one tracked run. Your bioinformatician validates the workflow once; anyone on the team can run it on their own data and re-run it identically later.

How Bridge Horizon runs it

From raw data to results, in one workspace

Bring in your counts

Upload a raw count matrix from featureCounts, HTSeq, or tximport, or start from FASTQs and let the RNA-seq pipeline produce the counts.

Describe your samples

Fill in a guided sample sheet with condition, batch, donor, or timepoint. These become the variables available to your design.

Set the design and contrast

Choose which variables to control for and which groups to compare, for example treated versus control while adjusting for batch.

Run DESeq2

Bridge Horizon runs normalization, dispersion estimation, testing, and optional lfcShrink fold-change shrinkage, and records the package versions used.

Review the results

Inspect the results table, volcano and MA plots, and PCA of the samples to sanity-check the comparison before sharing it.

Share and re-run

Your PI and bioinformatician open the same run. Change a cutoff or a contrast and the new run sits alongside the original for comparison.

Reproducible bioinformatics workflows

Every run is reproducible by default

Reproducibility shouldn't depend on whoever ran the analysis still being on the team. Bridge Horizon captures everything that went into a result, the pipeline version, parameters, reference, container image, and inputs, so any teammate can re-run it identically months or years later.

Versioned pipelines

Pipelines are pinned to a specific version on every run, so an old analysis doesn't silently change when the pipeline does.

Full parameter logs

Every parameter, input file, and reference is recorded automatically. No lab notebook entries to maintain by hand.

Audit-ready provenance

When a reviewer, client, or auditor asks how a figure was made, you can show them the full chain in one click.

Built for the whole genomics team

For research scientists

Run validated pipelines on your own sequencing data without waiting in the bioinformatics queue.

Learn more

For NGS core facilities

Deliver traceable sequencing results to clients faster, with built-in access controls and expiring links.

Learn more

FAQ

Common questions

See how Horizon fits your team.

Built on production genomics experience since 2020, Horizon makes every dataset, pipeline run, and parameter shared and traceable across your entire team.