pg_dump Alternative

For logical backups, Databasus is built on top of pg_dump. Rather than replacing pg_dump, Databasus extends its capabilities with backups management, a web interface, automated scheduling, cloud storage integration, notifications, team collaboration features and built-in encryption. Beyond logical backups, Databasus also supports physical backups, incremental backups with WAL archiving and Point-in-Time Recovery.

Quick comparison

Here's an overview of how Databasus extends the core pg_dump functionality:

Featurepg_dumpDatabasus
Backup enginepg_dumpBuilt on pg_dump
Backups management❌ No✅ Yes
Support of other DBsPostgreSQL onlyPostgreSQL, MySQL, MariaDB, MongoDB
InterfaceCommand-lineWeb UI + API
SchedulingManual or cron scripts✅ Built-in scheduler
Storage destinationsLocal filesystemLocal, S3, Google Drive, R2, Azure, NAS, Dropbox
Compressiongzip, LZ4, zstd (manual)zstd (automatic, optimized)
EncryptionExternal tools required✅ AES-256-GCM built-in
Notifications❌ None✅ Slack, Teams, Telegram, Email, Webhooks
Team features❌ None✅ Workspaces, RBAC, audit logs
Retention policiesManual cleanup scripts✅ Automatic retention
Health monitoring❌ None✅ Built-in health checks
Physical backups❌ No✅ Yes
Incremental backups❌ No✅ Block-level (PG 17+)
Point-in-Time Recovery❌ No✅ Yes
Remote backups✅ Yes (CLI)✅ Yes

What is pg_dump?

pg_dump is PostgreSQL's native utility for creating logical backups. It's been part of PostgreSQL since the beginning and is the standard tool for database exports.

pg_dump strengths

  • Portable backups: Creates SQL or custom format dumps that can be restored to different PostgreSQL versions.
  • Selective backups: Can export specific tables, schemas or entire databases.
  • Consistent snapshots: Uses PostgreSQL's MVCC to create consistent backups without blocking writes.
  • Widely supported: Available on every PostgreSQL installation, well-documented and battle-tested.
  • Flexible output formats: Plain SQL, custom, directory or tar formats.

pg_dump limitations

While pg_dump is powerful, using it in production typically requires additional scripting:

  • No built-in scheduling: Requires cron jobs or external schedulers.
  • Local storage only: Outputs to local filesystem; cloud uploads require additional scripts.
  • No encryption: Backup files are unencrypted by default; requires piping through gpg or similar tools.
  • No notifications: No way to alert on backup success or failure without custom scripting.
  • No retention management: Old backups must be cleaned up manually or via scripts.
  • Command-line only: No visual interface for monitoring or management.

How Databasus extends pg_dump

Databasus uses pg_dump as its backup engine, preserving all the benefits of logical backups while adding enterprise features on top.

Under the hood: When you trigger a backup in Databasus, it executes pg_dump with optimized parameters, then handles compression, encryption and upload to your configured storage destination.

Web interface

Instead of remembering pg_dump command-line options, Databasus provides a web UI where you can:

  • Add databases with a guided connection wizard
  • Configure backup schedules with visual controls
  • Monitor backup history and status at a glance
  • Download or restore backups with one click
  • View database health and availability charts

Optimized compression

Databasus uses zstd compression (level 5) by default, which provides:

  • 4-8x size reduction compared to uncompressed dumps
  • ~20% runtime overhead — much faster than gzip
  • Automatic handling — no need to pipe through compression tools

Beyond pg_dump: Physical backups and PITR

While Databasus builds on pg_dump for logical backups, it also goes beyond what pg_dump can offer:

  • Physical backups: File-level copies of the entire database cluster via pg_basebackup. Faster backup and restore for large databases.
  • Incremental and WAL backups: Block-level incremental backups via pg_basebackup --incremental (driven by server-side WAL summaries) plus continuous WAL streaming via pg_receivewal, enabling Point-in-Time Recovery — restore to any second between backups.
  • Disaster recovery: Designed for near-zero data loss requirements with physical base backups and continuous WAL streaming.

These backups are built on PostgreSQL 17's native backup mechanism, so Databasus reuses PostgreSQL's own battle-tested tooling instead of re-inventing it. They require PostgreSQL 17 or newer; on older versions only logical pg_dump backups are available. Everything runs remotely from the Databasus host over the replication protocol, so nothing is installed on the database server. Closed networks are reached through an SSH tunnel to an internal host or a bastion, so the database never has to be exposed publicly. Read how physical and PITR backups work.

Backup automation

One of the most common challenges with pg_dump is setting up reliable automated backups.

Traditional pg_dump automation

A typical pg_dump automation script might look like:

#!/bin/bash
# Backup script for pg_dump
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/backups"
DB_NAME="mydb"

# Create backup
pg_dump -Fc -h localhost -U postgres $DB_NAME > $BACKUP_DIR/$DB_NAME_$DATE.dump

# Compress (if not using custom format)
# gzip $BACKUP_DIR/$DB_NAME_$DATE.sql

# Encrypt
gpg --encrypt --recipient backup@company.com $BACKUP_DIR/$DB_NAME_$DATE.dump

# Upload to S3
aws s3 cp $BACKUP_DIR/$DB_NAME_$DATE.dump.gpg s3://my-bucket/backups/

