Bakta: fast bacterial genome annotation built on protein hashes

Alignment free identification is the whole trick

Bakta is a tool for the rapid and standardized annotation of bacterial genomes and plasmids, from both isolates and metagenome assembled genomes. Its distinguishing mechanism is called alignment free sequence identification, and it is the reason for the speed claims.

The approach uses full length MD5 protein sequence hash digests. For sequences that are already known, the digest is looked up directly rather than the sequence being aligned to a reference. Bakta exactly identifies known identical protein sequences from RefSeq and UniProt, which allows fine grained annotation of gene alleles such as antimicrobial resistance genes, or of closely related but distinct protein families.

The consequence is stated plainly: the approach substantially accelerates annotation by avoiding computationally expensive homology searches for genes that are already identified. A typical bacterial genome takes about ten minutes plus or minus five on a laptop, and plasmids take a couple of seconds or minutes.

For a database this large, the effect is dramatic. Bakta currently identifies roughly 350 million distinct protein sequences from UniParc, 330 million from UniRef100 and 290 million from RefSeq. The documentation says that for certain genomes up to 99% of all coding sequences can be identified this way, skipping the expensive sequence alignments entirely.

The database itself is built on UniProt's entire UniRef protein sequence cluster universe, which is what makes it taxonomy independent. The stated aim is favourable sensitivity and specificity along the whole continuum from well studied species to unknown genomes from MAGs, which is the harder half of the problem and the one that matters for metagenomics.

dbxrefs and the FAIR principles

The cross-references are what make the output reusable, and the design is explicitly driven by the FAIR principles of findable, accessible, interoperable and reusable data.

Bakta annotates coding sequences with database cross-references to RefSeq with the WP_ prefix, UniRef100 with the UniRef100_ prefix and UniParc with the UPI prefix. Because these identifiers are exact and stable, an annotation made elsewhere can be mapped back to the same coding sequence, which is what allows the surveillance of distinct gene alleles, the simplification of comparative analysis, and the posterior annotation of putative and hypothetical protein sequences after the fact.

The paper link is the clearest illustration. The E. coli gene ymiA is cited as an example of a protein that exists in the databases under a stable identifier even though its status has been regarded as dubious, and a stable identifier means an ambiguous annotation can still be resolved later.

The annotation database itself is versioned and custom, comprising UniRef100 and UniRef90 protein clusters enriched with GO, COG and EC annotations and with entries from specialised niche databases. For each database version the project provides a comprehensive log file of all imported sequences and annotations, which is what makes a result reproducible months later when the database has moved on.

Bakta also writes GFF3 and INSDC compliant files, meaning Genbank and EMBL, ready for submission. The documentation lists the validators used to check that, including the GenomeTools GFF3 validator, table2asn_GFF and the ENA Webin-CLI, tested on representative genomes of all ESKAPE species. The db-versions.json file in the repository and the db-scripts/ directory are where that versioned database work lives.

Expert systems for the genes that matter most

A purely automated pipeline will not satisfy anyone who works on antimicrobial resistance, so Bakta merges in expert annotation systems for the proteins of highest interest.

It uses NCBI's AMRFinderPlus for antimicrobial resistance gene annotations. Alongside that there is a generalised protein sequence expert system with distinct coverage, identity and priority values for each sequence, which currently comprises the VFDB virulence factor database and NCBI's BlastRules. The priority mechanism matters, because when two expert sources disagree about the same sequence, the tool needs a defined order to resolve it rather than an arbitrary one.

The feature that distinguishes Bakta from most pipelines is the annotation of small proteins and short open reading frames. The documentation notes that Bakta detects and annotates sORFs which are not predicted by tools like Prodigal. Prodigal is the long-standing standard for prokaryotic gene calling, and its heuristics deliberately skip very short open reading frames because they are so often spurious. Bakta chooses the opposite: it reports them, on the reasoning that a short gene in a bacterium is often real.

