Databasus

Open-source database backup tooling, honestly reviewed. What you actually get when you self-host it.

TL;DR

• What it is: Apache-2.0-licensed self-hosted backup tool focused on PostgreSQL, with MySQL/MariaDB and MongoDB support. Think “Vaultwarden for your database backups” — full UI, schedules, cloud storage routing, and notifications [README][4].
• Who it’s for: Small teams, indie developers, and DevOps engineers running production PostgreSQL who want automated backups, multi-destination storage, and Slack/Discord alerts without paying AWS or a managed SaaS [4][README].
• Cost savings: The managed cloud tier starts at $9/mo [1]. Self-hosted is $0 software on a VPS that probably costs $5–10/mo. Managed backup add-ons on AWS RDS run $0.095/GB-month just for snapshot storage, which adds up fast on large databases — pricing data not comparable directly, but the self-hosted math is straightforward.
• Key strength: Combines scheduling, multi-cloud storage routing, encrypted backups, and team access management in a single Docker container with a clean UI. The agent mode adds WAL archiving and point-in-time recovery for disaster scenarios [2][README].
• Key weakness: The available third-party coverage is almost entirely installation guides, not independent reviews. Independent community verdict on reliability at scale is thin. Agent mode (required for PITR) has a non-trivial setup and requires PostgreSQL 15 or newer [2].

---

What is Databasus

Databasus is a self-hosted backup orchestration tool. You point it at one or more databases, configure a schedule, tell it where to store the files (local, S3, Google Drive, Dropbox, SFTP, Cloudflare R2, Rclone), and tell it where to send notifications (Slack, Discord, Telegram, email, webhook). It handles the rest: compression, encryption, retention cleanup, and health checks [README][4].

The primary focus is PostgreSQL — versions 12 through 18. MySQL (5.7, 8, 9), MariaDB (10, 11, 12), and MongoDB (4 through 8) are supported as secondary targets [README]. The project was previously named Postgresus before rebranding [3], which explains why some older guides still reference the old name.

As of this review, the project has 6,106 GitHub stars and ships under the Apache 2.0 license, meaning you can self-host, fork, or embed it in your own tooling without restriction [merged profile]. The project is supported by both Anthropic and OpenAI open-source programs, per the homepage [website].

The architecture is a single-container deployment for most use cases. For advanced PostgreSQL scenarios — WAL archiving, physical backups, PITR — there’s a separate agent binary that runs on the database server itself and connects outbound to the Databasus instance [2].

---

Why people choose it

The honest answer is that the independent review coverage for Databasus is thin. The third-party sources available are two official documentation pages [1][2], a Synology NAS installation walkthrough [3], and a serverspace.io deployment tutorial [4] — none of them independent product reviews. What we can synthesize is why the problem Databasus solves is real and what the documentation reveals about the approach.

The actual problem: Database backups are one of those tasks that every production system needs and most teams handle badly — either relying on managed service snapshots they’ve never tested restoring from, or cobbled together cron jobs that pipe pg_dump to S3 with no monitoring. Both approaches fail silently. Databasus replaces that with a UI you can actually look at [4].

Versus managed service backups. AWS RDS automated backups, Google Cloud SQL backups, and Supabase point-in-time recovery are all tied to their respective platforms. If you’re running PostgreSQL on a Hetzner VPS, a Proxmox homelab, or a Raspberry Pi cluster, none of those exist. Databasus fills the gap [README][4].

Versus DIY shell scripts. The serverspace.io tutorial [4] puts it plainly: “data loss caused by hardware failures, misconfigurations, or human error can lead to serious downtime and financial damage. While many backup solutions exist, not all of them are flexible, transparent, or easy to self-host.” A cron job running pg_dump to a local directory gives you backups; it doesn’t give you offsite replication, Slack alerts when a backup fails at 3am, retention policies, or an audit log showing who downloaded what [README].

The PITR angle. Point-in-time recovery is what separates “we have backups” from “we can recover to any second.” Databasus’s agent mode adds WAL archiving to PostgreSQL, which means you can restore to the exact moment before an accidental DROP TABLE [2]. Most lightweight backup tools skip this entirely.