# Cleanup old backups (keep last 7 days)
find $BACKUP_DIR -name "*.dump*" -mtime +7 -delete

# Send notification on failure
if [ $? -ne 0 ]; then
  curl -X POST https://hooks.slack.com/... -d '{"text":"Backup failed!"}'
fi

This script needs to be maintained, tested and monitored. Each database requires its own cron entry.

Databasus automation

With Databasus, the same functionality is built-in:

  • Visual scheduler: Set hourly, daily, weekly, monthly or cron backups with specific times.
  • Automatic compression: zstd compression applied automatically.
  • Built-in encryption: AES-256-GCM encryption with unique keys per backup.
  • Cloud upload: Direct upload to S3, Google Drive, Cloudflare R2, Azure or other destinations.
  • Retention policies: Automatic cleanup of old backups based on your retention settings.
  • Notifications: Alerts to Slack, Teams, Telegram, Email on success or failure.

Storage options

pg_dump writes to the local filesystem. Getting backups to cloud storage requires additional tools and scripts.

Databasus storage destinations

Databasus supports multiple storage destinations out of the box:

  • Local storage
  • Amazon S3 and S3-compatible services
  • Google Drive
  • Cloudflare R2
  • Azure Blob Storage
  • NAS (Network-attached storage)
  • Dropbox

Each database can have its own storage destination and you can configure multiple destinations for redundancy.

View all storage options →

Notifications

Knowing when backups succeed or fail is critical for data protection.

pg_dump notifications

pg_dump has no notification system. You need to:

  • Write wrapper scripts that check exit codes
  • Integrate with external monitoring tools
  • Set up custom alerting pipelines

Databasus notifications

Databasus includes built-in notifications to:

  • Slack
  • Discord
  • Telegram
  • Microsoft Teams
  • Email
  • Webhooks (for custom integrations)

Configure which events trigger notifications: backup success, backup failure or both.

View all notification channels →

Team features

pg_dump is a single-user command-line tool. Databasus adds collaboration features for teams:

Databasus team capabilities

  • Workspaces: Organize databases, notifiers, and storages by project or team. Users only see workspaces they're invited to.
  • Role-based access control: Assign viewer, editor or admin permissions to control what each team member can do.
  • Audit logs: Track all system activities and changes. Essential for security compliance and accountability.
  • Shared notifications: Team channels receive backup status updates automatically.

Learn more about access management →

Security

Security is where Databasus adds significant value over raw pg_dump usage.

pg_dump security

pg_dump creates unencrypted backup files. Securing them requires:

  • Piping output through encryption tools (gpg, openssl)
  • Managing encryption keys separately
  • Ensuring secure key storage and rotation
  • Setting up proper file permissions

Databasus security

Databasus implements security at multiple levels:

  • AES-256-GCM encryption: All passwords, tokens and credentials are encrypted. The encryption key is stored separately from the database.
  • Unique backup encryption: Each backup file is encrypted with a unique key derived from master key, backup ID and random salt.
  • Read-only database access: Enforces SELECT permissions only, preventing data corruption even if compromised.

Learn more about Databasus security →

Restore process

Both tools support restoring backups, but with different workflows.

Restoring pg_dump backups

Restoring a pg_dump backup requires:

  1. Locating the backup file
  2. Decrypting if encrypted
  3. Decompressing if compressed
  4. Running pg_restore or psql with correct parameters

Restoring Databasus backups

Databasus simplifies restoration:

  • One-click download: Download any backup directly from the web interface.
  • Automatic decryption: Backups are decrypted automatically when downloaded.
  • Restore commands provided: Databasus shows the exact pg_restore command for each backup.
  • Parallel restore support: Utilize multiple CPU cores for faster restoration of large databases.

Installation

pg_dump installation

pg_dump comes with PostgreSQL. If you have PostgreSQL installed, you have pg_dump.

Databasus installation

Databasus offers multiple installation methods:

  • One-line script: Installs Docker (if needed), sets up Databasus and configures automatic startup.
  • Docker run: Single command to start with embedded PostgreSQL.
  • Docker Compose: For more control over deployment.

View installation guide →

Conclusion

pg_dump is PostgreSQL's proven backup utility, and Databasus builds directly on top of it. The choice between using pg_dump directly or through Databasus depends on your needs.

Use pg_dump directly if:

  • You need one-off or ad-hoc database exports
  • You're comfortable writing and maintaining shell scripts
  • You have existing automation infrastructure (Ansible, Terraform, etc.)
  • You only need local backups without cloud storage
  • You're a single developer with simple needs

Use Databasus if:

  • You want automated, scheduled backups without writing scripts
  • You need to store backups in cloud storage (S3, Google Drive, etc.)
  • You want built-in encryption without managing keys manually
  • You need notifications when backups succeed or fail
  • You're working in a team and need collaboration features
  • You prefer a visual interface over command-line tools
  • You want automatic retention policies and cleanup
  • You need physical backups, incremental backups or Point-in-Time Recovery for disaster recovery

Databasus builds on pg_dump for logical backups and extends it with automation, security and team features. Beyond that, Databasus also supports physical backups, incremental backups with WAL archiving and Point-in-Time Recovery — capabilities that pg_dump simply cannot provide.