Repository navigation
Barman Cloud Plugin performs worse than Embedded Barman #735
Description
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.
Activity
dosubot commentedon Jan 16, 2026
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.maxParallelsetting), 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.maxParallelin yourObjectStoreconfig 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.
Docs are dead. Just use Dosu.
einhverfr commentedon Jan 19, 2026
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.
fix: pre-compile Python bytecode in container build
fix: use wheel-based build to fix bytecode staleness
fix: use wheel-based build to fix bytecode staleness
fix: use wheel-based build to fix bytecode staleness
RogierO commentedon Jan 29, 2026
We've experienced exactly the same issues and brought to the attention on November 10th
#656
For now it is really no option to switch to the plugin variant, as this will impact our production environment.
Is it certain that embedded barman will be removed in version 1.29? That would mean we cannout upgrade anymore, as we're already using 1.28
mnencia commentedon Jan 29, 2026
@RedouaneVintecc, @einhverfr, @RogierO Hi! I think this should be fixed in PR #746. Would you mind testing it?
You can download the manifest from the latest CI run here:
https://github.com/cloudnative-pg/plugin-barman-cloud/actions/runs/21478615720
Just scroll to the "Artifacts" section at the bottom, download
manifest.yaml, and apply it with:Once the PR is merged, you can also test it directly from main by following the instructions here:
https://cloudnative-pg.io/plugin-barman-cloud/docs/installation/#testing-the-latest-development-snapshot
Thanks for your help testing this!
fix: resolve WAL archiving performance and memory issues (cloudnative…
chore(main): release 0.11.0 (#717)
chore(deps): update dependency cloudnative-pg/plugin-barman-cloud to …
chore(deps): update dependency cloudnative-pg/plugin-barman-cloud to …
RogierO commentedon Feb 2, 2026
@mnencia I can confirm that this issue has been fixed with the latest release.
I'm now gettign the same results with archiving times for embedded and with the plugin.
Thanks a lot for the effort that you guys have put into this issue.
chore(deps): update dependency https://github.com/cloudnative-pg/plug…