Turbo Picard

Open-source genomics · v0.1.16

Selected Picard steps.
Implemented in Rust.

Native Rust tools for the Picard steps holding up your pipeline. Mark duplicates, sort BAMs, export FASTQ and collect QC metrics—with familiar commands and inspectable results.

Find my command Install Turbo Picard

Linux & macOS · MIT licensed · Your data stays on your infrastructure

one step, not a rewriteMarkDuplicates

Your current task

java -jar picard.jar MarkDuplicates \
  I=sample.bam \
  O=picard.bam M=picard.txt

The native alternative

turbo-picard MarkDuplicates \
  I=sample.bam \
  O=turbo.bam M=turbo.txt

Same task. Separate outputs.
Compare before you switch.

Familiar interfacePicard command names & KEY=VALUE
No JVM on native pathsRust execution on your existing hardware
32 saved benchmark casesParity checked on documented fixtures
Reproducible comparisonsRetain results from your own comparison

Choose a command to evaluate

Start with one step
in your existing pipeline.

Pick the slow, fragile or frustrating step. See what to check, what Turbo Picard changes, and where it fits.

01 / DUPLICATE MARKING

MarkDuplicates keeps getting killed.

Separate Java heap from total memory. Understand the bounded native path, scratch requirements and the multi-input cases that still need care.

Diagnose memory & slow runs → 02 / READ EXPORT

You need FASTQs. Not a mate-buffering problem.

Get paired, unpaired or compressed outputs. Use bounded queryname staging for coordinate-sorted BAMs without guessing about read orientation.

Build a better BAM-to-FASTQ step → 03 / SEQUENCING QC

QC shouldn’t keep reading the same BAM.

Run supported metric programs together. Preserve their filtering and output contracts instead of replacing one slow step with five new ones.

Review the native QC path → 04 / SORTING & I/O

The sort step is eating the job.

Make the order, buffer and temporary storage explicit. Evaluate coordinate or queryname sorting with stable disk-backed merging.

Understand sorting & scratch space →

Already looking at samtools or Riker? Choose the tool that fits the job—including when it isn’t Turbo Picard.

Show the work

Small tasks. Real timings.
Clear limits.

These are absolute medians from the saved 2026-08-14 fixture suite. You can inspect every result and its source log.

MarkDuplicates

0.075s

Turbo Picard median
2.239s upstream Picard median

3 runs · generator reads=50,000
Saved fixture parity: PASS

SamToFastq

0.034s

Turbo Picard median
1.896s upstream Picard median

3 runs · generator reads=50,000
Saved fixture parity: PASS

CollectMultipleMetrics

0.017s

Turbo Picard median
2.107s upstream Picard median

3 runs · generator reads=100,000
Saved fixture parity: PASS

Small-fixture results, not a whole-genome forecast. Three runs per case. JVM startup can dominate short tasks. Generator parameters are not guaranteed record counts. This saved suite predates v0.1.16; use it as historical evidence, not a fresh release benchmark.

All results & methods ↗

A smaller migration

Replace a bottleneck.
Not the pipeline around it.

You already know what your Picard step needs to produce. Keep that contract at the centre: command arguments, duplicate flags, metrics and the sidecars your next task consumes.

Nextflow, WDL, Snakemake and shell starter examples are tested in this repository. They are starting points for your evaluation, not a claim of upstream nf-core adoption.

Build my comparison →

Find the exact command.

Read native scope and fallback boundaries in a searchable, source-derived catalogue.

Try it without replacing Picard.

Install into an isolated environment. Use explicit executable names and a fresh results directory.

Compare what matters.

Check scientific outputs and downstream compatibility. Keep the evidence—including unsuccessful trials.

Switch one task.

Pin the version and repeat on representative inputs. Leave other pipeline steps untouched.

Built for humans. Legible to agents.

No agent should have to guess what “supported” means.

Ask for one command’s scope as JSON. Get structured trial arguments. Require native execution so a benchmark cannot quietly become an upstream Java run.

Discovery describes the documented surface; it does not inspect your files or validate every option. There is no AI model, account or API key required.

Explore command support →
Machine-readable discovery
turbo-picard capabilities --json \
  --command MarkDuplicates

TURBO_PICARD_REQUIRE_NATIVE=1 \
  turbo-picard MarkDuplicates \
  I=sample.bam O=turbo.bam M=turbo.txt

Current boundaries

The questions worth asking.

Can this replace all of Picard?

No. This is not a full Picard suite. Some commands have scoped native support; others require upstream Picard. Unsupported commands or options can use configured or detected fallback. Check the exact command before switching.

Will it be faster on my whole genome?

That is a measurement to make, not a promise to inherit. Compression, storage, coverage, duplicate families and options change the result. Compare your own input and keep the whole task’s time and resource use.

Do I need a GPU, Java or an AI service?

Native paths run on the CPU without Java or an AI service. Java is needed when you deliberately use upstream Picard or run a Picard comparison. No production GPU backend is enabled in this release.

What about metrics, charts and reproducibility?

Metrics text is the parity target for supported collectors. Lightweight PDF summaries are not a reproduction of Picard’s full chart rendering. Pin a release, retain the exact options and compare the outputs your downstream tasks consume.

Make the next step a useful one

Your bottleneck is specific.
Your evaluation should be, too.

Switch only the commands where the evidence supports the change. Start with the file and task you already care about.

Plan a safe comparison →