目前，论坛帖子、用户账户等的主要存储方式是 PostgreSQL 数据库。
我能否建议将论坛内容的主要存储格式改为简单的文本文件？
由于难以修复的数据库问题（作为普通用户，我很难自行解决），我认为因 SQL 数据库看似/实际上不透明的二进制格式而导致所有论坛数据丢失的风险很高。看起来，没有人能够修复严重损坏的数据库（而上述问题可能并不明显），或者修复成本对普通用户来说过高。
我确信，使用 PostgreSQL 等数据库有非常充分的理由，例如性能。但我提议，采用一种透明且人类可读的文本格式作为备份，以便在数据库备份和恢复功能损坏或失效时，作为最后的应急手段。
您很可能无需被说服 Git 有多强大，因为您已经在使用了。论坛内容可以存储为子文件夹和大量文本文件。这样，整个文件夹就可以纳入 Git 版本控制。如果引入了任何错误，追踪是哪个提交导致的问题会容易得多。
由于数据库（不可靠、复杂）可能仍然需要，这些文本文件（简单、可靠）可以作为“从源代码”重建数据库的模板。如果实时将新帖子存储到文本文件中速度太慢，您可以将文本文件备份选项设置为按需执行，或在系统空闲时执行（延迟写入/写入缓存）。
公开数据（公开论坛帖子）将存放在与私有用户数据（如哈希密码）不同的文件夹中。额外的优势是，公开部分（帖子）甚至可以发布到 Git 远程仓库，供那些认为有用的人进行归档。用户数据将保留在仅限本地的 Git 仓库中（或自定义的远程、私有、加密的 Git 仓库）。
Stephen
(Stephen)
2
这里存在规模经济效应。这样的工程变更意义重大。如果上述情况成立，其性能影响将导致你的额外运行成本很可能超过聘请顾问修复数据库的费用。
数据库之所以存在，是因为它们比替代方案——纯文本文件——高效得多。
软件本身是免费的，但仅此而已。你最好短期内在#marketplace 话题上进行一些投资，而不是推广一种会让 Discourse 运行成本过高的方法。
5 个赞
RGJ
(Richard - Communiteq)
3
TL;DR 不，你不需要那样。真的不需要。
我理解你对更简洁方案的需求。
但是。
在 20 世纪 90 年代，我使用过基于文本文件的互联网论坛（Telnet BBS）软件。我们一直渴望获得更强大、更完善的功能。我们需要为数据添加“列”。于是我们添加了一个制表符（TAB），然后加入额外的列。我们需要对所有现有文件进行同样的操作。后来，我们想要删除（另一部分）数据。我们编写了一个 awk 脚本来遍历所有文件并移除这部分数据。在此期间，我们必须将软件置于维护模式，因为软件会检测到字段数量不同的文本文件。那简直是地狱。我们如此渴望一个更好的系统，但受限于只能使用文件系统且资源极其有限，我们只能勉强运行软件。我们真正需要的是……一个数据库。
然而，性能并非唯一问题。文本文件也可能损坏，例如当两个进程同时写入时。
此外，还有所谓的“参照完整性”，它确保内部引用有效（例如，此帖子属于主题 #152787 和用户 #406）。
还有事务、快照、复制和负载均衡等功能。
诚然，数据库也可能崩溃。我的车昨天就出故障了，因为过于复杂的 ABS 控制软件对微小且看似无关的问题非常敏感。我自己无法修复它，必须花一大笔钱才能修好。但它带来的优势远胜过步行。它不可靠吗？不。刹车依然有效，而且仪表盘上的指示灯立即向我发出了警告。
数据库正是为了可靠性而构建的，因为文本文件做不到这一点。
16 个赞
pfaffman
(Jay Pfaffman)
4
理查德的比喻很贴切。用文本来追踪 Discourse 的数据是不可能的。
即使增加对其他数据库的支持，每年的成本也高达约 20 万美元。
你或许可以先确定预算，然后在 Marketplace 频道中找人修复你的数据库。这项工作很难报价，因为目前还不清楚你只是有一个损坏的索引需要修复几条记录，还是有多个索引需要修复几十条记录。
7 个赞
PG10 中的损坏索引是我们密切关注的问题，在你们链接的帖子中，我们将尽我们所能提供帮助，以惠及所有人。我希望 PG12 对这一问题更具抵抗力，升级将从长期上彻底解决该问题。
但我确实认为，“退回到纯文本文件”并不是解决此问题的合适方案。
10 个赞
dfabulich
(Dan Fabulich)
6
Postgres 提供了一种纯文本备份解决方案，即 pg_dump。
pg_dump 是用于备份 PostgreSQL 数据库的实用工具。
脚本转储是纯文本文件，其中包含重建数据库至保存时状态所需的 SQL 命令。
5 个赞
Laurent
(Laurent)
8
严格来说，一堆文本文件也算是一种数据库，只是不适合用于任何关键或高性能的场景。
2 个赞
