Back to browse
GitHub Repository

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

7,048 starsGo

Databasus v3.16.0 – new release of self-hosted PostgreSQL backup tool

by rostislav_dugin·Feb 22, 2026·3 points·0 comments

AI Analysis

●●SolidSolve My ProblemNiche Gem

240k Docker pulls and most-starred backup repo, but GFS retention is the only novelty here.

Strengths
  • 240k Docker Hub pulls and most-starred backup tool on GitHub—real adoption signals
  • GFS retention policy (hourly/daily/weekly/monthly/yearly) genuinely addresses enterprise backup requirements
  • Multi-database support (PostgreSQL, MySQL, MongoDB) plus rich destination options (S3, Google Drive, SFTP, rclone)
Weaknesses
  • Solves a well-served problem—Veeam, pgBackRest, WAL-G already dominate; GFS alone doesn't shift the category
  • Feature-checklist approach (notifications, scheduling, compression) is table stakes, not differentiating
Target Audience

DevOps engineers, DBAs, developers managing databases

Similar To

pgBackRest · WAL-G · Veeam

Post Description

Hi!

I want to share the latest important updates for my open source tool for scheduled database backups (with focus on PostgreSQL).

A quick recap:

- Supported databases: PostgreSQL, MySQL, MariaDB and MongoDB

- Many storage destinations: local storage, S3, Google Drive, Dropbox, SFTP, rclone and more

- Notifications: Slack, Discord, Telegram, email, webhook

GitHub - https://github.com/databasus/databasus

Website - https://databasus.com

In 2025 Databasus renamed from Postgresus when it became popular and support for other databases was added.

Primary audience for the project is developers, DevOps engineers and DBAs. Now project is the most GitHub starred repository for backups (surpassed even WAL-G and pgBackRest). There are ~240k pulls from Docker Hub (both of previous Postgresus and Databasus images).

New features:

1. GFS retention policy

GFS is an acronym for Grandfather-Father-Son. It allows to keep last N hourly, daily, weekly, monthly and yearly backups.

This is needed to keep backups over wide period of time within reasonable storage space.

Before only X days or months were supported.

By default now is used:

- Keep 24 hourly backups

- Keep 7 daily backups

- Keep 4 weekly backups

- Keep 12 monthly backups

- Keep 3 yearly backups

Usually this strategy is used by enterprises which needs long period of backups retention.

2. Encrypted backups are stored along with their metadata to decrypt them without Databasus itself

Before, if server with Databasus is destroyed, you were not able to decrypt backups without Databasus itself. So you had to make backups of Databasus internal DB.

Now backups are stored in S3\Google Drive\other storages with meaningful names with their encryption metadata in format:

- {database-name}-{timestamp}-{backup-id}.dump

- {database-name}-{timestamp}-{backup-id}.dump.metadata

In case of server destruction, you need only `secret.key` to decrypt backups and restore via pg_dump, mysqlbackup, mongodump or other tools. It is important for me to not vendor-lock users on my tool (even despite the fast it's OSS)

Full guide - https://databasus.com/how-to-recover-without-databasus

Similar Projects

Developer Tools●●Solid

DB Pro Studio – A self-hosted, collaborative database client

Runs in the browser, ships as a Docker image, and emphasizes shared connections, collaborative queries and dashboards — nice for teams that want DB access without handing out credentials. The UI in the screenshot looks thoughtful (mobile-ready panels, query editor, change diffs), but the product sits in a crowded niche; the site should call out concrete differentiators like RBAC, audit logging, connection pooling or performance to justify switching from existing tools.

SlickSolve My Problem
upmostly
104mo ago