The Synology crowd. The Marius Hosting guide [3] documents a popular use pattern: running Databasus on a NAS device alongside the database, treating the NAS as both backup orchestrator and local storage destination. The guide notes 99.9% of people skip the donation step, which is a reasonable proxy for how popular the tool has become in the self-hosted homelab community.

---

Features

From the README and documentation:

Database support:

• PostgreSQL 12–18 (primary focus)
• MySQL 5.7, 8, 9 and MariaDB 10, 11, 12
• MongoDB 4, 5, 6, 7, 8 [README]

Backup types:

• Logical backups via pg_dump (default, works with remote and cloud-managed databases)
• Physical backups (file-level, faster for large datasets) — requires agent [2]
• Incremental backups with continuous WAL archiving — requires agent [2]
• Point-in-time recovery (PITR) — requires agent, PostgreSQL 15+ [2]

Scheduling:

• Hourly, daily, weekly, monthly, or arbitrary cron expressions
• Run at specific times (e.g. 4am during low traffic)
• Compression with ~4–8x space savings [README]

Retention policies:

• Fixed duration (keep 7 days, 3 months, etc.)
• Fixed count (keep last 30 backups)
• GFS (Grandfather-Father-Son) — layered hourly/daily/weekly/monthly/yearly retention, documented as an enterprise requirement [README]
• Per-backup and total storage size caps [README]

Storage destinations:

• Local VPS storage
• S3-compatible (AWS S3, Cloudflare R2, MinIO, etc.)
• Google Drive
• Dropbox
• SFTP/FTP
• NAS
• Rclone (covers any rclone-supported target) [README][website]

Notifications:

• Email, Telegram, Slack, Discord, webhook [README][4]
• Success and failure events
• Health checks: pings database each minute and notifies on failure/recovery [website]

Security:

• AES-256-GCM encryption on backup files [README]
• Read-only database user for backups by default [README]
• Encrypted secrets storage — never exposed in logs [README]
• Recovery without Databasus documented explicitly to prevent vendor lock-in [README]

Team features:

• Workspaces for separating teams and projects
• RBAC: viewer, member, admin, owner roles
• Audit logs for access and changes (backup downloads, schedule changes, config updates) [README][website]

---

Pricing: SaaS vs self-hosted math

Databasus Cloud:

• Starts at $9/mo for the managed version [1]
• Full feature parity with self-hosted — same codebase [1]
• The cloud option handles infrastructure, uptime, and redundancy

Self-hosted:

• Software: $0 (Apache 2.0)
• VPS: $5–10/mo (Hetzner CX11 or Contabo equivalent)
• System requirements are minimal: 1 CPU core, 500MB RAM, 5GB for installation [1]

What you give up with self-hosting:

• Managed uptime (if your VPS goes down, backup jobs don’t run)
• No offsite redundancy unless you configure it yourself
• Your time to maintain updates

For context on alternatives:

• Pgbackrest Cloud / Pgbarman managed services: pricing not publicly listed for comparison
• AWS RDS automated backups: included but locked to AWS; cross-region copy incurs S3 transfer costs
• A dedicated backup SaaS like Snapshooter starts at $9/mo for 1 server, $29/mo for 5 servers (external reference — pricing data may have changed)

For a developer running 3–5 PostgreSQL databases on a VPS, the self-hosted math is: $6/mo VPS vs. $9/mo cloud. The difference is whether you want to manage the infrastructure. For a non-technical founder already overwhelmed by server maintenance, the $9/mo cloud tier is a reasonable trade.

---

Deployment reality check

Installation is genuinely simple for standard use cases. The recommended path on Linux is a one-line install script [1]:

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

Alternatively, a single docker run command gets you running [1]. The Marius Hosting guide [3] walks through Portainer-based deployment on Synology with a copy-paste Docker Compose stack — about 10 steps including creating folders and setting a password.

What you actually need for basic setup:

