数据库比较
PostgreSQL：数据库专业人员毕业生
PostgreSQL 是工程师向其他工程师推荐的开源关系数据库：面向标准的 SQL、值得阅读文档的事务模型以及将数据库转变为 GIS、搜索、向量存储和编排平台的扩展生态系统。代价是诚实的维护要求，特别是真空规则和配置，MySQL 式默认设置的疫苗并没有让人们做好准备。
要点
- MVCC 是该架构的签名：读取器不会阻止任何人，更新是行的多版本形式，过期版本会一直存在，直到 VACUUM 回收它们；真空调优（自动真空成本、每个繁忙表的阈值）是高变动模式工作的一部分，而不是可选的卫生。
- 扩展面是其特征：PostGIS 使其成为一个严肃的 GIS，pg_stat_statements 将性能调整从民间传说变成事实，压缩 WAL 归档工具（pgBackRest/barman）支持时间点恢复，而 pgvector 将其转变为语义搜索存储的结构。
- JSON 是一流的：jsonb 存储在关系模式内提供索引文档查询：这对消除了大多数内部工具的“需要文档存储”参数。
- 复制和 HA 已经成熟，但需要手动操作：流式复制加上复制槽是基线；逻辑复制支持有针对性的升级和选择性同步；上游存在 Patroni/postgres-operator 人员配置，但生产 HA 仍然需要脚本化和经过测试的程序。
- 备份规则：WAL 归档加上定期基础备份和经过验证的恢复演练； pg_dump 本身并不是对正常运行时间敏感的工作负载的备份计划，尽管它仍然是小型堆栈的合法工具。
- 我们比较中的默认姿势：当模式是关系型的、数据是产品的核心、并且团队阅读手册时，PostgreSQL 的默认设置将比现有的任何 MySQL 风格的默认设置更强大；当任务是在一台机器上安装 100 个小型 CMS 数据库时，MySQL/MariaDB 的面板生态系统由于操作界面而不是引擎的分数而保持默认状态。
一线手记
成长为 PostgreSQL 的团队需要一个 autovacuum 事件来学习 MVCC：批量更新后分析框变得更慢，而死元组指标解释了每个缓冲区调整直觉无法解释的事情。真空调谐现在已成为他们操作手册的一部分。
常见问题
PostgreSQL 与 MySQL：Postgres 何时明显正确？
复杂的关系工作、跨数十个表的连接、数据库内的分析以及 GIS/矢量搜索等字段：PostgreSQL。由于面板工具的原因，细粒度共享 CMS 托管默认为 MariaDB-as-shipping。
autovacuum 应该有多积极？
足够积极，可以防止死元组流失破坏查询计划。对于大量更新模式，存在 autovacuum 成本窗口、阈值和每表调整；诚实的做法是监视（pg_stat_user_tables 活/死元组计数），然后根据工作负载进行调整。
pgvector 适合生产语义搜索吗？
在适度的数据量下，它是一种实用的、基于扩展的向量存储，其索引选项越来越显示出良好的性能。专用矢量数据库可以更好地解决某些工作负载（大规模、分布式写入），但对于向现有关系应用程序添加语义搜索来说，它非常出色。
为什么我的数据库在批量更新后变得更慢？
典型的 MVCC 症状：死版本使表和索引膨胀，直到 autovacuum 赶上；长事务阻碍了清理工作。监视死元组和锁定持续时间，而不是猜测缓冲区。
Kinetikatech 如何在数据库比较方面为您提供帮助
您不必自己成为数据库比较专家：用于托管工作负载的数据库引擎选择，在正确性保证、操作权重和实际成本方面进行比较：嵌入式引擎与服务器、MySQL 与 PostgreSQL、SQL 与文档存储，以及不断出现的遗留案例研究。服务器管理和网站速度优化正是为此而设：配置、加固、监控，并有工程师日夜值守。