PostgreSQL 能替代所有技术栈？

我的一般经验法则是：“先用 PostgreSQL，直到你发现为什么不能用它为止。”

你引入的任何东西都是另一个需要运营和维护的组件，而在起步阶段，PostgreSQL 很可能就能搞定。等负载上来了，看看哪里出了问题，那时你再判断是否值得引入另一个工具。

这类文章（PostgreSQL！你只需要它！）已经让人很厌烦了。PostgreSQL 甚至远不能替代 Elastic，而这只是第一点。

往下看列表，很容易得出结论：是的，PostgreSQL 可以在极其基础的使用场景中替代那些工具，但一旦你真的需要这些其他工具的任何强大功能，上述结论就统统不适用了。

我用 SQLite 处理所有事情，对此我非常满意。我知道并发写入的问题，但在我的规模下，这根本无所谓。

这类文章之所以需要被写出来，是因为我们之前已经走向另一个极端太久了。问题在于，人们在阶段不需要的时候过早地使用了太多工具。所以，是的，在大多数情况下，你最好只用 PostgreSQL。我自己也是这种行为的始作俑者，所以我也不敢说自己更懂行。这仅仅是因为设置太多工具会让人感觉更酷，或者让人觉得“我们必须用 Elasticsearch，因为没人会在数据库里做搜索”。

我对这一点很感兴趣：

> 经过一些性能测试后，我们发现在我们的使用场景中，PostgreSQL 甚至比直接从文件系统读取还要快。PostgreSQL 非常高效地利用文件系统存储数据——它增加了大量的缓存和高效的读写策略，其性能可以超越在文件系统中直接读写原始数据。

这违背了常规认知。我一直听说（并遵循最佳实践）要避免将二进制数据存储在 BYTEA 列中，这些数据本应放在文件系统或像 S3 这样的对象存储上。

我想深入了解这一点，因为在许多情况下，直接将其存储在数据库中确实会非常方便。

在 Comper，我们有一个非常热的键值存储，用于标注 git 数据。我们维护了一个并行的 git-blame 数据结构，以便进行增量的“git blame -w -M -C -C”操作。这通常是一个代价很高的操作，但如果你让它变成增量的，那么在需要分析新提交时，成本就会变得非常低。然而，对于大型仓库来说，构建 git blame 树仍然相当耗费资源。

我们目前使用 rocksdb，存储在同一节点上，在分析过程中每秒访问 rocksdb 数千次。大约 20% 是写入，80% 是读取。问题是我们需要开始水平扩展，以支持突发式的工作节点和零停机部署。所以我们正在考虑将负载卸载到外部的 kv 服务，而不是使用本地的 rocksdb。

TiKV 似乎是一个不错的替代品，虽然慢了大约 3-4 倍，但可扩展性非常好。读了这篇文章后，我觉得一个带有未记录表（unlogged tables）的独立 postgres 集群可能是个好主意。如果有任何人有相关经验可以分享，请告诉我！

我倾向于同意文章中的许多观点，但有些话题需要仔细审视。

* 作为消息队列：

仅当你的需求非常基础时才适用，例如你需要集群通信并在其上运行自己的协调协议。

* 高吞吐量时间序列：

TimeScale 可以工作，但在同一 DB 服务器上与其他工作负载组合时（从大规模运营的角度来看）表现不佳。

* 向量数据库：

与 TimeScale 类似的问题... 例如 PgVector 生活在自己的独立“世界”中，查询优化器将其视为一个非常不透明的东西。别想着给现有的高吞吐量数据库添加向量存储，该数据库还必须服务于其他复杂查询... PGVector 要么会搞垮你的缓存，要么会占满你的 CPU，导致原本运行良好的工作负载停滞。在我看来，这本身不是 pgvector 的问题（向这些开发者致敬），而是 postgresql 扩展 API 不太擅长向整个系统暴露自定义成本和权衡。

* 原始数据：

适用于小文件... 为什么有人想在其中存储大量数据是个谜，它真正发光的地方是访问大量小文件，此时内部缓存等机制相比原始文件系统访问帮助很大（这也稍微取决于文件系统及其调优）。

* 微服务：

如果你的服务仅仅是暴露来自某个数据库模型的 json 数据，那么在我看来它根本不应该存在。创建一个视图就完事了。