The Postgres Backup Tool Anthropic and OpenAI Both Backed in the Same Month

A backup tool created in June 2025 now has more GitHub stars than pgBackRest, WAL-G, and Barman have each individually — 7,802, against 4,279, 4,199, and 3,206 respectively, per a live pull from the GitHub API. It's listed in the official PostgreSQL Software Catalogue. And in March 2026, it was accepted into both Anthropic's Claude for Open Source program and OpenAI's Codex for Open Source program — the same month, the same project, two AI labs that otherwise compete for the same coding-agent market both deciding a Postgres backup tool was worth backing.

The tool is Databasus (formerly Postgresus). The short version of what it means for a team running its own Postgres: it's a genuinely good standalone option, and it is not a replacement for an operator like CloudNativePG (CNPG) if your Postgres already lives inside a Kubernetes cluster under GitOps. The two solve different layers of the same problem, and picking the standalone tool where the operator belongs costs you reconciliation you didn't know you were relying on. Here's what Databasus actually does, how it stacks up against the incumbents, and where that line actually falls.

What Databasus actually is​

Databasus is a free, Apache 2.0, self-hosted backup manager with a web UI wrapped around PostgreSQL's own native tooling — not a reimplementation of pg_dump, but an orchestration layer on top of it. It connects to a target database remotely (SSH tunnel supported for closed networks) and drives pg_basebackup, pg_receivewal, and pg_combinebackup directly, so nothing has to be installed on the database host itself.

It supports four backup modes:

• Logical backups — engine-native dumps (and, notably, it's not Postgres-only: MySQL, MariaDB, and MongoDB are supported through the same logical-dump path)
• Physical backups — file-level cluster copies, faster to restore than logical dumps at scale
• Incremental backups — block-level diffs against the previous backup, keeping storage and backup windows small
• WAL streaming — continuous write-stream capture, enabling point-in-time recovery (PITR) to any specific second

Storage targets span local disk, S3, Cloudflare R2, Google Drive, Azure Blob, NAS, SFTP, and rclone-compatible backends, with AES-256-GCM encryption built in. Restores are one-click from the web UI, and a scheduled restore-verification job periodically pulls the latest backup into a throwaway container and reports whether it actually comes back up — the check most manual backup setups skip until the day they need it and discover the dump was silently broken. Team features (workspaces, RBAC, audit logs covering downloads, schedule changes, and config edits) and notifications over Slack, Discord, Telegram, MS Teams, and webhooks round it out. Deployment is a one-line installer script, a Docker container, Docker Compose, or an official Helm chart for Kubernetes.

How it actually compares to Barman and pgBackRest​

The GitHub-star gap is real, but stars measure attention, not fitness for a specific job. The architectural differences matter more:

Read that table for what it says, not for a winner. pgBackRest is still the right call for a DBA running a single 5TB instance who needs delta restore and doesn't care about a UI. Barman is still the right call if you're already centralizing backups for a fleet of standalone Postgres servers from one dedicated backup host and want standby creation baked in. Databasus's actual differentiator isn't raw backup throughput — it's being the first of the three built for a team that wants a UI, cross-engine coverage, and Kubernetes packaging out of the box, instead of assembling those from scripts and cron.

The Kubernetes-native question​

Here's the part the comparison table doesn't answer: bex, and platforms like it, run tenant Postgres on Cluster API-managed Hetzner fleets through CloudNativePG, not through a Docker container a tenant manages by hand — bex's own non-goal is running a managed-database product, but the operator story for a self-hosted tenant's own Postgres instance still exists, and CNPG is the incumbent answer this blog has already covered for that layer. So does a standalone tool like Databasus have a place next to it, or does it get replaced by it?

The deciding question is narrower than "which tool is better": does this Postgres instance already live inside a CNPG Cluster custom resource?

If yes, CNPG's own backup story is the better fit, full stop. A CNPG cluster already reconciles its own state continuously — the operator watches the Cluster CRD, drives failover, and rewires the active WAL archive target automatically when a replica gets promoted to primary. Point it at a Backup CRD or Kubernetes Volume Snapshots, and backup scheduling becomes one more field in the same declarative spec that already defines the cluster's replica count and storage class — checked into the same GitOps repo, reviewed in the same pull request, drift-checked by the same tooling that watches everything else in the cluster.

Bolt Databasus onto a CNPG-managed instance instead, and you get a second system that doesn't know about failovers: if CNPG promotes a new primary, Databasus has no CRD to watch and no built-in signal that the connection string it's been backing up just changed. You'd be scripting that reconciliation yourself — the exact work the operator already does for free.

If no — the Postgres instance is a standalone container or VM install, outside any operator's control loop — that CNPG advantage doesn't exist to give up, and Databasus is a legitimately better starting point than reaching for Barman or hand-rolled pg_basebackup cron jobs. That covers more real-world cases on a self-hosted PaaS than it might first sound: a tenant's own Postgres instance deployed as a plain container rather than through the platform's managed-database path, a local development database, or a small team standardizing backups across Postgres, MySQL, and MongoDB with one tool instead of three. In every one of those cases, there's no CRD to lose reconciliation with, because there was never one to begin with — and a one-click restore with a web UI beats memorizing pgbackrest restore flags for anyone who isn't a full-time DBA.

A setup checklist, not a repeat of the framework​

If you've decided Databasus fits — a standalone instance, not a CNPG-managed cluster — here's what actually changes in how you run it, distinct from the fit question above:

• Point it at object storage you already pay for. If your fleet already writes application backups to S3-compatible storage (R2, a Hetzner-adjacent bucket, whatever your platform already uses), reuse that bucket and IAM scope rather than provisioning a second storage account just for database backups.
• Turn on restore verification from day one, not after the first failed restore. It's a scheduled job, not a manual step — the entire value of the feature is that nobody has to remember to run it.
• Route notifications to wherever your on-call already lives — Slack or a webhook into your existing alerting, not a Databasus-specific inbox nobody checks.
• Revisit the decision if the workload graduates into an operator-managed cluster. A standalone instance that grows into a CNPG Cluster (for HA, for declarative failover) should move its backup story to CNPG's native path at the same time — don't keep Databasus bolted onto a workload that's since gained a reconciliation loop of its own.

The honest read​

Databasus earned the attention: agentless architecture, multi-engine support, and Kubernetes packaging in a project that's a little over a year old is a genuinely fast climb past tools that have been the default for a decade. But "most-starred" and "right tool for your specific Postgres instance" are different claims, and the gap between them is exactly the CNPG-or-not question above. A self-hosted PaaS asking tenants to run their own Postgres owes them a straight answer to that question, not just a link to whichever backup tool got the most attention this quarter.

bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with the underlying fleet managed by Cluster API instead of hand-rolled scripts. Star the repo on GitHub or deploy your first app today.

Sources​

• PostgreSQL Software Catalogue — Administration/development tools (Databasus listing)
• Databasus GitHub repository
• Databasus vs Barman — official comparison
• Databasus vs pgBackRest — official comparison
• GitHub API star counts for databasus/databasus, pgbackrest/pgbackrest, wal-g/wal-g, and EnterpriseDB/barman, pulled live July 29, 2026.
• CloudNativePG documentation — Backup on Volume Snapshots.