Databasus: self-hosted PostgreSQL backups with PITR and restore verification

The gap Databasus targets: backups that were never restored

Most backup setups answer the wrong question. They confirm a file exists and has a checksum, then stop. The README draws that line explicitly: Databasus performs a real restore to confirm backups are usable, not just intact on disk or checksum check. That distinction is the whole product thesis.

The intended user is a team running PostgreSQL on its own servers or VPS who wants point-in-time recovery without assembling WAL archiving, retention rules and notification plumbing by hand. The README frames the goal as a focus on Point-in-Time Recovery at low RPO/RTO, and lists physical full, physical incremental and WAL streaming as separate backup types rather than one mode with flags. Logical dumps exist too, but they are positioned as the engine-native path, compressed and suitable for parallel restore, not as the recovery mechanism.

Who it is not for: anyone whose recovery target is a single small database with a nightly dump and a one-hour tolerance. The machinery here (containers, WAL, retention tiers, workspaces) buys you a lower recovery point objective, and you pay for it in operational surface.

How the backup pipeline is put together

The repository is a Go backend with an embedded frontend. The Dockerfile builds the frontend first with Node 24 and pnpm, copies the output into /app/ui/build, then compiles the Go backend with golang:1.26.3. The frontend is served from the same binary, which is why a single container on port 4005 is the entire deployment.

Migrations are handled by goose, built from source in the image at version v3.27.3 with a databasus.1 suffix. The build compiles goose for the target architecture rather than downloading a prebuilt binary, and the Dockerfile comment says why: a prebuilt binary may have the wrong architecture and cause exec format errors on ARM. That is a real detail for anyone deploying on ARM hosts.

Backup data flows from the source PostgreSQL instance into a storage destination you configure, with notifications sent to channels you configure. The README separates these into storages (local, S3, Cloudflare R2, Google Drive, NAS, Dropbox, SFTP, Rclone) and notifiers (Email, Telegram, Slack, Discord, Teams, Mattermost, webhooks). Restore verification runs as its own step: it spins up a database container, runs the restore and checks the restored size against the backup, then reports every table with its row count. Secrets are encrypted, and the README states Databasus uses a read-only user by default for backups and never stores anything that can modify your data.

Installing Databasus with Docker and running a first backup

The README gives four installation paths: an automated script (recommended, Linux only), a plain docker run, Docker Compose, and Kubernetes with Helm. The script installs Docker with Compose if missing, sets up Databasus and configures startup on reboot. It is fetched and piped to bash, so read it before running it on a host you care about.

sudo apt-get install -y curl && \
sudo curl -sSL https://raw.githubusercontent.com/databasus/databasus/refs/heads/main/install-databasus.sh \
| sudo bash

If you would rather not run a remote script, the single-container form is the shortest path. Note that the data directory is bind-mounted from the current working directory, so run it from wherever you want backups and configuration to live.

docker run -d \
  --name databasus \
  -p 4005:4005 \
  -v ./databasus-data:/databasus-data \
  --restart unless-stopped \
  databasus/databasus:latest

The README notes the same image is published to GitHub's registry, so use ghcr.io/databasus/databasus:latest if Docker Hub rate-limits your pull. After the container is up, the web interface is on port 4005. The first real task is adding a database connection, then a storage destination, then a backup schedule. Scheduling accepts hourly, daily, weekly, monthly or cron, and the README mentions running backups at specific times such as 4 AM during low traffic.

The repository's own docker-compose.yml is a development file, not a deployment recipe. It defines a databasus-local service behind the image profile, so a plain docker compose up -d does not start it, plus backend-db and backend-db-test services on postgres:17. The compose file comment warns that the dev database exposes its port to the public, and the environment defaults in .env.example include a literal password. Treat that file as a development fixture and set your own values.

What restore verification actually proves, and what it does not

Restore verification is the most defensible feature here, and also the easiest to over-read. According to the README, it triggers after each backup or on a schedule you set, spins up a database container, runs the restore and checks the restored size against the backup, then produces a report listing every table with its row count.

What that catches: truncated archives, a storage destination returning short reads, a backup that never completed, schema drift that breaks a restore. What it does not catch, based on the described check, is semantic correctness. A row count matching does not mean the rows are the ones you wanted, and a size comparison is a coarse signal. If your failure mode is silent data corruption inside PostgreSQL rather than a broken backup file, this verification will not be the thing that finds it. It is a strong smoke test, not a data integrity audit.