• Linux server or NAS with Docker
• ~500MB RAM, 1 CPU core, 5GB disk [1]
• Database credentials
• Reverse proxy (Caddy setup is documented and auto-handles HTTPS) [1]
• Time estimate for basic deployment: 15–30 minutes if you’re comfortable with Docker

Where it gets harder — agent mode:

If you need PITR or physical backups, the agent setup involves:

1. Downloading a binary to the database server
2. Editing postgresql.conf to enable WAL archiving with wal_level = replica and archive_mode = on
3. Editing pg_hba.conf to allow replication
4. Granting replication privilege to the database user
5. Creating and chowning a WAL queue directory
6. Starting the agent process with the right tokens and host config [2]

This is not difficult for someone who manages PostgreSQL regularly. For a non-technical founder who has never touched postgresql.conf, it’s a half-day project with a meaningful risk of misconfiguring WAL archiving in a way that silently fails. The Databasus UI provides pre-filled commands to copy-paste, which helps [2], but the underlying concepts (WAL segments, base backups, archive_command) require some understanding to debug.

Agent mode also requires PostgreSQL 15 or newer. If you’re running 12, 13, or 14 and want PITR, you’re either upgrading first or using logical-only backups [2].

The cloud-managed database angle: Remote backup mode works with RDS, Cloud SQL, Supabase, and any publicly reachable database without the agent. You just need credentials [2]. The agent is only needed for physical/incremental/PITR on self-hosted instances.

---

Pros and Cons

Pros

• Apache 2.0 license — genuinely permissive. Fork it, embed it, white-label it [README].
• Clean UI with real UX attention — the README specifically mentions “designer-polished UI” and the dashboard screenshots look production-quality, not an afterthought [README].
• Minimal resource footprint — 500MB RAM minimum. Runs comfortably on a shared VPS alongside other services [1].
• PITR support — most lightweight backup tools stop at logical snapshots. The agent mode adds WAL archiving for actual disaster recovery [2].
• Multi-database in one place — PostgreSQL, MySQL, MariaDB, MongoDB from a single dashboard [README].
• Anti-lock-in documentation — explicitly documents how to restore directly from storage without Databasus running. Unusual and appreciated [README].
• GFS retention — layered grandfather-father-son retention is an enterprise feature that competes above its price point [README].
• Team features included — workspaces, RBAC, audit logs at no separate license cost [README].
• Synology NAS support documented — accessible to homelabbers who don’t run traditional Linux VPS infrastructure [3].

Cons

• Thin independent review record — the available third-party coverage is installation tutorials, not independent evaluations. There’s no equivalent of a Trustpilot profile or a forum thread where real users discuss production reliability. Make your own judgment about that gap.
• Agent mode setup is non-trivial — WAL archiving configuration has sharp edges, especially with Docker-hosted PostgreSQL where volume mounts need precise setup [2].
• Agent requires PostgreSQL 15+ — older versions are stuck with logical backups only [2].
• Young project under active development — the project was known as Postgresus until a recent rebrand [3]. How recently, and what stability implications that carries, is unclear from available data.
• No native Windows server support — Linux and macOS only; Windows is listed as a platform badge in the README but server deployment is Docker-only [README].
• No documented REST API — programmatic management of backup jobs from external systems doesn’t appear to be a first-class feature based on available documentation.
• Cloud pricing transparency is limited — the documentation says “from $9/mo” but detailed tier breakdowns aren’t in the scraped content [1].

---

Who should use this / who shouldn’t

Use Databasus if:

• You’re running self-hosted PostgreSQL (on a VPS, homelab, or NAS) and your current backup strategy is “I think cron runs pg_dump somewhere.”
• You want backup failures to actually notify you in Slack or Telegram rather than being discovered during an incident.
• You have multiple databases and want one dashboard instead of separate cron jobs per server.
• You want encrypted offsite backups to S3 or Google Drive with GFS retention and you don’t want to script it yourself.
• You’re comfortable with Docker and basic Linux administration.
• You’re on a Synology NAS and want a GUI-based backup workflow [3].

Skip it (use managed backups) if:

