HotPursuit

PgDog is funded and coming to a database near you - infra 架构解读

HackerNews入库于 2026/6/11|
PostgreSQL横向扩展连接池分片路由代理架构两阶段提交

作者：dodo

原文：https://pgdog.dev 及 https://pgdog.dev/blog/our-funding-announcement 发布时间：Jun 10th, 2026 解读视角：大模型基础建设架构设计 沉淀时间：2026-06-11

一句话核心

PgDog 是一个无侵入式 Postgres 代理层，通过连接池、读写分离负载均衡与分片协调器三合一设计，实现 Postgres 横向扩展；其 $5.5M 融资公告揭示了一种对大模型基建高度可参考的"代理层承载分布式语义"架构范式——在不改造上层应用的前提下，用代理扩展数据库能力边界。

文章背景与问题域

核心问题：Postgres 本身不支持横向扩展，当表规模超过 100 TB、QPS 超过 100 万时，传统解法（Mongo、DynamoDB、Citus）要么放弃 ACID，要么侵入应用层，要么绑定云厂商。

重要性：Postgres 是当前大模型系统（向量存储、元数据管理、工具调用状态）中最主流的持久化方案。Postgres 的扩展上限直接约束了大模型推理系统在高并发场景下的稳定性。

PgDog 的解题逻辑：不改 Postgres 本身，不改应用代码，在两者之间插入一个代理层，由代理承担：连接复用、流量路由、分片路由、跨分片协调。这是典型的"扼流点（Choke Point）"设计哲学。

核心架构 / 方案解析

总体分层

Application Layer
  asyncpg / pgx / libpq / ruby-pg（任意标准 Postgres 驱动）
          ↓ （Postgres wire protocol，无感知）
    ┌─────────────────────────────────────┐
    │             PgDog Proxy              │
    │  ┌──────────┐  ┌──────────────────┐ │
    │  │ Pooler   │  │  Load Balancer   │ │
    │  │(连接复用) │  │ (读写分离 + 健康) │ │
    │  └──────────┘  └──────────────────┘ │
    │  ┌──────────────────────────────┐   │
    │  │ DSQL (分布式 SQL 协调器)      │   │
    │  │ - Shard key 路由              │   │
    │  │ - 跨分片并行执行               │   │
    │  │ - 2PC 事务协调                │   │
    │  └──────────────────────────────┘   │
    └─────────────────────────────────────┘
          ↓ shard 0   ↓ shard 1   ↓ shard 2
      [primary+2r] [primary+2r] [primary+2r]

三个核心模块详解

1. Connection Pooler（连接复用）

采用真实事务模式（Real Transaction Mode），突破了传统连接池"连接锁定"的限制：

  • SET 命令、advisory locks、LISTEN/NOTIFY 均支持，无需 connection pinning
  • 多线程 + 异步架构，单线程 50,000+ TPS
  • Prepared statements 零开销兼容

配置极简：

# pgdog.toml
[general]
default_pool_size = 100

[[databases]]
name = "prod"
host = "10.0.0.1"

2. Load Balancer（负载均衡 + 健康检查）

类比应用层 ALB（Application Load Balancer）在数据库层的实现：

  • Health checks：自动屏蔽落后复制节点
  • Failover detection：主库故障时自动切换写流量，无需配置变更
  • Read/write split：基于内置 Postgres SQL parser 实现，对比正则/关键词匹配方案，兼容性更强

3. DSQL 分布式 SQL 协调器（最核心的基建能力）

这是 PgDog 架构中技术密度最高的部分：

  • Shard key 提取：直接从查询 AST 提取分片键，路由到目标分片
  • Scatter/Gather：无分片键的查询在所有分片并行执行，结果在代理层合并（GROUP BY、COUNT、AVG、ORDER BY、MIN/MAX、COPY）
  • 跨分片事务：使用 Postgres 原生 Prepared Transactions + Two-Phase Commit（2PC）实现原子性写入，任何错误触发自动回滚
  • 复制表（Replicated Tables）：不需分片的维度表在所有分片存储相同副本，实现 shard-local joins，避免跨分片 join 的网络开销
  • 大整数主键生成：代理层内置单调递增大整数主键生成，无需应用迁移到 UUID
  • 分片键变更：通过 UPDATE 语句跨分片迁移行，代理层透明处理
  • DDL 广播：Schema 变更自动同步到所有分片，兼容 Alembic、ActiveRecord 等 migration 工具

