它解决什么问题
PostgreSQL 的集中式备份与恢复工具
Barman
STACKS数据与存储EnterpriseDB · PostgreSQL 备份工具
所属栏目
数据与存储
关系型（事务）
形态
PostgreSQL 备份工具
开源 / 商业 / 托管形态
许可证
GPL-3.0
以官方仓库为准
数据日期
2026-10-27
条目信息核对到这一天
Barman 编辑总结
整理日期：2026-10-27 · 关系型（事务） · 同分类 9 个
分类关系型（事务）数据与存储下的分类
形态PostgreSQL 备份工具交付形态，决定怎么接入
主要语言Python以官方仓库为准
许可证GPL-3.0商用前核对 LICENSE 原文
同分类条目9可与下方对比表横向比较
上面几项是本条目的关键信息摘要，正文整理见下方「详细说明」与「关键信息」。
详细说明
核心优势
统一管理多套 PostgreSQL 实例的备份，全量与增量都能排期，配合归档日志可做时间点恢复；备份状态与保留策略集中查看，恢复演练不必临时拼脚本。
注意事项
只覆盖 PostgreSQL，且要提前配好归档与流复制才能做时间点恢复；恢复仍要人工确认目标，跨版本恢复与超大库的耗时要有预期。
适合场景
有多套 PostgreSQL、需要统一备份与时间点恢复的团队。
不适合场景
单实例小库、用托管服务自带备份就够的场景。
关键信息
- 维护方
- EnterpriseDB
- 分类
- 关系型（事务）
- 形态
- PostgreSQL 备份工具
- 主要语言
- Python
- 许可证
- GPL-3.0
- 代码仓库
- https://github.com/EnterpriseDB/barman
- 官方文档
- https://docs.pgbarman.org/
特性标签
备份PITRPG
标签取自各项目公开信息里的分类字段，未做二次归类。
同分类数据与存储对比
| 方案 | 形态 | 定位 | 许可证 |
|---|---|---|---|
| MariaDB | 关系型数据库（MySQL 分支） | MySQL 分支，把开源协议留在 GPL | GPL-2.0 |
| CockroachDB | 分布式 SQL 数据库（兼容 PostgreSQL） | 跨地域部署自带强一致的分布式 SQL 库 | BSL-1.1 |
| TiDB | 分布式关系型数据库（MySQL 兼容） | 计算存储分离、兼容 MySQL 的分布式库 | Apache-2.0 |
| TimescaleDB | PostgreSQL 时序扩展 | 给 Postgres 补上时序表与连续聚合 | Timescale License（部分 Apache-2.0） |
| QuestDB | 时序数据库 | 面向高写入吞吐的列式时序数据库 | Apache-2.0 |
| RisingWave | 流式数据库 | 用 SQL 做增量计算的流式数据库 | Apache-2.0 |
| Materialize | 流式数据库 | 持续维护查询结果的流式数据库 | BSL-1.1（源码可见） |
| pgBackRest | PostgreSQL 备份与恢复工具 | 面向大库的 PostgreSQL 备份工具 | MIT |
| Patroni | PostgreSQL 高可用模板 | 给 PG 做自动故障切换的模板 | MIT |
同一分类内的方案才适合横向比较；定位列已按详情页原文截断
相关链接
数据与存储 常见问题
关系库、缓存、搜索、向量库，要各挑一个吗？
按数据形态分：事务数据用关系库，热点与计数用缓存，全文与日志检索用搜索型或分析型库，语义检索用向量库。规模不大时，PostgreSQL 的扩展（pgvector、全文检索、JSONB）往往能顶替后三类，可以少维护一套系统。
向量库要单独部署，还是用 PostgreSQL 的向量扩展？
数据量在千万级向量以内、且已经在用 PostgreSQL 时，pgvector 往往够用，少一套运维；超过这个量级或要做大规模混合检索，再考虑专用向量库。
数据说明
所属栏目数据与存储分类：关系型（事务）
数据来源项目官方文档与代码仓库定位、优势与许可条件取自官方资料，中文为归纳版
数据日期2026-10-27条目信息核对到这一天；官方更新后以官方为准
口径边界整理不改写能力、价格与许可证以官方为准；本站不打分、不排推荐名次
页面文字只做中文整理，数值不改写；仓库地址、许可证与版本请以官方仓库为准，本站与所列项目无隶属关系。
继续浏览数据与存储
返回栏目列表
上一个条目已经是第一个了
下一个条目已经是最后一个了
同分类的其他数据与存储
更多条目信息取自各项目官方仓库与文档；定位、优势与注意事项为中文归纳，数值不改写，仓库地址、许可证与版本以官方为准。
