Databasus vs WAL-G
Databasus 和 WAL-G 都以最小化 RTO 和 RPO 的灾难恢复为目标，都支持 PostgreSQL 物理备份、WAL 归档和按时间点恢复（PITR）。Databasus 基于 PostgreSQL 17 的原生工具栈远程执行这些备份，复用 PostgreSQL 自带的、久经考验的工具而不是重新造轮子，这一切都在直观的 Web 界面里管理。它适用于任何规模和复杂度的数据库。物理备份要求 PostgreSQL 17 及以上版本；在更早的版本上只能使用逻辑 pg_dump 备份。WAL-G 是一个命令行工具，自带备份引擎，因此能在旧得多的 PostgreSQL 版本上做物理备份，使用自定义流式协议获得略优的性能，支持增量 delta 备份（只备份变化的页），并覆盖更多数据库引擎，包括 MS SQL、FoundationDB 和 Greenplum。
快速对比
下面是 Databasus 与 WAL-G 主要差异的速览：
| 功能 | Databasus | WAL-G |
|---|---|---|
| 备份管理 | ✅ 支持（多个数据库） | ❌ 不支持（仅单个数据库） |
| 其他数据库支持 | ✅ PostgreSQL、MySQL、MariaDB、MongoDB | ✅ PostgreSQL、MySQL、MS SQL |
| 界面 | Web 界面 | 仅命令行 |
| 备份类型 | 逻辑 + 物理 | 物理（WAL 归档） |
| 物理备份所需 PostgreSQL 版本 | 17+（原生） | 9.x+（自带引擎） |
| 备份调度 | ✅ 内置调度器 | 需外部工具（cron） |
| 恢复选项 | ✅ PITR | ✅ PITR |
| 增量备份 | ✅ 块级（PG 17+） | Delta 备份（只备份变化的页） |
| 远程备份 | ✅ 支持 | ❌ 不支持（本地运行） |
| 团队功能 | ✅ 工作区、RBAC、审计日志 | ❌ 仅操作系统级权限 |
| 通知 | ✅ Slack、Teams、Telegram、邮件 | ❌ 需要自写脚本 |
| 加密 | 内置 AES-256-GCM | GPG 或 libsodium |
| 学习曲线 | 很低 | 要求熟练使用命令行 |
| 安装 | 一行脚本或 Docker | 下载二进制文件 + 配置 |
| 适合自托管数据库 | ✅ 适合 | ✅ 适合 |
| 适合云数据库 | ✅ 适合（RDS、Cloud SQL、Azure） | ❌ 只能备份（无法恢复到云端） |
数据库定位
两款工具最显著的差异之一是覆盖的数据库范围：
Databasus：全面的备份管理
Databasus 面向多数据库系统的全面备份管理，并以易用性为核心：
- 多数据库支持：在同一个界面里管理 PostgreSQL、MySQL、MariaDB 和 MongoDB 的数据库备份。
- 统一体验：界面、工作流和功能在所有受支持的数据库上保持一致。
- 版本支持：支持 PostgreSQL 12 到 18 的各个版本，并针对不同版本做了优化。
- 专注管理体验：全部开发精力都投入到改进备份管理体验上。
WAL-G：多数据库支持
WAL-G 最初是 PostgreSQL 备份工具，后来扩展到支持多种数据库系统：
- PostgreSQL：最早、最成熟的实现。
- MySQL/MariaDB：支持基于 binlog 的备份。
- MS SQL Server：Windows 上的 SQL Server 备份。
- MongoDB：文档数据库备份支持。
- FoundationDB：分布式数据库支持。
- Greenplum：数据仓库备份支持。
当全面管理很重要时： 如果你需要通过统一界面管理多个数据库的备份，Databasus 提供了更顺畅的体验。你可以集中管理所有备份，还能使用团队功能，不必为不同数据库切换不同工具。
目标用户
基于各自的设计理念，两款工具服务于不同的用户群体：
Databasus 的用户
Databasus 面向广泛的用户群体，从个人开发者到大型企业：
- 个人开发者：安装简单、界面直观，无需深入了解 PostgreSQL 也能保护个人项目。
- 开发团队：工作区、基于角色的访问控制和审计日志让团队成员安全协作。
- 企业：完善的安全机制、多种存储目标和通知渠道，可满足企业级需求。
- 多数据库环境：同时运行 PostgreSQL、MySQL、MariaDB 或 MongoDB 的组织能从集中式备份管理中受益。
- DBA 和灾难恢复：物理备份、WAL 归档和 PITR，为要求数据近零丢失的关键系统服务。
- DevOps 工程师：Agent 模式可融入现有基础设施，Web 界面和 API 提供可见性和控制力，无需自写脚本。
WAL-G 的用户
WAL-G 面向习惯命令行工具的用户：
- DevOps 工程师：偏好基础设施即代码和基于 CLI 的工作流的人。
- 多数据库环境：同时运行 PostgreSQL 和 MySQL、MongoDB 或其他受支持数据库的组织。
- 云原生部署：使用 Kubernetes 或容器化环境、CLI 工具容易集成的团队。
- 扩展数据库支持：除了 PostgreSQL 还需要备份 MS SQL、FoundationDB 或 Greenplum 的团队。
备份方式
两款工具采用截然不同的备份策略，各有优势：
Databasus：逻辑 + 物理备份
Databasus 同时支持逻辑和物理两种备份策略：
- 物理备份、增量备份和 WAL 备份：通过 PostgreSQL 复制协议远程执行，基于 PostgreSQL 17 的原生工具栈：
pg_basebackup、由服务端 WAL 摘要驱动的块级pg_basebackup --incremental、pg_receivewal和pg_combinebackup。Databasus 复用 PostgreSQL 自带的、久经考验的工具，而不是重新造轮子。要求 PostgreSQL 17 及以上版本。 - 逻辑备份：使用
pg_dump生成可移植的备份，能恢复到不同的 PostgreSQL 版本。这也是 PostgreSQL 17 以下版本唯一可用的备份类型，以及 MySQL、MariaDB 和 MongoDB 的备份途径。 - 数据库上无需安装任何东西：备份通过远程连接完成；封闭网络可以通过 SSH 隧道连接到内部主机或跳板机，数据库无需暴露到公网。
- 高效压缩：两种备份类型都使用 zstd（级别 5），可将体积缩小 4-8 倍。
- 只读访问：逻辑备份只需要 SELECT 权限，最大限度降低安全风险。
WAL-G：物理备份加 WAL 归档
WAL-G 执行文件级（物理）备份并持续归档 WAL：
- 基础备份：对 PostgreSQL 数据目录做完整的文件级复制。
- Delta 备份：只备份发生变化的页，减少存储占用和传输时间。
- WAL 归档：持续归档预写日志（WAL），实现按时间点恢复。
- 写时复制优化：高效处理未变化的数据块。
恢复选项
两款工具都提供恢复能力，但粒度不同：
Databasus 的恢复
- 按时间点恢复：通过 WAL 回放恢复到任意指定的一秒。
- 整集群恢复：从物理备份将整个数据库集群恢复到指定时间点。
- 逻辑恢复：从定时逻辑备份恢复到任意一个备份点。
- 一键恢复：直接在 Web 界面下载并恢复逻辑备份。
- 跨版本兼容：逻辑备份可以恢复到不同的 PostgreSQL 版本。
WAL-G 的恢复
- 按时间点恢复（PITR）：通过 WAL 回放恢复到任意指定的一秒，最大限度减少数据丢失。
- 整集群恢复：将整个数据库集群恢复到指定时间点。
- Delta 恢复：只获取变化的页，恢复速度更快。
- 创建备用节点：从备份创建 PostgreSQL 副本，用于高可用架构。
注意： 两款工具都支持 PITR。WAL-G 额外提供 delta 恢复（只获取变化的页），并使用自定义流式协议，在大规模场景下性能略优。 了解 Databasus 如何支持 PITR →
易用性
两款工具在用户体验上的取向差别很大：
Databasus 的使用体验
- Web 界面：所有备份设置都可以点选配置，不需要命令行。
- 2 分钟安装：一行 cURL 脚本或一条简单的 Docker 命令，立即上手。
- 可视化监控：仪表盘一目了然地展示备份状态、健康检查和历史记录。
- 内置通知：直接在界面里配置 Slack、Teams、Telegram、邮件或 webhook 告警。
- 无需 PostgreSQL 专业知识：为想获得可靠备份、又不想成为数据库专家的开发者而设计。
WAL-G 的使用体验
- 命令行界面：所有操作都通过终端命令完成，如
wal-g backup-push、wal-g backup-fetch。 - 环境变量：配置主要通过环境变量而不是配置文件。
- 外部调度：自动备份需要 cron 任务或外部编排。
- WAL 归档配置：必须配置 PostgreSQL 的
archive_command才能与 WAL-G 集成。 - 要求熟练使用 CLI：文档默认读者熟悉命令行工具和 shell 脚本。
团队功能
对于由多名成员共同管理备份的组织：
Databasus 的团队能力
- 工作区：按项目或团队组织数据库、通知渠道和存储。用户只能看到被邀请加入的工作区。
- 基于角色的访问控制：分配查看者、编辑者或管理员权限，控制每位成员能做什么。
- 审计日志：记录系统中的所有操作和变更，是安全合规与责任追溯的基础。
- 共享通知：团队频道自动收到备份状态更新。
WAL-G 的团队能力
WAL-G 是命令行工具，没有内置团队功能：
- 没有用户管理或访问控制
- 没有操作审计日志
- 团队协作需要借助外部工具和流程
- 访问通过操作系统级权限和云 IAM 策略控制
安全性
两款工具都提供安全功能，但思路不同：
Databasus 的安全性
- AES-256-GCM 加密：所有密码、令牌和凭据都加密存储，加密密钥与数据库分开保存。
- 每个备份独立加密：每个备份文件用主密钥、备份 ID 和随机盐派生的唯一密钥加密。
- 只读数据库访问：只需 SELECT 权限，即使被攻破也不会破坏数据。
WAL-G 的安全性
- GPG 加密：支持对备份文件做基于 GPG 的加密。
- libsodium 加密：另一种基于 libsodium 库的加密方式。
- 云 IAM 集成：利用云厂商的 IAM 控制对存储的访问。
- 没有内置凭据管理：依赖环境变量或外部密钥管理。
存储选项
两款工具都支持云存储，但侧重点不同：
Databasus 的存储
面向各种使用场景的友好选项：
- 本地存储
- Amazon S3 及 S3 兼容服务
- Google Drive
- Cloudflare R2
- Azure Blob Storage
- NAS（网络附加存储）
- Dropbox
WAL-G 的存储
云原生存储选项：
- Amazon S3
- Google Cloud Storage（GCS）
- Azure Blob Storage
- Swift（OpenStack）
- 本地文件系统
- SSH/SFTP
通知
随时掌握备份状态：
Databasus 的通知
内置多种通知渠道：
- Slack
- Discord
- Telegram
- Microsoft Teams
- 邮件
- Webhook
WAL-G 的通知
WAL-G 没有内置通知支持，实现通知需要：
- 围绕备份命令自写脚本
- 集成外部监控工具
- 手动解析日志并配置告警
- 接入 Prometheus、Grafana 等工具或自研方案
压缩
两款工具都提供压缩来缩小备份体积：
Databasus 的压缩
- zstd 压缩：使用 zstd 级别 5，在速度和压缩率之间取得平衡。
- 体积缩小 4-8 倍：典型压缩率下运行时开销只增加约 20%。
- 自动启用：压缩默认开启，无需任何配置。
WAL-G 的压缩
- 多种算法：支持 LZ4、LZMA、Brotli 和 zstd。
- 级别可调：可精细权衡压缩率与速度。
- 按文件类型压缩：WAL 文件和基础备份可以使用不同的压缩设置。
结论
在 PostgreSQL 备份生态中，Databasus 和 WAL-G 满足的是不同的需求。如何选择取决于你的数据库环境、团队结构和运维偏好。
选择 Databasus，如果：
- 你需要在同一个界面里全面管理 PostgreSQL 备份
- 相比命令行工具，你更喜欢 Web 界面
- 你需要团队协作功能（工作区、RBAC、审计日志）
- 你想要内置的 Slack、Teams、Telegram 等通知
- 你想要内置调度，不必额外配置 cron
- 你想在一个带调度、通知和团队功能的仪表盘里管理多个数据库的备份
- 你想快速上手，不需要太多数据库知识
- 内置备份加密对你很重要
- 你使用云托管数据库（AWS RDS、Google Cloud SQL、Azure）或自托管数据库
选择 WAL-G，如果：
- 你需要在 PostgreSQL 17 以下版本上做物理或增量备份（WAL-G 自带备份引擎）
- 你需要 delta 备份（只备份变化的页）来减少存储占用和传输时间
- 你需要支持 MS SQL、FoundationDB 或 Greenplum
- 你偏好命令行工具和基础设施即代码的工作流
- 你想要多种压缩算法（LZ4、LZMA、Brotli、zstd）并做精细调优
- 你的团队有管理 CLI 工具的 DevOps 经验
两款工具都支持物理备份、WAL 归档和 PITR，都以最小化 RTO 和 RPO 的灾难恢复为目标。Databasus 适用于任何规模和复杂度的数据库，并提供 Web 界面、团队功能，以及覆盖自托管和云托管数据库的逻辑与物理备份。
对于偏好 CLI 工作流的团队，WAL-G 仍然是出色的选择，它有独特的优势：delta 备份（只备份变化的页）、性能略优的自定义流式协议，以及对 PostgreSQL 之外更多数据库引擎的支持。