databasus: Open Source Databases

What is databasus?

Databasus is a free, open source, self-hosted backup tool for PostgreSQL — with MySQL, MariaDB and MongoDB also indicated by its badges and topics — that targets Point-In-Time Recovery at low RPO/RTO and verifies backups by performing a real restore rather than a checksum check, built for DevOps, platform and database teams that want backups under their own control.

What it is

Databasus is an Apache-2.0 licensed project written in TypeScript, listed in this registry under Infrastructure & Operations / Databases, with its website at databasus.com. The repository carries 8,584 stars, 539 forks and 16 open issues, and its topics place it in the DevOps, Docker and Kubernetes world alongside PostgreSQL, MySQL, MariaDB and MongoDB operations. The README describes it as a free, open source and self-hosted tool to back up PostgreSQL, and the project badges repeat that self-hosted, open source positioning while linking to a Docker image at databasus/databasus. It runs on Linux, macOS or Windows and combines backup creation, storage upload, retention, encryption, restore testing and alerting in one tool.

The concrete problem it addresses is the gap between a backup that exists on disk and a backup that actually restores. Databasus performs physical, full, incremental, WAL streaming and logical backups, but its restore verification step spins up a database container, runs a real restore and checks the restored size against the backup, then reports every table with its row count. That replaces the assumption that a file which is merely intact is a usable recovery point, and it consolidates scheduling, storage upload, retention pruning, encryption and notifications into a single self-hosted service instead of a collection of hand-rolled scripts. For disaster recovery, WAL streaming captures the write stream continuously so recovery can reach a chosen point in time at low RPO and RTO.

Key capabilities

Five backup types: physical (file-level copy of the entire database cluster using the PostgreSQL native incremental backups mechanism), full, incremental, WAL streaming for Point-in-Time Recovery, and logical dumps in the engine-native binary format, compressed and suitable for parallel restore.
Restore verification that performs a real restore, compares restored size against the backup, and lists every table with its row count, triggered after each backup or on an hourly, daily, weekly, monthly or cron schedule.
Scheduling options covering hourly, daily, weekly, monthly or cron runs, plus precise timing such as 4 AM during low traffic, with smart compression delivering 4-8x space savings at roughly 20% overhead.
Retention policies by time period, by count, by GFS layering (hourly, daily, weekly, monthly and yearly kept independently), and by per-backup and total storage size caps.
Storage destinations including local disk, S3, Cloudflare R2, Google Drive, NAS, Dropbox, SFTP and Rclone.
Notifications through Email, Telegram, Slack, Discord, Teams, Mattermost and webhooks, for success and failure, full reports or failure-only alerts.
AES-256-GCM encryption of backup files and encrypted secrets, so backups stay useless to attackers when held in shared storage such as S3 or Azure Blob Storage.

Who uses it and how

DevOps and platform teams running PostgreSQL in Docker or Kubernetes, who need scheduled backups without building their own cron and upload pipeline.
Teams with low RPO/RTO recovery requirements that lean on WAL streaming and Point-in-Time Recovery for disaster recovery.
Organisations with long-term history obligations that use GFS retention to keep hourly, daily, weekly, monthly and yearly backups independently.
Operators who store encrypted backups in shared or third-party cloud storage and rely on the zero-trust storage model rather than trusting the bucket.
Teams routing success and failure alerts into existing channels such as Slack, Discord, Teams, Mattermost, Telegram, email or webhooks, and documentation is available in English, Russian, Spanish, Portuguese, Chinese and French.

Getting started

Deploy the self-hosted Docker image databasus/databasus, with setup details in the README's Installation section and on databasus.com.

How it compares

The facts provided do not name any paid product that Databasus replaces, and they do not name any similar backup tool either. On the evidence available, it stands alone in this registry.

When to use it — and when not to

A self-hoster runs the application itself and supplies the surrounding infrastructure: a storage destination such as S3, Google Drive, NAS, Dropbox, SFTP or Rclone, plus accounts for whichever notification channels are configured. Teams that want a fully managed service, a vendor support arrangement or a hosted option should not pick it, because no hosted offering is named in the facts. Note also that the README excerpt provided is truncated mid-sentence in the security section, so the full secrets-encryption claims must be confirmed in the repository docs, and the facts give no release history beyond a last push on 2026-09-17 and 16 open issues.

project readme (upstream, from github) — read inline

PostgreSQL backup tool

Databasus is a free, open source and self-hosted tool to backup PostgreSQL. Make backups with different storages (S3, Google Drive, FTP, etc.) and notifications about progress (Slack, Discord, Telegram, etc.). With a focus on Point-in-Time Recovery at low RPO/RTO

English • Русский • Español • Português • 中文 • Français

Features • Installation • Usage • License • Contributing

🌐 Databasus website

✨ Features

📦 Backup types

Physical: file-level copy of the entire database cluster over PostgreSQL native incremental backups mechanism (read more)
- Full: a complete, self-contained copy of the cluster
- Incremental: stores only what changed since the previous full backup, so backups stay small and fast
- WAL streaming: continuously captures the database write stream, enabling Point-in-time recovery (PITR). Designed for disaster recovery and near-zero data loss
Logical: native dump of the database in its engine-specific binary format (compressed, suitable for parallel restore)

