Databasus

Databasus

Scheduled database backups behind a web interface

Databasus is a self-hosted database backup service that you drive from a web interface. It handles PostgreSQL, MySQL, MariaDB and MongoDB. For each database you set a schedule (hourly, daily, weekly, monthly or a cron expression), a destination and a retention policy. Databasus then runs the backups, compresses them, encrypts them with AES-256-GCM and reports the result by email, Slack, Telegram or webhook, among other channels. The whole thing runs in a single Docker container that bundles its own PostgreSQL 17 instance for configuration.

The open source backup tools comparison weighs Databasus against file backup tools on what each one encrypts, deduplicates and verifies.

Point-in-time recovery and restore-tested backups

  • Remote physical backups for PostgreSQL: from PostgreSQL 17 onward, Databasus chains a full backup (pg_basebackup), block-level incrementals and continuous WAL streaming (pg_receivewal), so a restore can target any second between backups. Everything goes over the replication protocol with nothing installed on the database host, which the FAQ says also covers RDS and Cloud SQL.
  • Logical backups for all four engines: pg_dump custom format with zstd compression for PostgreSQL 12 to 18, and native dumps for MySQL 5.7, 8.0, 8.4, 9 and 26, MariaDB 5.5 to 13 and MongoDB 4.2 to 8.
  • Destinations: local disk, S3 and compatible stores, Cloudflare R2, Google Drive, Azure Blob Storage, NAS, FTP, SFTP, and rclone for any other provider.
  • Verification by actual restore: after each backup or on a schedule, the latest backup is restored into a throwaway container of the same major version. The report checks the restored size against the backup and lists every table with its row count.
  • Retention by age, count or GFS: grandfather-father-son rotation keeps hourly, daily, weekly, monthly and yearly backups independently.

Databases only, PITR from PostgreSQL 17 onward

Physical backups and PITR require PostgreSQL 17. On older versions Databasus falls back to pg_dump. MySQL, MariaDB and MongoDB are logical only: every backup is a full dump, with no incrementals and no point-in-time restore.

Databases only. Databasus does not back up files or directories, so protecting a whole server takes a second tool. restic has no scheduler and no interface, and reads a database through the output of a dump command. Plakar keeps files and databases in the same repository and adds its PostgreSQL and MySQL connectors as plugins.

Restore verification needs an agent. It is a Go binary that runs on a machine with Docker and outbound HTTPS access to the Databasus instance, and the docs ask for at least 1 CPU core and 512 MB of RAM per concurrent check. When a newer backup arrives, any pending check for the same database is cancelled.

Restoring without Databasus is documented for logical backups only. The manual recovery guide decrypts a backup with a Python script and hands it to pg_restore, mysql or mongorestore. It says nothing about physical backups. Each backup's key is derived from the secret.key file, which the README recommends copying right after installation.

The project spells out when pgBackRest is the better fit. Its comparison page points to pgBackRest for physical backups before PostgreSQL 17, differential backups, delta restore, or a command-line and infrastructure-as-code workflow. Databasus targets teams that want a UI, per-workspace roles and a setup that does not call for PostgreSQL expertise.

Free, with no paid tier. The code is Apache-2.0 and the site rules out open core and gated features. Funding comes from sponsorships between $25 and $5,000 a month, which list the sponsor's name and unlock nothing. The site offers no hosted version.

A young project with one main developer. Databasus used to be called Postgresus, and its repository dates from June 2025. Between v0.1.0 (July 21, 2025) and v3.60.0 (September 22, 2026), 251 versions shipped, and one developer authored 955 of the 1,047 commits GitHub counts. Version 3.43.0 (June 17, 2026) removed the agent that used to take physical backups from the database host: anyone still holding such backups has to stay on 3.42.0 or delete them before upgrading.