The rest of the feature set is the standard prokaryotic annotation surface, done thoroughly. ncRNA, cis-regulatory regions, oriC, oriV and oriT, assembly gaps, tRNA, tmRNA, rRNA, ncRNA genes, CRISPR, CDS and pseudogenes are all covered, along with genome plots.

The design decision to cover bacteria and plasmids only is stated as deliberate. Tuning the annotation process to the tools, preferences and databases of that domain was chosen to make further development and maintenance simpler, which is a defensible trade for a tool that wants to be fast and predictable rather than general.

Bakta sits between PGAP and Prokka on purpose

The project's own framing of where it sits is the most useful part of the documentation for anyone choosing an annotator.

Bakta aims at a well balanced trade-off between fully featured but computationally demanding pipelines like PGAP, and rapid, highly customisable offline tools like Prokka. It says it is heavily inspired by Prokka, with credit to its author, and that many command line options are compatible for the sake of interoperability and user convenience.

That compatibility detail is worth more than it sounds. A lab that has scripts around Prokka can move to Bakta without rewriting them, and a lab that has PGAP output in a submission pipeline can compare, because the output formats overlap.

The distributable forms are numerous, which is a sign of a tool that has to fit into many different pipelines. It is on PyPI, on bioconda, on Docker Hub, on Spack as py-bakta, and on the Galaxy Toolshed as an IUC tool, so a Galaxy user can run it without a local install at all. It is also published in a paper with a DOI for citation, and the static bio.tools entry records the version.

The Python packaging reflects the same approach. The setup file declares Python 3.9 up to but not including 3.14, and the runtime dependencies are the expected set for the field: biopython for sequence handling, pyhmmer for homology search, pyrodigal for gene prediction, pycirclize for the genome plots, xopen for compressed input, alive-progress for progress bars, PyYAML for configuration, and requests for the network calls. The console entry points are bakta, bakta_proteins, bakta_db, bakta_plot and bakta_io, so database preparation, protein bulk annotation and plotting are separate commands rather than modes of one.

The container image is built with micromamba on a Debian slim base, and the final stage copies a trimmed conda environment, with the comments explaining that trimming steps exist so the image is smaller and so the environment works on the PATH for every process, including entrypoint overrides and workflow managers like nextflow.

What Bakta will not do

The limitations are clear enough that they can be stated without hunting for them, and they are the reason to check before adopting.

The domain limit is the first and the most decisive. Bakta was designed to annotate bacteria, isolates and MAGs, and plasmids, only. If your project involves eukaryotes, archaea, viruses or any non-bacterial organism, this is the wrong tool and no configuration change will help, because the databases and the heuristics are bacterial.

The database is the second constraint, and it is a real operational one. The annotation set is built on the UniRef cluster universe with roughly a million scale of distinct protein sequences behind it, and it has to be downloaded, unpacked and version matched to the tool version. A workflow that runs Bakta on a schedule needs to track those versions, and the db-versions.json file and the per-version log files are the mechanism for doing that, but it is work that a small pipeline may not have the appetite for.

The third is a matter of expectation rather than capability. Bakta is fast partly because it skips the alignments it can prove are unnecessary, and partly because it does not attempt the depth that a full PGAP-style pipeline does. If what you need is a complete, deeply curated functional profile of every gene, the feature-rich pipeline is the answer and Bakta is the wrong shape.

There is also a short list of supporting capability that a user should not assume. The repository includes a Command Line Interface Workflow definition, bakta.cwl, so it fits workflow engines that speak CWL, and there is a web version plus auxiliary scripts. But the database is the piece you have to plan for, and it is the one that determines whether Bakta is pleasant to use or merely fast.

Editorial conclusion

Bakta suits a microbial genomics group that annotates many genomes a week and wants the same standardised output every time, especially one producing INSDC files for submission. It does not suit anyone annotating eukaryotes or archaea, because the tool is explicitly limited to bacteria and plasmids by design, and the database is a large download that has to be versioned and kept current. Before running it, fetch the matching database version for your tool version, and check the sORF behaviour against Prodigal, since Bakta annotates short open reading frames that the older tool does not predict.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. oschwengers/bakta on GitHub
4. README
5. Releases