PostgreSQL 无所不包

原文 ↗ Hacker News 讨论 ↗

PostgreSQL 的支持者认为，它可以替代从消息队列、搜索引擎到时序数据库和向量数据库等广泛基础设施，让小团队通过只运行“Postgres”更快交付。反对者则指出，尽管在中等规模下这套方案很有效，但当数据量、性能需求和运维复杂度增长时，ClickHouse、Kafka、Elasticsearch 或专用队列等 специализирован 工具就会变得必要。一个反复出现的主题是：先把 PostgreSQL（甚至 SQLite）作为简单默认方案，只有在真正遇到明确的扩展性或功能边界时，才引入额外系统。

MySQL 与 PostgreSQL 的历史背景

  • 2000 年代初：MySQL 是 LAMP/PHP 托管环境中的默认选择，之所以被认为更快，部分原因是 MyISAM 跳过了事务和持久性。
  • 随着时间推移，Postgres 增加了功能并提升了稳定性，而 MySQL 的设计问题、糟糕的默认配置，以及后来 Oracle 的收购，让一些用户转向别处。
  • MySQL 早期有运维上的优势（易安装、master–master 复制），但从 2000 年代中期起，Postgres 逐渐成为“正经 RDBMS”的默认选择。

SQLite 与 PostgreSQL

  • 几位评论者在小规模场景下愉快地把 SQLite “用于一切”；NVMe + Litestream 之类的复制工具被认为足以满足许多应用。
  • 另一些人则提醒 SQLite 的类型系统较弱、缺少原生 DATE/TIME/TIMESTAMP，并且与 Postgres 的行为存在差异，认为开发环境应与生产环境一致。
  • 有人说 SQLite 非常适合单服务器或嵌入式场景；而当你需要多个写入者、严格类型、访问控制和复制时，Postgres 更合适。

“Postgres 无所不包”——支持者观点

  • 许多人把 Postgres 作为默认选择：OLTP 数据库、JSON 存储、全文搜索、向量存储、队列、消息总线、日志，甚至基础分析。
  • 强调的扩展和功能包括：JSONB、trigram 索引、PostGIS、property graphs（PG 19）、pgvector/pgvectorscale、Timescale continuous aggregates、GPU ML（PostgresML）、LISTEN/NOTIFY。
  • 论点是：大多数应用规模都属于小到中等；在规模迫使改变之前，一个大家都熟悉、托管良好的系统，比 Kafka、Elasticsearch、Redis 等复杂技术栈更好。

“Postgres 无所不包”——怀疑者观点

  • 批评者认为文章夸大了 Postgres 相对于专用工具的能力：
    • 搜索：无法达到 Elasticsearch 的强大能力；新的基于 Postgres 的搜索项目正在试图缩小差距。
    • OLAP/分析：ClickHouse、BigQuery、以及对象存储上的列式引擎在大规模临时分析方面要强得多。
    • 时间序列和向量：Timescale/pgvector 可能与其他工作负载冲突，并在高负载下拖累缓存/CPU。
    • Blob：存储大型 BYTEA 会损害缓冲区、备份和 WAL；对象存储通常更可取。
  • 运维方面的担忧：vacuum 调优、每连接一个进程的模型、需要连接池、HA/分片（Patroni、自定义分片）都不算简单。

设计哲学与规模

  • 广泛认同的一条经验法则是：“先用 Postgres（或者你熟悉的东西），直到你发现它不够用；然后再添加专用工具。”
  • 反方观点：把一切都围绕单个 Postgres 实例来设计，可能会在未来造成中心瓶颈，并让迁移变得复杂；应当提前考虑未来的规模和可用性需求。
  • 总体共识是：Postgres 是一个极好的、很多情况下甚至是最佳的默认选择，但它并非字面意义上的“无所不包”，尤其是在超大规模或高度专业化的工作负载下。