If you run PostgreSQL in production, the backup question is never "if" but "how reliably." Shell scripts wrapping pg_dump work at first, but the problems are predictable: missed runs nobody noticed, archives quietly filling a disk, no alerts when the job fails at 3 AM.

Databasus was built to solve exactly that. It started as an internal tool, was open-sourced in early 2025 and has since grown into the most widely used PostgreSQL backup solution. Today it's used daily by tens of thousands of developers, DBAs and DevOps engineers worldwide.

What is Databasus

Databasus is a free, open source, self-hosted backup management system for PostgreSQL and many other databases. It provides a web UI on top of pg_dump and adds everything that raw dump scripts lack: scheduling, compression, multiple storage destinations, encryption, health monitoring, real-time notifications and team access management.

The tool runs as a single Docker container. All data stays on your own infrastructure — Databasus never proxies your credentials or backup files through any external service. You own everything.

Supported databases

PostgreSQL is and remains the primary focus, but all four engines are production-ready. Here are the supported versions:

Database	Supported versions
PostgreSQL	12, 13, 14, 15, 16, 17, 18
MySQL	5.7, 8, 9
MariaDB	10, 11
MongoDB	4, 5, 6, 7, 8

PostgreSQL receives the most thorough testing, optimization and ongoing development. The other engines are fully supported, but if PostgreSQL is what you're running, Databasus is tuned specifically for it.

Scheduling and compression

Every backup job has its own independent schedule. You can run different databases at completely different times, which actually matters in production when you don't want five large backups competing for I/O at 2 AM.

Supported schedule types:

Hourly, with an exact minute offset
Daily at a specific time, such as 4:00 AM
Weekly on a chosen weekday and time
Monthly on a chosen calendar day
Any custom cron expression for edge cases

Databasus also handles retention for you using the GFS (Grandfather-Father-Son) rotation scheme. Instead of letting archives pile up indefinitely, you configure how many backups to keep at each level:

Keep last N backups
Keep last N daily backups
Keep last N weekly backups
Keep last N monthly backups

Any combination of these rules works together. Old backups that fall outside the retention policy are cleaned up automatically.

Backup files are compressed by default at a balanced level. In practice, this typically achieves 4 to 8x size reduction with about 20% additional runtime overhead. That directly cuts storage costs and speeds up uploads to cloud destinations. There's nothing to configure. It just works.

Storage destinations

Databasus supports storing backups wherever you already keep files:

Local storage on the same VPS or server
S3-compatible storage: AWS S3, Cloudflare R2, MinIO, DigitalOcean Spaces
Google Drive
Dropbox
SFTP and FTP
NAS
Rclone, which itself covers 70+ additional cloud storage providers

Each backup job can target any configured storage. Files are always owned by you — Databasus is not a cloud service and does not intermediate the storage in any way.

Security

Security in Databasus works on three independent layers, all active by default.

The first is backup file encryption. Every backup archive is encrypted with AES-256-GCM using a unique key derived from a master key, the backup ID and a random salt. Even if someone gains access to your S3 bucket, the files are useless without your encryption key. You can safely store backups in shared cloud storage without worrying about unauthorized access.

The second layer covers credentials. All passwords, API keys and tokens stored by Databasus are encrypted before being written to disk. They are never exposed in logs or error messages.

The third layer is read-only database access. Databasus uses a read-only database user by default and checks at setup time that no write privileges are present. This means that even in a worst-case scenario, Databasus cannot modify your data.

One more thing worth mentioning: you can restore any backup directly from storage without Databasus at all. With just your secret.key file and standard tools like pg_restore, you can decrypt and restore any archive manually. There's a step-by-step recovery guide in the documentation. Even being open source and self-hosted, Databasus avoids locking you in.

Notifications

Databasus sends notifications on backup success and failure. DevOps teams can route them to existing channels and know about a failed backup the moment it happens, not the next morning.

Supported notification channels:

Email
Telegram
Slack
Discord
Mattermost
Webhooks for custom integrations

Each backup job can have its own notifier set, so a critical production database can alert a dedicated Slack channel while a dev database sends nothing at all.

Database health monitoring

Beyond backups, Databasus can continuously monitor database connectivity. It pings the database on a configurable interval and maintains a history of results. After a configurable number of consecutive failures, the database is marked as down and a notification is sent. When connectivity is restored, another notification fires.

This isn't a replacement for dedicated monitoring, but it's a useful lightweight availability check for databases that don't have any monitoring set up yet. And since Databasus is already connected to your database for backups, the feature adds no overhead to configure.

Team features

Databasus supports workspaces that group databases, storage configurations and notifiers for different projects or teams. Within a workspace, users can be assigned one of four roles:

Role	What they can do
Viewer	Read-only access to backups and status
Member	Can manage backups
Admin	Can manage members and configurations
Owner	Full control including workspace deletion

This means you can give a junior developer or a client read-only visibility into backup history without giving them credentials or management rights.

Every action taken by every user inside a workspace is also recorded in audit logs: configuration changes, backup downloads, schedule modifications, member role changes. Logs are queryable with date filtering and pagination, which is useful both for security compliance and for tracing what changed when something went wrong.

Works with cloud-managed databases

Databasus connects over a standard database network connection and requires no server-side installation. It works with AWS RDS, Google Cloud SQL, Azure Database for PostgreSQL, Supabase and any other managed service that exposes a standard connection endpoint.

This is worth noting because tools like pgBackRest and Barman require direct filesystem access to the database server, which makes them incompatible with managed cloud databases. Cloud providers already offer native PITR, and external incremental backups generally cannot be restored back to them anyway. For most projects, hourly or daily logical backups give you adequate recovery granularity without the operational complexity of WAL archiving.

Getting started

Databasus deploys as a single container. There are four supported installation methods: an automated script (recommended for Linux), Docker run, Docker Compose and Kubernetes via Helm.

The quickest way to get started on Linux:

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

Or with Docker directly:

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

After installation, open http://localhost:4005, add your database and configure the first backup job. The whole process usually takes under five minutes.

Open source

Databasus is licensed under Apache 2.0 — free for personal use, commercial use and self-hosting. The source code is on GitHub. You can inspect every line before running it on your infrastructure, which matters when you're trusting a tool with database credentials.

The project has an active community on Telegram: @databasus_community.

Databasus vs alternatives

Databasus has surpassed WAL-G and pgBackRest in popularity over the last couple of years. That shift reflects a broader trend: most teams don't need second-precise PITR, they just need backups that reliably run, go somewhere safe and alert them when something breaks. Databasus handles that well, without requiring DBA expertise or complex configuration.

That said, the tools solve different problems. Here's how they compare:

	Databasus	pg_dump scripts	pgBackRest / Barman	WAL-G	Cloud provider backups
Web UI	Yes	No	No	No	Yes
Multi-database management	Yes	Manual	One DB per config	One DB per config	Per-service
Works with managed clouds	Yes	Yes	No	No	Yes
Built-in scheduling	Yes	Manual (cron)	Manual (cron)	Manual (cron)	Yes
Notifications	Yes	Manual scripting	No	No	Limited
Team features (RBAC, audit logs)	Yes	No	No	No	Limited
Cloud storage destinations	Yes	Manual scripting	Yes	Yes	Vendor-specific
Encryption	AES-256-GCM	Manual	AES-256	GPG / libsodium	Yes
Self-hosted	Yes	Yes	Yes	Yes	No
Free	Yes	Yes	Yes	Yes	Pay per backup
PITR	No	No	Yes	Yes	Yes
Learning curve	Minimal	Low	High (DBA level)	High (DBA level)	Minimal

pgBackRest, Barman and WAL-G are all command-line tools that require direct filesystem access to the database server. This makes them incompatible with cloud-managed databases like AWS RDS, Google Cloud SQL or Azure, and means they each manage a single database instance per configuration. None of them have built-in notifications, team access control or a web interface. They are powerful tools, but they're built for DBAs managing self-hosted infrastructure who need PITR.

Databasus takes a different position. It manages multiple databases across different servers from a single interface, works with both self-hosted and cloud-managed databases and is usable by developers without deep PostgreSQL knowledge. For the vast majority of projects, hourly or daily logical backups are more than sufficient.

If you specifically need WAL-based Point-in-Time Recovery on self-hosted infrastructure, pgBackRest and WAL-G remain valid choices. For everything else, Databasus is the more practical option.

Databasus is available at databasus.com and on GitHub.

Conclusion

Most teams don't lose data because they chose the wrong backup tool. They lose it because they had no backup running at all, or they had one and never noticed when it stopped working.

Databasus doesn't try to replace pgBackRest or WAL-G for teams that genuinely need WAL-level recovery. It solves a different and more common problem: making it easy to set up reliable, automated, encrypted backups that actually run and actually alert you when something fails.

It's free, self-hosted and takes about five minutes to get running. That's a reasonable trade-off for most projects.