关键工程决策与权衡

决策点选择放弃的方案理由
部署形态单一可执行文件，可自托管托管 SaaS / Serverless避免云厂商绑定，适应企业合规要求；on-prem、colocation 场景可用
分布式事务协议Postgres 原生 2PC（Prepared Transactions）应用层 saga / 最终一致性保留 ACID 语义，无需改造上层代码，利用 Postgres 已有机制
SQL 解析方式内置 Postgres SQL Parser正则匹配 / 关键词检测读写分离准确性更高，不被"SELECT ... FOR UPDATE"等边缘 case 误判
主键策略代理层单调大整数主键强制应用迁移 UUID降低迁移成本，保持与旧代码兼容
分片扩展方式配置驱动（pgdog.toml）应用层显式路由无侵入，切换成本极低（只改 DATABASE_URL）
并发实现Rust 多线程异步Go / Python 协程2026年的 Blog 提到"Replacing Protobuf with Rust to go 5x faster"，性能优先

大模型基建视角专项解读

1. 系统架构与分层设计

PgDog 是"扼流点（Choke Point）"设计的教科书案例。它将所有分布式副作用（路由、事务协调、连接复用、健康检查）集中到代理层，而非散落在应用侧。

对大模型基建的直接映射：大模型推理网关（LLM Gateway）面临完全类似的问题——多个 LLM 后端、多种路由规则（按模型、按用户、按 token 预算）、限速、故障转移。PgDog 的架构表明，这类问题的最优解是"在应用层与基础设施层之间插入一个协议兼容的代理，由代理承担所有分布式语义"。

2. 并发与调度模型

Scatter/Gather 模式值得深入研究：无分片键的查询被广播到所有分片并行执行，结果在代理层合并聚合。这正是大模型 inference 中"fan-out 并行推理 + 结果聚合"的数据库版本。

关键设计：聚合算子（COUNT、AVG、ORDER BY、MIN/MAX）必须在代理层重新实现，因为每个分片只有局部结果。这与大模型 ensemble 推理中的结果合并逻辑高度同构。

3. 容错与可靠性

Failover Detection 的设计值得关注：主库故障时，PgDog 自动将写流量切换到新主库，无需配置变更。这是"外部观察者检测拓扑变化并重路由"的标准模式。

对比大模型基建：当某个 inference 节点故障，流量应自动重路由到健康节点，且不需要业务侧感知——PgDog 的实现方式是代理层持续发送健康探测并维护路由表，这与 LLM serving 中的服务发现机制完全同构。

复制延迟检测：对落后复制节点的屏蔽（health check 阻断），避免应用读取到过时数据。类比大模型系统中的 KV Cache 一致性问题——落后节点的 KV Cache 若被命中，可能返回基于旧上下文的推理结果。

4. 上下文与状态管理

**复制表（Replicated Tables）**是跨分片状态管理的精妙解法：将访问频率高、体积小的维度表（如 cities、categories）在所有分片存储相同副本，使高频 join 操作在本地完成，不涉及跨分片网络 I/O。

对大模型基建的启示：System Prompt、工具定义（Tool Schemas）、用户 Persona 等"热读少写"的小型上下文，可采用类似的"全量复制"策略而非分片，使每个推理节点都能本地完成上下文构建。

5. 可扩展性设计

协议兼容性是核心护城河：PgDog 兼容所有标准 Postgres 驱动（asyncpg、pgx、libpq、ruby-pg），应用侧只需修改 DATABASE_URL。这种"协议层面的向后兼容"使其渗透率极高。

配置驱动（pgdog.toml）而非代码驱动，使运维人员无需修改应用代码即可完成分片配置，降低了技术栅栏。

