Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

data.compression rejects zstd although barman-cloud-backup supports it

Open Beginner friendly
  • Is something wrong?
#1,104 0 comments 4 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
databases

Research direction

Start in api/v1/objectstore_types.go and compare data.compression with the existing wal.compression enum. Add zstd to the data.compression enum, regenerate the CRD, and inspect the generated schema to confirm the new value is present. Done means the CRD accepts zstd for data.compression while retaining the existing values.

Written by the indexing model from the issue text.

Description

ObjectStore.spec.configuration.data.compression accepts bzip2|gzip|lz4|snappy, but not
zstd — even though the barman-cloud-backup binary in the sidecar image supports it.
wal.compression does accept zstd.

Versions: plugin v0.15.0 (chart 0.8.0), sidecar barman 3.20.0, CNPG 1.30.0.

barman-cloud-backup --help, from ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.15.0:

usage: barman-cloud-backup ... [-z | -j | --snappy | --lz4 | --zstd] [-h HOST]
  --zstd    zstd-compress the backup while uploading to the cloud

CRD on main:

data.compression.enum: [bzip2, gzip, lz4, snappy]
wal.compression.enum:  [bzip2, gzip, lz4, snappy, xz, zstd]

This looks like a lag rather than a decision: #200 added these algorithms on 2025-03-19,
when barman supported them for WAL only; EnterpriseDB/barman#1083 added --zstd to
base backups on 2026-07-04, and api/v1/objectstore_types.go has not changed
functionally since 2025-09-24.

Measured on 1.07 GiB of real pgdata/base (PG16 + TimescaleDB), single-threaded:

algorithm ratio compress decompress
snappy 5.07x 583 MB/s 1138 MB/s
lz4 6.12x 521 MB/s 1583 MB/s
gzip 8.94x 78 MB/s 727 MB/s
bzip2 13.76x 8 MB/s 45 MB/s
zstd -3 11.46x 856 MB/s 1655 MB/s

zstd is faster than every permitted value in both directions, and only bzip2 compresses
better — at 1/100th the compression speed and 1/37th the decompression speed, the latter
being what a restore pays.

Request: add zstd to the data.compression enum and regenerate the CRD.

data.additionalCommandArgs: ["--zstd"] looks like a workaround, but I have not verified
the restore path end to end.

Dominant language
Go
Stars
196
Forks
76
Avg merge
6d 8h
Merged PRs (30d)
22

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from cloudnative-pg/plugin-barman-cloud

All issues in cloudnative-pg/plugin-barman-cloud

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.