PgDog 已获得融资，正来到你身边的数据库

PgDog 的作用

• 充当 PostgreSQL 代理，提供：
  • 连接池
  • 读负载均衡
  • 跨多个 Postgres 实例的分片 / 查询路由
• 位于未修改的 Postgres 服务器前端；不是扩展，也不是自定义存储引擎。
• 旨在带来类似 Aurora/Vitess 的体验，但完全在代理层实现。

性能与架构

• 使用 Rust 编写，以获得安全性和速度，但主要收益来自：
  • 将连接成本从 Postgres 进程中卸载出去
  • 将读取分散到各个副本
  • 通过分片分散写入，以避免单节点 WAL / vacuum 瓶颈。
• 文中提到的生产环境数据包括约 2M QPS；内存使用主要受缓存的查询 AST 驱动。
• 对于可能让代理 OOM 的大结果集，有两种处理方式：崩溃并增加内存，或分页到磁盘；两者都被承认为权衡。

分片模型与限制

• 当前模型：shard_number = hash(key) % num_shards；批评者指出，与虚拟分片 / 基于范围的方案相比，这会使重新分片成本很高。
• 支持通过 2PC 进行跨分片事务，但：
  • 成本高，在故障下也更脆弱。
  • 仅建议用于低吞吐量的“元数据”表。
• 读取可以是最终一致的；跨分片的强 ACID 并不会“比单机更快”。
• 存在一些自动分片路由，但文档不够完善；很多时候你必须显式指定目标分片。

部署与配置

• 配置由 TOML 文件驱动；一些用户表示，在高度动态、多租户的 Kubernetes 环境中会遇到摩擦。
• 变通办法包括自定义 controller/operator，重新生成配置并触发协调式重载。
• 企业版（付费）将加入：
  • 用于多节点管理 / “开箱即用”部署的控制平面。
  • 阻止坏查询的 QoS 功能。
  • 带 SLA 的支持。
• 核心分片与扩容功能承诺仍将保持开源；围绕它的基础设施 / 用户体验则是商业化的。

高可用与升级

• PgDog 提供带健康检查和故障转移路由的负载均衡，但：
  • 它不会提升副本为主库；预期外部 HA 工具（Patroni、RDS 等）来完成。
• 并不能直接解决重大的 Postgres 版本升级；讨论指出，逻辑复制和基于 pooler 的切换仍是当前常态。

与其他系统的比较

• vs PgBouncer/Pgpool-II：功能更多（分片、更智能的池化、处理 LISTEN/NOTIFY、按连接设置），但复杂度也更高。
• vs Citus：Citus 拥有更丰富的 OLAP / 查询引擎；PgDog 专注于 OLTP、基于代理的并发，以及独立的协调器扩展。
• vs Mongo/Dynamo/Cockroach/Yugabyte：
  • 讨论串指出，Postgres 从根本上仍然是“每行单写者”。
  • 有些人认为 KV/NoSQL 系统能更自然地扩展写入；也有人偏爱 Postgres + 分片，因为它拥有更好的生态。

反馈与担忧

• 许多用户表示，在生产中体验积极，并且相比 PgBouncer 迁移更顺畅。
• 也有人质疑：
  • 核心团队规模较小带来的 QA 和运维风险。
  • 供应链 / 安全立场（维护者的审查实践缓解了部分担忧）。
  • “你不会再用别的东西了”之类的营销说法，被一些人认为过于夸张。
• 整体语气：大家对更严肃的 Postgres 扩展方案感到兴奋，但同时也现实地认识到，分片的复杂性以及高可用 / 升级仍然需要谨慎设计。