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

[MrLonely]

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

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

[Maboroshii]

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

[airyland]

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

[Garasu]

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

[julyclyde]

容器就不该有状态

[yinmin]

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

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

[abcbuzhiming]

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


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

[MrLonely]

@Garasu 其他地方的 SQLite 每天同步上去的意思是，每天把 SQLite 里的数据备份到云服务数据库里吗？

[MrLonely]

@abcbuzhiming 这个当然是需要备份的。只是说，也许把备份还原这个操作统一化以后相对来说会更稳健一些？从操作上来说看起来也更方便一些。不过我也立刻想到了一个潜在的问题。就是不同应用的数据需要恢复到历史状态时，统一备份的能否实现一个高颗粒度的还原呢？比如 ABC 三个应用的数据都放在一起。那恢复备份的时候只恢复 A 应用需要用到的表。BC 的数据不动。

[billzhuang]

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


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

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

[IvanLi127]

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

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

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

[nt0p]

容器就不该有状态

[69partner]

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

[codehz]

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

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

[LancerComet]

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

[laminux29]

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

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

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

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

[xuanbg]

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

[yinmin]

@xuanbg #16 sqlite 是基于文件锁来处理并发操作的，高并发的情况下，文件锁的读写冲突会很严重，因此 sqlite 只适合单用户或者低并发的场景使用。

当然了，如果 sqlite 的数据库是一个只读不写（例如：geoip 库）并且不超过 20MB ，的确如你所说，在高并发场景性能也会很好。

[julyclyde]

@abcbuzhiming 问题是“每个容器各自的 sqlite”有啥用？各容器数据都不一样了还咋提供一致服务呢？

[wxf666]

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

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

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