🔄 Scheduled backups

Flexible scheduling: hourly, daily, weekly, monthly or cron
Precise timing: run backups at specific times (e.g., 4 AM during low traffic)
Smart compression: 4-8x space savings with balanced compression (~20% overhead)

🧪 Restore verification (docs)

Databasus performs a real restore to confirm backups are usable, not just intact on disk or checksum check.

Triggers: after each backup or on a flexible schedule (hourly, daily, weekly, monthly or cron)
Real restore: spins up a database container, runs the restore and checks the restored size against the backup
Report: lists every table with its row count
Optional notifications: send the report or failure-only alerts through any configured notifier

🗑️ Retention policies

Time period: Keep backups for a fixed duration (e.g., 7 days, 3 months, 1 year)
Count: Keep a fixed number of the most recent backups (e.g., last 30)
GFS (Grandfather-Father-Son): Layered retention — keep hourly, daily, weekly, monthly and yearly backups independently for fine-grained long-term history (enterprises requirement)
Size limits: Set per-backup and total storage size caps to control storage usage

🗄️ Multiple storage destinations (view supported)

Local storage: Keep backups on your VPS/server
Cloud storage: S3, Cloudflare R2, Google Drive, NAS, Dropbox, SFTP, Rclone and more
Secure: All data stays under your control

📱 Notifications (view supported)

Multiple channels: Email, Telegram, Slack, Discord, Teams, Mattermost, webhooks
Real-time updates: Success and failure notifications
Team integration: Perfect for DevOps workflows

🔒 Enterprise-grade security (docs)

AES-256-GCM encryption: Enterprise-grade protection for backup files
Zero-trust storage: Backups are encrypted and remain useless to attackers, so you can safely store them in shared storage like S3, Azure Blob Storage, etc.
Encryption for secrets: Any sensitive data is encrypted and never exposed, even in logs or error messages
Read-only user: Databasus uses a read-only user by default for backups and never stores anything that can modify your data

👥 Suitable for teams (docs)

Workspaces: Group databases, notifiers and storages for different projects or teams
Access management: Control who can view or manage specific databases with role-based permissions
Audit logs: Track all system activities and changes made by users
User roles: Assign viewer, member, admin or owner roles within workspaces
OpenTelemetry logs: Export application and audit logs to an external system (by default they are also written to a local file)

🎨 UX-Friendly

Designer-polished UI: Clean, intuitive interface crafted with attention to detail
Dark & light themes: Choose the look that suits your workflow
Mobile adaptive: Check your backups from anywhere on any device

💾 Supported databases

PostgreSQL: 14, 15, 16, 17 and 18 (physical and logical)
MySQL: 5.7, 8.0, 8.4 and 9 (logical only)
MariaDB: 10, 11 and 12 (logical only)
MongoDB: 4.2+, 5, 6, 7 and 8 (logical only)

🐳 Self-hosted & secure

Docker-based: Easy deployment and management
Privacy-first: All your data stays on your infrastructure
Open source: Apache 2.0 licensed, inspect every line of code
Build-in SSH: Connect to your databasus via SSH tunnel

📦 Installation (docs)

You have four ways to install Databasus:

Automated script (recommended)
Simple Docker run
Docker Compose setup
Kubernetes with Helm

📦 Installation

You have four ways to install Databasus: automated script (recommended), simple Docker run, or Docker Compose setup.

Option 1: Automated installation script (recommended, Linux only)

The installation script will:

✅ Install Docker with Docker Compose (if not already installed)
✅ Set up Databasus
✅ Configure automatic startup on system reboot

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

Option 2: Simple Docker run

The easiest way to run Databasus:

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

The same image lives on GitHub's registry — use ghcr.io/databasus/databasus:latest if Docker Hub rate-limits your pull.

This single command will:

✅ Start Databasus
✅ Store all data in ./databasus-data directory
✅ Automatically restart on system reboot

Option 3: Docker Compose setup

Create a docker-compose.yml file with the following configuration:

services:
  databasus:
    container_name: databasus
    image: databasus/databasus:latest
    ports:
      - "4005:4005"
    volumes:
      - ./databasus-data:/databasus-data
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "databasus", "healthcheck"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 60s

Then run:

docker compose up -d

Option 4: Kubernetes with Helm

For Kubernetes deployments, install directly from the OCI registry.

Add --set image.repository=ghcr.io/databasus/databasus to any of the commands below to pull image from GHCR instead of Docker Hub.

With ClusterIP + port-forward (development/testing):

helm install

Frequently asked questions

Is databasus free to use?

databasus is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does databasus do?

PostgreSQL backup tool with Point-In-Time-Recovery and restore verification

What is databasus written in?

databasus is primarily written in TypeScript. Its source is publicly available at https://github.com/databasus/databasus, and it has 8,584 GitHub stars.