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

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

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

如果是在同一个机器，所有 sqlite 文件都挂载在同一个目录下，就一起备份好了

集中到一个 pg 不一定比现在好，因为一旦数据挂了，所有服务都受影响。
只要做好备份和流程的自动化感觉问题不大。

小孩子才做选择.jpg
如果中心化 pg, 那你的 pg 可靠性想高，那就不能只在一个地方了吧？定期备份是不是也需要了， 不在同一局域网延迟是不是还得考虑？
不如国内云服务数据库，其他地方的 sqlite 每天同步上去，恢复时候 用户数据都全量，量大的历史数据做个裁剪？
我目前是准备这么搞的，家里服务器跑计算(毕竟电费和性能比起来，家里还是划算)，国内云服务用个数据库(最起码比家里的二手硬件稳)，再来一台国外的跑被强的网。

容器就不该有状态

选择 sqlite 和 pg ，应该是根据并发量。如果并发量低，优选 sqlite ，如果高并发优选 pg 。

至于备份问题，把数据通过 volume 到 docker 主机目录，备份迁移 volume 目录即可。

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


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

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


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

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

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

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

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

容器就不该有状态