在分布式系统设计中，"Kafka 很快，我选择 Postgres" 这样的表述看似简单，实则蕴含着深刻的架构哲学。这不仅仅是一个性能对比问题，而是关于系统设计理念、数据处理模式和团队工程能力的综合考量。
设计目标的本质差异
Kafka 和 PostgreSQL 从诞生之初就服务于完全不同的设计目标。Kafka 是一个分布式流处理平台，专门设计用于处理高吞吐量的实时数据流，采用了日志结构的存储模型和分区机制来实现水平扩展。这种架构使得 Kafka 能够轻松处理每秒百万级的消息，同时保证消息的持久化和顺序性。
相比之下，PostgreSQL 作为关系型数据库，其核心是 ACID 事务保证和复杂查询优化。它采用页式存储结构和 B + 树索引，支持复杂的 JOIN 操作和事务回滚。PostgreSQL 的设计哲学是 "可靠性和一致性优先"，这使其在需要强一致性的业务场景中表现出色。
这种根本性的差异意味着我们不能简单地用 "谁更快" 来比较两者，而应该从使用场景的本质需求出发。
实际案例：Dataddo 的架构演进
一个很有说服力的案例来自数据集成公司 Dataddo。该公司最初使用 RabbitMQ 处理长时间运行的任务，但遇到了心跳超时和连接重连的问题。在托管的 AWS 环境中，他们无法按照期望的方式配置 RabbitMQ，也没有足够的工程能力来管理这个开源消息代理。
经过与 PostgreSQL 贡献者的合作，他们发现 PostgreSQL 可以很好地处理长时间运行的任务，并提供更深入的洞察力。由此诞生了 PGQ（Postgres Queue），一个构建在 PostgreSQL 之上的消息队列机制。
Dataddo 的 CTO Tomáš Sedláček 表示："使用 RabbitMQ、Kafka 或其他工具只是增加了开发人员需要学习和维护的另一种技术。从招聘的角度来看，找到只懂得 Postgres 的工程师更容易。"
这个案例揭示了一个重要的工程原则：技术选型不仅要看功能匹配度，还要考虑团队的技能栈和运维能力。
性能边界的实际考量
从性能数据来看，Kafka 在高吞吐量消息处理方面确实具有明显优势。Kafka 的分区机制允许它线性扩展处理能力，单个集群可以轻松处理每秒百万级的消息。其磁盘顺序写的存储模型也确保了高吞吐量的同时保持相对较低的延迟。
然而，PostgreSQL 在数据持久化和查询分析方面展现出了不同的优势。PGQ 虽然比 Kafka 稍慢，但差距并不如想象中巨大。更重要的是，PostgreSQL 提供了更好的可观测性 —— 所有操作都写入磁盘而非内存模式，这消除了数据丢失的风险，并允许跟踪队列深度、处理速率和错误率等关键指标。
在 Dataddo 的实际使用中，PGQ 每天处理超过 20 万个长时间运行的作业，以及发送邮件、保存日志等短作业，表现稳定可靠。
混合架构的实践智慧
现代系统设计越来越倾向于采用混合架构，而不是单一技术栈。Kafka 和 PostgreSQL 的结合使用，能够发挥各自的优势，避开各自的劣势。
典型的模式是使用 Kafka 作为实时数据流的缓冲和处理层，利用其高吞吐量和分区特性来吸收流量峰值，然后将重要的业务数据持久化到 PostgreSQL 中，利用其强一致性和复杂查询能力来支持业务逻辑。
Debezium 等工具的出现，使得从 PostgreSQL 实时捕获变更并同步到 Kafka 变得更加简单。这种 CDC（Change Data Capture）模式允许系统在保持数据库一致性的同时，实现实时数据分发和处理。
选型决策框架
在实际的技术选型中，我建议采用以下决策框架：
选择 Kafka 的场景：
- 需要处理极高吞吐量（百万级 TPS）的实时数据流
- 要求多个下游系统独立消费相同数据
- 需要长时间的数据保留和回放能力
- 流处理和实时分析是核心需求
选择 PostgreSQL 的场景：
- 需要强一致性和 ACID 事务保证
- 复杂的查询和分析需求
- 团队熟悉 SQL 和数据库操作
- 对数据可观测性和调试能力要求较高
采用混合架构的场景：
- 既需要高吞吐量的数据流处理，又需要强一致性的业务存储
- 不同系统对数据的访问模式差异很大
- 需要在性能和可靠性之间找到平衡点
技术债务与运维考量
选择 PostgreSQL 作为消息队列的一个隐性优势是减少了技术栈的复杂度。对于许多中小型团队而言，维护一套额外的消息队列系统可能带来显著的技术债务和运维负担。PostgreSQL 的成熟度、社区支持和完善的监控工具生态，使得基于 PG 的队列系统更容易被团队接受和维护。
另一方面，Kafka 的生态系统和专业的运维工具（如 Kafka Connect、Kafka Streams）在处理大规模流数据时具有不可替代的优势。对于需要处理 PB 级数据流的组织而言，投资专业的 Kafka 基础设施是必要的。
结论：架构决策的工程本质
回到开头的观点，"Kafka 很快，我选择 Postgres" 这种表述虽然简洁，但背后反映的是对系统需求本质的深刻理解。技术选型从来不是简单的性能对比，而是对业务需求、团队能力、运维成本和发展规划的综合权衡。
对于大多数应用场景而言，最佳实践不是选择单一技术，而是构建一个混合架构，让不同的技术各司其职。Kafka 处理高吞吐量的实时数据流，PostgreSQL 提供可靠的业务数据存储，辅以适当的同步机制和监控体系。
最终，好的架构决策应该让系统既能满足当前的业务需求，又为未来的发展留下足够的灵活性和扩展空间。这才是技术选型的真正价值所在。
参考资料：
- "PGQ: Queuing for Long-Running Jobs in Go Written Atop Postgres"，The New Stack
- PostgreSQL 官方文档与性能基准测试报告