• Your databases are entirely on RDS, Cloud SQL, or another managed service with built-in PITR — adding Databasus is redundant unless you’re routing to additional offsite destinations.
• You’re not comfortable managing a VPS, and the $9/mo cloud tier doesn’t fit your budget.

Skip it (use WAL-G or pgBackRest directly) if:

• You’re a DBA or DevOps engineer who wants CLI-native backup tooling with maximum control, no web UI, and tight integration with your existing Ansible/Terraform infrastructure.
• You need to run physical backups on PostgreSQL 12–14 — agent mode requires 15+ [2].
• You need a battle-tested backup solution with years of production deployments and a large community — WAL-G and pgBackRest have more verifiable track records at this point.

Skip it (stay with your current solution) if:

• You’re already running Barman or pgBackRest and your ops team knows it. Don’t migrate a working backup system to chase a better UI.

---

Alternatives worth considering

• WAL-G — CLI-only, no web UI, PostgreSQL/MySQL/MongoDB/Redis support, widely used in production. The right choice for ops engineers who prefer configuration files over dashboards. Free, open source (Apache 2.0).
• pgBackRest — PostgreSQL-focused, excellent PITR, well-documented, no web UI. The gold standard for PostgreSQL-specific backup on self-managed servers.
• Barman — PostgreSQL backup and disaster recovery from 2ndQuadrant/EDB. CLI-based, production-proven, free and open source.
• Duplicati — general-purpose backup with a web UI, supports databases via pre/post backup scripts. Less purpose-built for databases, but covers more backup scenarios.
• Restic + cron — file-level backups with deduplication, works well for logical dump files. No scheduling UI, but dead-simple and extremely reliable.
• Managed cloud backups (AWS RDS, Google Cloud SQL, Supabase) — if your database is already on a managed platform, the native backup features are the path of least resistance.

For a non-technical founder who needs something that works without ongoing ops attention: Databasus Cloud at $9/mo versus WAL-G on a VPS is not a fair comparison — the latter requires skills the former shouldn’t need to have. The self-hosted path is genuinely accessible here.

For an engineer building production infrastructure: Databasus is appealing for the UI and multi-DB consolidation, but WAL-G and pgBackRest have longer track records at scale. Both can coexist — use pgBackRest for critical PostgreSQL, Databasus for everything else.

---

Bottom line

Databasus solves a real problem — database backup is boring, easy to neglect, and catastrophic when it fails. It wraps a capable PostgreSQL (and MySQL/MongoDB) backup stack in a Docker container and a clean web UI, adds multi-cloud storage routing, AES-256 encryption, and team access management, all under the Apache 2.0 license. The PITR story via the agent mode is competitive with purpose-built tools, though the setup is non-trivial and limited to PostgreSQL 15+. The main caveat is that independent reviews are almost nonexistent — what’s available is documentation and installation guides. That’s worth knowing before you bet your production backup strategy on it. For a developer or small team who currently has no reliable backup system, Databasus self-hosted is a fast, low-cost step up from nothing. For a company running critical production databases, verify it against your actual recovery scenarios before committing.

If deploying and managing a backup infrastructure is the blocker, that’s exactly what upready.dev deploys for clients — one-time setup, you own the infrastructure.

---

Sources

1. Installation — Databasus Documentation. https://databasus.com/installation
2. Agent Installation — Databasus Documentation. https://databasus.com/installation/agent
3. Marius Hosting — “How to Install Postgresus on Your Synology NAS”. https://mariushosting.com/how-to-install-postgresus-on-your-synology-nas/
4. Daniil Fedorov, Serverspace.io — “Databasus – Open Source Self-Hosted Database Backup Tool with S3, FTP and Notifications” (January 13, 2026). https://serverspace.io/support/help/databasus-open-source-self-hosted-database-backup-tool-with-s3-ftp-and-notifications/

Primary sources:

• GitHub repository: https://github.com/databasus/databasus (6,106 stars, Apache 2.0 license)
• Official website: https://databasus.com
• Cloud pricing: https://databasus.com (from $9/mo)
• Security documentation: https://databasus.com/security
• Storage destinations: https://databasus.com/storages
• Notification integrations: https://databasus.com/notifiers