The cost side matters too. A real restore means starting a database container each time verification runs. On a busy schedule that is repeated CPU, memory and disk churn on the host running Databasus, and it competes with whatever else lives there. The README does not document a cap on concurrent verification runs or a way to route verification to a separate host, so plan the schedule with the host's capacity in mind.

Retention, storage caps and the encryption trade-off

Retention is layered. You can keep backups for a fixed duration, keep a fixed count of the most recent, or use GFS, which the README describes as keeping hourly, daily, weekly, monthly and yearly backups independently for fine-grained long-term history. There are also per-backup and total storage size caps.

The interaction between these policies is where operational surprises live. A duration policy and a count policy applied to the same destination can disagree about what should be deleted, and the README does not spell out precedence. Size caps add a third constraint that can force deletion earlier than either time or count would. If you enable all three, you need to watch what actually survives in the destination rather than assume the policy you care about wins.

Encryption is AES-256-GCM, and the README argues the case for it: backups remain useless to attackers, so you can safely store them in shared storage like S3 or Azure Blob Storage. That is a genuine argument for off-site storage. The trade-off is key custody. The README describes encryption for secrets and for backup files but does not document a key escrow or export procedure. Losing the instance's data directory while holding encrypted backups in S3 would be a bad day, so confirm how keys are persisted before you rely on this for disaster recovery.

Where Databasus is the wrong tool

The supported database matrix is uneven. PostgreSQL 14 through 18 gets physical and logical backups. MySQL 5.7, 8.0, 8.4 and 9, MariaDB 10, 11 and 12, and MongoDB 4.2 through 8 are logical only. If your recovery requirement is a low recovery point objective on MySQL or MongoDB, this tool cannot deliver it, because logical dumps do not give you WAL-style continuous capture. The README is clear about that split rather than burying it.

The second boundary is scale of operations. Workspaces, role-based permissions, audit logs and OpenTelemetry export are all listed, which means the product assumes multiple databases and multiple people. A solo developer with one database gets a web UI, a container, a migration system and a notification framework to maintain in exchange for scheduling and verification they could approximate with a cron job and pg_dump. That is not a criticism of the tool, it is a statement about fit.

Third, the README does not document rollback of a Databasus upgrade, and the release cadence shown in the repository is fast, with v3.55.0, v3.55.1 and v3.55.2 all landing in August 2026. Frequent releases plus an undocumented downgrade path means you should pin your image tag rather than track latest in production, and test upgrades against a copy of your data directory first.

Alternatives and the licence position

The obvious comparison is pgBackRest, which is the established PostgreSQL physical backup tool. The difference in approach is where the orchestration lives. pgBackRest is a command-line tool you drive from cron, systemd timers or your own scripts, and it does not ship a web interface, a scheduler, a notifier framework or built-in restore verification as a product feature. Databasus wraps the same category of work in a service with a UI and a database of its own. If your team already has configuration management and monitoring, pgBackRest gives you a smaller surface. If you want a UI, scheduled verification and notifications without writing glue, Databasus is the shorter path.

WAL-G is the other reasonable comparison, aimed at pushing PostgreSQL backups into object storage with a CLI-first model. Same trade-off: Databasus adds the control plane.

On licensing: Databasus is Apache-2.0, which permits commercial use, modification and redistribution, and includes an explicit patent grant. The repository also contains a NOTICE.md file, and Apache-2.0 requires that notices be preserved in redistributions. If you fork the project or embed it in a product, read NOTICE.md and keep the attribution intact. None of this is legal advice; if you are redistributing commercially, have counsel review the NOTICE and any bundled dependency licences.

Editorial conclusion

Adopt Databasus if you run PostgreSQL 14 through 18 on infrastructure you control and you need point-in-time recovery plus a restore drill you did not have to build. Skip it if a nightly pg_dump into object storage is enough, or if your database is MySQL, MariaDB or MongoDB and you need physical backups, since the README lists those as logical only. Before committing, verify on your own host that the read-only user the tool creates can reach every database you expect, and confirm which storage destination you will point it at, because the retention and size caps behave differently per destination.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes