The Problem

PostgreSQL backups are easy to take and hard to trust. Standard tools like pg_dump or pg_basebackup produce archives, but verifying they actually restore—and restoring to a specific point in time—requires manual orchestration across storage, notification, and test infrastructure. Databasus packages full, incremental, and WAL-streaming backups with automated restore verification into a single self-hosted service.

What This Does

Databasus is a Go backend (backend/, 724 Go files) with a React/TypeScript frontend (frontend/, 419 files) and a separate verification agent (agent/verification/, 95 files). It manages physical backups via PostgreSQL's native incremental mechanism, logical dumps, WAL streaming for PITR, retention policies (time, count, GFS), and scheduled restores that spin up a container and validate row counts per table.

The architecture is documented in 15 ADRs (adr/), including 0008-why-pg17-native-backups-with-mandatory-wal-summary.md and 0012-pg-basebackup-tar-fetch-and-manifest-reconstruction.md. The restore verification agent is a standalone Go binary that runs the actual restore in an isolated container.

How It Is Wired

The system has two independent entry points:

  1. Backend service: backend/cmd/healthcheck.go and backend/cmd/cleanup_test_db/main.go are the only explicit mains; the primary server entry is not among the listed entry points, so the main API server bootstrap is unmapped. The backend likely starts an HTTP/Express service (Express is detected in the stack) that handles backup scheduling, storage backends (S3, Google Drive, FTP), and notifiers (Slack, Discord, Telegram).
  1. Verification agent: agent/verification/cmd/main.go is the real workhorse. It executes a restore against a spun-up database container, checks restored size against the backup manifest, and reports per-table row counts. cmd/reexec.go handles privilege re-escalation for the restore container. The e2e harness (agent/verification/e2e/) includes mock-server/main.go, a fixture generator, and Dockerfiles for builder/runner images.

The verification agent's Makefile and go.mod show it builds as a standalone binary. The e2e/docker-compose.yml wires the agent, mock server, and fixture generator together for testing.

The blast radius is concentrated in agent/verification/cmd/main.go—every restore verification path routes through it, and a bug there means backups pass verification when they shouldn't. The frontend's setSshTunnelAuthTypeAndClearUnusedSecrets.ts is the only file that mutates stored credentials, making it a security-sensitive hub.

How To Use It

Setup and running commands are not documented in the provided README excerpt. The repo contains a root Dockerfile, .env.example, and docker-compose.yml (implied by the deploy directory), but no explicit build/run instructions were captured.

# Build the verification agent (from agent/verification/)
make build  # or: go build -o agent ./cmd/main.go

# Backend container build
docker build -t databasus .

Configuration lives in .env.example at root and agent/verification/.env.example for the agent. The e2e environment uses agent/verification/e2e/.env.example. Exact variable names are not in the provided excerpt.

Real-World Use

A team runs Databasus as a Docker service on a small VM. It schedules a full backup nightly at 2 AM, WAL streaming continuously, and a verification job at 6 AM. The verification agent spins up a PostgreSQL container, restores the latest backup, compares table row counts against the manifest, and posts a report to Slack. If the restore fails, the team gets alerted before the backup is needed for recovery.

Code Health & Issues

Static analysis flagged one low-severity item:

  • Low/Security - Secret-shaped paths present: backend/internal/features/tests/logical/mongodb/testdata/ssl/server.pem contains a PEM file (test fixture, likely benign), and frontend/src/entity/databases/model/sshtunnel/setSshTunnelAuthTypeAndClearUnusedSecrets.ts handles credential clearing—verify the logic actually wipes secrets on tunnel type change.

SDLC observations from the structure:

  • Med - 325 test files exist, but the backend has no explicit test runner config visible; CI runs via GitHub Actions (.github/workflows/ci-release.yml, codeql.yml, dependency-review.yml). CodeQL and dependency review are active.
  • Low - .trivyignore and .coderabbit.yaml show security scanning is configured, but the ignore file contents are not reviewed.

The Bottom Line

Databasus is a serious, well-architected PostgreSQL backup tool with a strong focus on PITR and restore verification—the hardest part of backup reliability. The Go backend and verification agent are well-separated, and the ADR set shows deliberate engineering decisions. The fork has zero stars and no evidence of active maintenance beyond the CI config, so treat it as a codebase to evaluate, not a product to adopt blindly. Teams needing a self-hosted, verifiable PostgreSQL backup pipeline should evaluate it; teams wanting a maintained, supported tool should look at the upstream project.