每个 Docker 单独使用 SQLite 和中心化部署 PostgreSQL 怎么选择？

我有一些数量的 Self-Hosted 的服务。大部份或多或少需要用到数据库。因为我自己并没有充分使用过 PostgreSQL ，所以从一开始的时候在每个 Docker 需要用数据库的时候就选择其中的 SQLite 方案。

但随着 Docker 的数量增多，其中需要备份迁移的数据也越来越多。我开始考虑是不是用一个中心化部署的 PostgreSQL 来替代数量众多的分散化的 SQLite 更好一些？

@yinmin #17 用外部互斥锁，保证同一时间只有一个写入呢？

我试了下，WAL 模式下，开事务写入一条 1KB 记录再提交，每秒能有 3W 的 TPS ？

而且 WAL 模式下，写不影响读，意味着任何时候，都能有无数个并发读？

@yinmin 你这个说的完全错了。如果 sqlite 能顶的话，高并发你换 pg 不见得能顶得住。sqlite 的性能几乎等同于内存数据库，强得一逼好不好。

如果资源足够，分开部署 + 数据湖统一管理 + 统一备份才是王道。

分开部署可以避免集中式数据库的单点问题与冷热数据混在一起的性能处理麻烦的问题。

数据湖统一采集管理可以方便你对数据做分析与利用。

统一备份可以使用单一的存储备份一体机来降低备份成本，配合自建 OpenZFS 的实时压缩与实时去重，甚至可以做到 CDP （ Continuous Data Protection ，持续数据保护，数据库备份的高端功能，每 2-5 秒一个快照，每小时合并一次快照，由 OpenZFS 提供底层的 block 级别的实时去重可以支持几乎无限个快照恢复节点）。

单例数据库无非是可用性和数据备份问题，听起来楼主好像都是 Self Hosted 的自用程序，可用性没那么高，那么做一个 Postgres 主从即可；至于备份，用 crontab 定时跑一个脚本，docker exec 跑到 Postgres 容器里用 pg_dumpall 把数据库数据拿出来即可

其实现在 postgresql 也可以进程内使用，隔壁的 pglite.dev 了解一下(不过目前只适配了 js 版本，因为是 wasm ）这样以后迁移到正统的 postgresql 也没很高成本了

其次，用 sqlite 也不是不能搞备份迁移，隔壁 litestream 了解一下，虽然同步方面只能单个写入者，没法多个，但备份需求这点是没问题的

如果有的选 我不会用 sqlite 在所有软件上

容器就不该有状态

自部署服务自用的话，强烈建议用 sqlite ，不会有冲突，不会有额外的耦合，起新服务不用维护共用的数据库，删服务也不用维护。

只能用 pg 我的都是每个服务单独起，不想太折腾。

不怕麻烦有精力维护并且有做高可用的话，共用一个是个比较省硬件资源的方法。

比如 vaultwarden ，你可以用 sqlite 也可以用 pg 。


sqlite 可以定期备份到 s3 ，pg 的话，你也要定期备份。

self host 的话，我个人比较喜欢每个服务不依赖于别的，然后整体备份到 s3 ，也就是 sqlite 的方案。

你把数据集中到 pgsql ，你 pgsql 就不需要备份了吗？


@julyclyde 这话说的太理想了，你总会遇到有状态的服务的，而实际上状态正是网络服务里最难管理的东西