Barman Cloud Plugin performs worse than Embedded Barman

[RedouaneVintecc]

Hi,

We are using Clounativepg 1.28 with the latest Barman plugin version 0.10 and we see degraded performance compared to the original embedded solution. As it seems now the embedded solution will be deprecated in the future, we would like this issue to be taken up or for an alternative solution to be available before that happens. As it stands now we can't consider cloudnativepg with barman plugin for our production systems.

Our system:

• Timescaledb version 2.22
• Postgres 16
• Running on AKS
• The backups are sent to a blob container using the objectstore crd with azure workload identity

What we see:

• Higher CPU usage in plugin-based system
• Slower WAL archiver processing
• WAL archiving can't keep up during high-load periods (mainly bulk inserts of data) causing a buildup of ready WAL files and an explosion in disk size.

The blue line indicates the switch from plugin to embedded barman

After seeing this behaviour, we can consistently reproduce this difference in performance using the benchmark tool from Timescale: https://github.com/GreptimeTeam/tsbs.git

Any way for this to be picked up?
In case more information needs to be provided, let me know.

[dosubot]

Hi @RedouaneVintecc! I'm Dosu and I’m helping the plugin-barman-cloud team.

Your experience with higher CPU usage, slower WAL archiving, and WAL file buildup when using the Barman Cloud Plugin (compared to the embedded solution) is a known and reproducible issue. Multiple users have reported similar problems, with the plugin often consuming 2x CPU and 4x RAM versus the embedded Barman, especially under high load or bulk inserts. These reports are tracked in issues like #385, #607, and #608.

The main reasons are architectural: the plugin runs as a dedicated sidecar container, making its resource usage more visible and inherently higher than the more tightly integrated embedded solution. The plugin’s WAL archiving and restore logic uses concurrent processing (controlled by the wal.maxParallel setting), which can increase both throughput and resource consumption, but doesn’t always keep up with high WAL generation rates during bulk operations. Some improvements have been made (see PR #659), but users still report WAL backlog and resource spikes even on recent versions.

You can try tuning wal.maxParallel in your ObjectStore config to increase concurrency, and set explicit CPU/memory limits for the sidecar, but these are mitigations rather than solutions. The underlying performance gap between the plugin and embedded Barman is still open and being discussed by the community.

If you have detailed benchmarks or traces, sharing them in the relevant issue threads may help maintainers prioritize further improvements. For now, monitoring plugin updates and tuning concurrency/resource settings are the main actionable steps.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[einhverfr]

It is worth noting that wal.maxParallel was set to 8 and it was not providing nearly enough performance, and higher levels did not improve performance.