bzip3 se presenta como el sucesor espiritual de bzip2, la herramienta de compresión abierta que durante años acompañó a servidores y distribuciones Linux. Desarrollada por Kamila Szewczyk y publicada en GitHub, promete ratios de compresión notablemente superiores y tiempos de proceso más ajustados que su predecesor, sobre todo cuando el material a comprimir es texto o código fuente.
No se trata de un fork, sino de una reescritura completa. bzip3 combina un codificador entrópico de mezcla de contextos de orden 0, una transformada de Burrows-Wheeler acelerada mediante suffix arrays (a través de la biblioteca libsais, de Ilya Grebnov) y un pase RLE con Lempel-Ziv más predicción, una técnica inspirada en LZ77 y en el modelado de contexto PPM. Esa combinación es la que le permite sacar partido a los datos repetitivos, algo habitual en repositorios de código, dumps de bases de datos y logs archivados.
Los benchmarks frente a xz, zstd y bzip2 son notables
Szewczyk publicó un benchmark propio comprimiendo 262 tarballs de todas las versiones de Perl 5 en un único archivo. En su modo más agresivo (-b 511), bzip3 reduce ese corpus a 546.456.978 bytes, frente a los 3.441.163.911 bytes de bzip2 y los 2.056.645.240 bytes de LZMA (xz).
La diferencia es de 6,3 veces respecto a bzip2 y de 3,8 veces respecto a Zstandard, que se queda en 3.076.143.660 bytes sobre el mismo archivo. En tiempos, bzip3 completa la compresión en 7 minutos y 8 segundos, frente a los 12 minutos y 9 segundos de xz. La descompresión también gana: 4 minutos y 6 segundos frente a los 9 minutos y 22 segundos de bzip2, y cerca de los 3 minutos y 51 segundos de zstd. El rendimiento depende del compilador: las compilaciones para Linux x64 con clang13 rondan los 17 MiB/s de compresión y 23 MiB/s de descompresión por hilo, mientras que los binarios de Windows o de 32 bits quedan por detrás.
Dónde tiene sentido usar bzip3 hoy y sus riesgos
El encaje inmediato no pasa por sustituir gzip en una CDN ni zstd en un bus de eventos de baja latencia. Su terreno natural son los archivos de larga vida: snapshots de bases de datos, distribuciones de datasets, backups fríos y, en general, cualquier repositorio dominado por texto o código fuente.
Combinado con lrzip, que aporta duplicación de largo alcance antes de comprimir, el archivo de Perl usado como referencia baja hasta 60.072.608 bytes, por debajo de los 64.774.202 bytes de lrzip junto a lzma y de los 75.685.065 bytes de lrzip junto a bzip2.
No conviene perder de vista sus límites: el formato es incompatible con bzip2 (un archivo .bz2 no se abre con bunzip3, ni al revés), el valor máximo del parámetro de bloque (-b 511) exige picos de memoria RAM cercanos a los 12 GB, algo delicado en entornos de integración continua con cuotas ajustadas, y el ecosistema que lo rodea es todavía joven, lo que previsiblemente limita por ahora su integración de serie en los pipelines más habituales.
Instalación, licencia y el aviso a conocer
Para probarlo, podéis compilar el código fuente con los comandos habituales (git clone, bootstrap.sh, configure y make) o instalarlo directamente vía Homebrew en macOS. El repositorio principal acumula 1.300 estrellas, 19 watchers y 61 forks, y ya aparece empaquetado en varias distribuciones Linux.
El proyecto se distribuye bajo licencia LGPLv3: cualquier modificación de la propia biblioteca bzip3/libbz3 debe publicarse con esa misma licencia, pero el enlazado dinámico desde software propietario está permitido sin obligar a liberar código adicional. Pese a todo, Szewczyk incluye en el README una advertencia poco habitual y muy directa: no hay que comprimir datos con este programa a menos que se esté dispuesto a aceptar la posibilidad, aunque sea mínima, de que no puedan recuperarse. No es una coletilla legal de compromiso; es una recomendación explícita de mantener una segunda copia con xz o zstd mientras el proyecto termina de madurar.