工程模式提炼

模式名文章中的实现大模型基建启示
扼流点代理（Choke Point Proxy）PgDog 作为 Postgres 前置代理，集中处理路由、池化、分布式事务LLM Gateway 统一承担限速、路由、Token 预算控制，避免这些逻辑散落到各业务服务
Scatter/Gather 并行执行无分片键查询广播到全分片并行，结果在代理聚合Ensemble 推理：多模型并行推理后在网关层聚合结果；RAG 多分片并行检索后在上层合并
维度数据全量复制（Replicated Tables）小体积热读维度表全量复制到所有分片，实现 shard-local joinSystem Prompt、Tool Schema 等热读小上下文全量预载到所有 inference 节点，避免跨节点获取
原生协议 2PC 事务利用 Postgres 内置 Prepared Transactions + 2PC 保证跨分片原子性大模型工具链中多工具调用结果的原子提交，避免部分成功的中间态
外部观察者故障重路由代理层持续健康探测，主库故障自动切换写流量无需手动介入LLM Serving 中代理层主动探测 inference 节点健康状态，故障时自动从路由表摘除
协议兼容零侵入部署完全兼容 Postgres wire protocol，只改 DATABASE_URL 即可接入LLM 推理网关兼容 OpenAI API 协议，业务侧无感知切换 backend
代理层主键生成代理层集中生成单调大整数主键，避免应用迁移到 UUIDInference 请求的唯一 ID、Trace ID 统一在网关层生成，保证全局唯一性和可追溯性

反常识点梳理

反常识点常规认知文章实际做法背后原因
分布式事务用 2PC 而非最终一致性分布式系统中 2PC 被认为性能差、可用性低，现代系统倾向最终一致性PgDog 使用 Postgres 原生 Prepared Transactions + 2PC 保证跨分片 ACIDPostgres 原生 2PC 已有成熟实现，代理层协调成本可控；用户不愿放弃 ACID 语义
主键生成放在代理层而非数据库序列主键通常由数据库 sequence 生成，由单个主库保证唯一性代理层生成单调大整数主键，绕过了分布式序列问题分片后各分片 sequence 可能冲突；代理层集中生成保证全局单调性，同时避免应用迁移 UUID 的改造成本
Schema 变更（DDL）不需要停机广播分布式数据库 DDL 通常是高风险操作，需要停机或复杂的协调协议PgDog 自动将 DDL 广播到所有分片，兼容 Alembic/ActiveRecord 等工具利用 Postgres 的 transactional DDL，代理层串行广播，开发体验与单机无差异

延伸思考

  1. LLM Gateway 能否借鉴 PgDog 的 Scatter/Gather 模式实现推理加速？ 当一个 prompt 需要同时检索多个知识库分片，或者做 multi-model ensemble 时，网关层的 fan-out + 聚合逻辑与 PgDog DSQL 中的并行查询 + 结果合并几乎完全同构。值得深入研究的问题是：LLM 场景的"聚合算子"语义是否可以标准化（如：取最大 confidence、vote、concat）？

  2. Postgres 作为大模型系统持久化层的扩展瓶颈应在哪一层解决？ PgDog 选择在代理层解决，而非修改 Postgres 内核或使用 Citus 扩展。这一选择给大模型基建的启示是：当底层基础设施（数据库、对象存储、消息队列）无法满足规模需求时，优先考虑在协议兼容的代理层扩展，而非侵入底层系统——代价是代理层需要完整理解并重实现上层协议语义（SQL 解析、事务语义等），技术门槛极高。

  3. 连接池中的"Session State"保留（SET、advisory lock、LISTEN/NOTIFY）对大模型上下文管理有何启示？ PgDog 解决的核心问题之一是：在连接复用时如何保留特定会话的状态，而不强制 connection pinning。这与大模型 inference 中的 Session KV Cache 迁移问题高度相关——如何在连接迁移的同时保持 KV Cache 状态，是提升 inference 集群利用率的关键命题。

← 返回文章列表