Pgedge

pgEdge，企业级 PostgreSQL 平台，内置 AI 智能工具、多主复制与零停机高可用，支持自托管、云部署或全托管。

通往无限 Postgres 之路：Neon、Pg_mooncake、Pg_tier 与 Pg_lake 深度评测

PgEdge 深入评测了 Postgres 实现“无限存储”与冷热数据分离的几种主流方案。对比了 Neon（重写存储引擎）、pg_mooncake（实时镜像）、pg_tier（已废弃的分层）及 pg_lake（独立守护进程）。重点介绍了自家新产品 ColdFront，其通过嵌入 DuckDB 和自动归档机制，在保持单份数据副本的同时实现了透明的读写分层。文章详细分析了各方案在架构侵入性、运维复杂度及性能上的权衡，为需要处理海量历史数据的 Postgres 用户提供选型参考。

收藏25 天前

展望 PostgreSQL 19：分区重组的新语法

PostgreSQL 19 引入 SPLIT PARTITION 和 MERGE PARTITIONS 语法，让分区重组从繁琐的手动建表、拷贝、分离变为单条语句完成。文章详细演示了按时间范围拆分季度为月度、合并月度为季度的实操，并指出关键限制：操作期间会持有 ACCESS EXCLUSIVE 锁导致全表冻结，且会丢失分区本地的索引和约束。这对需要高频维护分区架构的 DBA 和后端工程师极具参考价值，能显著降低运维复杂度。

收藏41 天前

展望 Postgres 19：为所有数据开启校验和

Postgres 19 引入在线开启数据校验和的功能，解决了以往必须停机数小时才能启用该特性的痛点。校验和不仅防御硬件位翻转导致的静默数据损坏，还是 pg_rewind 高可用切换的关键前提。新版支持后台异步转换并可调节 I/O 限速，让生产环境平滑升级成为可能。

收藏43 天前

Looking Forward to Postgres 19: It's About Time

收藏64 天前

展望 PostgreSQL 19：查询提示（Query Hints）终于来了

PostgreSQL 19 的功能冻结包含了社区争论超过十五年的"查询提示"——只不过它被巧妙地命名为"计划建议"（plan advice），通过 pg_plan_advice 和 pg_stash_advice 两个模块实现。文章作者追踪了这场漫长争论的历史脉络：从 2010 年 pgsql-performance 邮件列表上 Robert Haas 与 Tom Lane 等人的激烈交锋，到社区对 Oracle 式 hint 嵌入 SQL 注释的坚决反对。作者详细解释了新方案如何逐一回应历史质疑：建议完全独立于 SQL 之外（通过 GUC 或独立 stash 管理），不是替代而是约束优化器的搜索空间，失效时优雅降级而非报错崩溃，且优化器能反生成自己的建议字符串供用户直接使用。文章还深入介绍了建议语言的表达力（扫描方法、连接顺序、连接方式、并行控制）、pg_stash_advice 的生产部署方案（按会话/角色/数据库作用域、持久化、随时可改），以及 EXPLAIN 输出的详细反馈机制。文中穿插了大量具体 SQL 示例和代码片段，结论是：Postgres 社区花了二十年说绝不加 hint，最终却加了"建议"——技术上说，这确实是最准确的表述。

收藏71 天前

Why Postgres Lacks Transparent Data Encryption

收藏79 天前

检查点、写入风暴与你的数据库

PostgreSQL 的检查点配置不当会导致性能骤降 40%——本文用实测数据证明了这一点。WAL（预写日志）写满时会触发强制检查点，与定时检查点不同，强制检查点不顾 checkpoint_completion_target，瞬间爆发磁盘 IO 风暴，与业务查询争抢带宽。作者在 2,000 IOPS 的云盘上以 pgbench 做了两组对比：默认 1GB max_wal_size 下，第 42 秒 WAL 触顶后 TPS 从 1,100 暴跌至 620 且未恢复；调至 4GB 后，全程无强制检查点，TPS 稳步爬升至 1,200。文章进一步给出了线上定位方法——用 pg_stat_checkpointer（PG17+）或 pg_stat_bgwriter 检查 requested 与 timed 的比例，开启 log_checkpoints 捕获 "checkpoint starting: wal" 的告警日志。建议写密集型 OLTP 从 10GB–20GB 起步，大批量操作可到 50GB+，配合 pg_walsizer 扩展自动调节。对在用 PostgreSQL 的团队来说，这是一篇可拿来即用的实操调优指南，尤其适合被周期性 IO 尖峰困扰的 DBA。

收藏124 天前

MCP传输架构：边界、故障模式与工程选型指南

本文系统解析MCP三种传输模型（stdio、HTTP+SSE、HTTPS+SSE）的架构边界与故障模式。核心论点：传输层不是实现细节，而是可靠性工程的组成部分，决定了Agent系统在真实负载下的延迟稳定性、故障传播方式和安全边界。文章逐一详述每种模型的适用场景——stdio适合同主机本地执行（最低延迟、进程隔离），HTTP+SSE适合受信集群内部（水平扩展、负载均衡），HTTPS+SSE适合跨信任边界的生产环境（TLS加密、证书身份验证）——并给出了连接池、超时、重试策略、断路器、证书管理等生产级配置建议。附有故障案例分析和三种模型的详细对比表，对正在构建生产级Agent基础设施的工程师有实操参考价值。结尾推广了pgEdge自家的Postgres MCP服务器实现。

收藏191 天前

PostgreSQL 开源 MCP 服务器：pgEdge Beta 2 现已发布，Beta 3 即将到来

pgEdge Postgres MCP Server 发布 Beta 2 与预告 Beta 3，让 LLM 更灵活地操作 PostgreSQL 数据库。Beta 2 最大亮点是可选的写访问模式（默认关闭，支持 DDL/DML，界面有醒目警告标识），配合 Token 优化——count_rows 预检表大小、分页查询、TSV 格式替代 JSON 节省约 30% Token 开销、CLI 命令重组、知识库混合分块算法（两遍扫描：先语义切分再合并小碎片，保留代码块和表格完整性）。Beta 3 将推出自定义工具功能，通过 YAML 将复杂业务逻辑包装成 MCP 工具供 LLM 调用，支持 plpgsql/plpython3u/plv8/plperl，以及 LLM 自主切换数据库连接。对正在构建 AI 数据管线的开发者来说，这些更新提供了更安全可控的 LLM-to-PostgreSQL 集成路径，尤其是 write access 的安全设计（默认关闭+视觉警告）和自定义工具对领域特定应用的潜力值得关注。

收藏199 天前

基于 PostgreSQL 的企业级 AI 开发开源工具包

pgEdge 公司官方产品页面，介绍其 AI 工具包（MCP Server、RAG Server、Docloader、Vectorizer 等），声称可基于 PostgreSQL 构建企业级 AI 应用。内容完全是组件列表加功能说明，没有任何个人经验、真实案例细节、踩坑记录或独立观点。属于典型的厂商机构号自宣材料，信息可查但缺乏讨论入口和阅读价值，对中文读者几乎无推荐必要。

收藏206 天前

PostgreSQL 18 的 RETURNING 子句增强：现代应用的变革性功能

PostgreSQL 18 为 RETURNING 子句引入 OLD 和 NEW 别名，支持在 INSERT、UPDATE、DELETE 和 MERGE 操作中同时访问变更前后数据值。文章通过产品库存系统完整示例，演示了如何用 MERGE + RETURNING + OLD/NEW 在一个原子操作内完成数据同步、变更捕获和审计追踪，无需触发器和额外查询。此前只能通过多次 SELECT、复杂触发器或应用层逻辑来对比前后差异，新特性大幅简化架构。附有完整的建表、MERGE 操作、审计表插入及结果查询代码，并引用了具体 commit（80feb727c8）和社区讨论。对于处理数据同步、变更追踪或审计需求的 PostgreSQL 开发者，是直接可用的实操参考。

收藏221 天前

在Postgres上构建AI智能体：我们为何打造PgEdge Agentic AI工具包

PgEdge 发布开源 Agentic AI Toolkit for Postgres，核心卖点是满足企业级高可用、数据主权、安全合规等需求，且不锁定自家数据库，可对接社区版 Postgres 和 Amazon RDS。文章指出当前 AI 工具难以适配金融、政府等受监管行业的合规基础设施，现有数据库迁移成本高，且缺乏独立厂商提供完整 MCP Server。工具包包含 MCP Server、自然语言查询 CLI/Web 客户端、自动向量化扩展 pgEdge-vectorizer、RAG Server 等组件，支持在现有数据库上快速搭建 AI 应用和智能体工作流。

收藏241 天前

使用 PostgreSQL 构建 RAG 服务（三）：部署你的 RAG API

pgEdge 官方教程第三篇，手把手教你将前两篇准备好的 PostgreSQL 文档块和向量嵌入，通过 pgEdge RAG Server 部署为可用的 HTTP API。文章覆盖了从安装编译、YAML 配置（数据库连接、嵌入模型、LLM 模型、token 预算、top_n 等）、混合检索（向量相似度 + BM25 关键词匹配）原理到实际调用的完整流程。还深入介绍了流式响应、多 Pipeline 管理（同一服务支持多个文档库）、结构化过滤防止 SQL 注入、对话历史保持上下文、多种 LLM 提供商切换（OpenAI/Anthropic/Voyage/Ollama 本地模型）以及生产部署要点（TLS/HTTPS、反向代理鉴权、Systemd 服务）。最后给出性能调优建议和 Python 客户端示例。整个方案基于 PostgreSQL 加单一 Go 二进制文件，无需消息队列或独立向量数据库，适合已在使用 PostgreSQL 且希望自建轻量 RAG 系统的开发团队。

收藏247 天前

用 PostgreSQL 搭建 RAG 服务器——第1部分：加载文档内容

这是一篇由 pgEdge 官方发布的 PostgreSQL + RAG 技术教程第一部分，详细演示如何用 pgEdge Document Loader 将文档加载到 PostgreSQL 数据库。文章给出了完整的建表 SQL、权限设置、CLI 工具安装与使用、配置文件写法、跨格式支持（HTML/Markdown/rst）以及多文档集管理方案。操作步骤清晰、代码可直接复制使用。缺点是全文围绕 pgEdge 自家工具链展开，本质是产品教程加推广，缺乏独立技术视角或对比讨论。对正在选型或使用 pgEdge 体系的开发者有实用参考价值，但对更广泛的技术读者吸引力有限。

收藏254 天前

Postgres 18 跳过扫描：打破最左索引限制

Postgres 18 新增 B-tree 跳过扫描（Skip Scan）功能，解决了多列索引必须从最左列开始查询的长期痛点。本文通过 SQL 示例和执行计划对比，详细解释了工作原理：当查询条件跳过索引前置列时，PostgreSQL 可自动识别前置列的不同值，分别进行索引查找并合并结果。实测显示，对于前列基数较低的场景（如 region 仅 4 个值），查询性能从顺序扫描的 48ms 降至 12.8ms，缓冲区读取从 7917 降至 67。文章还讨论了适用条件（低基数前置列 + 后置列等值条件）、当前限制（仅 B-tree 索引）以及索引整合建议。内容技术上扎实，有实际可复用的查询示例和优化思路，对 Postgres DBA 和开发者有参考价值。但行文偏公司博客体，个人观点和讨论入口不足。

收藏256 天前

使用 exec_node() 和 Spock OSS 简化 PostgreSQL 集群级 SQL 执行

pgEdge 官方博客介绍了一个自建的 exec_node 函数，用于在分布式 PostgreSQL 集群中跨节点远程执行 SQL 命令。核心价值在于：pgEdge 基于 Spock 逻辑复制的架构下，DDL、VACUUM、ALTER SYSTEM、Spock 管理命令等操作默认不会自动复制到各节点。exec_node 函数利用 dblink 扩展，允许用户通过标准 SQL 在指定节点或全部节点上执行这些非复制命令，避免了手动登录各节点或编写外部脚本的繁琐与风险。文章提供了大量实际代码示例（VACUUM ANALYZE、ALTER SYSTEM、spock.repset_add_table 等），并给出了使用注意事项和最佳实践。但本文整体风格偏向产品文档式教程发布，属于 pgEdge 公司官方博客的技术推广内容，缺乏独立观点或个人叙事，讨论入口有限，对非 pgEdge 用户的参考价值不高。

收藏272 天前

PgEdge and CloudNativePG Partnership: Simplifying Distributed Postgres on K8s

收藏283 天前

PostgreSQL 多主集群中的冲突解决与规避完全指南

PostgreSQL 多主（Active-Active）集群的数据冲突是分布式数据库最棘手的工程问题之一——不同节点同时对同一行数据操作，轻则数据覆盖丢失，重则节点永久性分叉，且原生逻辑复制默认不做任何冲突管理。本文源自 PGDay Chicago 2025 的现场演讲，系统拆解了四类冲突场景：收敛型（删除/截断等幂等操作）、可解型（INSERT/UPDATE 冲突，默认 Last-Write-Wins 可能导致意外丢数据）、发散型（三节点竞态导致节点永久不一致，需人工干预工具修复）、以及幻影型（应用层重试引发的幽灵重复记录，单节点也可能出现）。文章还给出了从架构层面规避冲突的实战建议（粘性会话、区域隔离、用账本模式替代直接更新），以及 CRDT（冲突无复制数据类型）的具体 SQL 实现方法（pgEdge Spock 与 EDB BDR 两种方案对比）。对于正在选型或运维 PostgreSQL 分布式方案的团队，这是少有的同时讲清理论与踩坑细节的技术参考。

收藏308 天前

pgEdge 发布企业版 PostgreSQL 并宣布全部组件开源

pgEdge 发布企业级 PostgreSQL 发行版并承诺将所有数据库服务器组件（包括 Spock 多主复制、LOLOR 大对象逻辑复制、Snowflake Sequences）在 PostgreSQL 社区许可下完全开源。该发行版内置高可用、pgAudit/pgBackrest/pgBouncer/PostGIS/pgVector 等企业级扩展、pgAdmin 管理界面，支持物理机和容器部署，并提供 24×7 技术支持。但这是一篇典型的企业产品发布通稿，全文围绕自家产品功能罗列和卖点包装，缺乏个人经验、现场观察或独立观点，没有为读者提供讨论入口或可反驳的立场。

收藏310 天前

PgEdge 核心组件正式开源

前资深 PostgreSQL 工程师讲述个人职业选择：在上一家公司近二十年后，不愿转入 AI 方向，转而加入专注分布式 PostgreSQL 的 pgEdge。公司正式宣布将 Spock 复制引擎、Snowflake 集群唯一序列扩展和 Lolor 大对象逻辑复制扩展等核心组件，从限制性的 pgEdge 社区许可证全面转为 OSI 批准的 PostgreSQL 开源许可。文章包含职业转型的个人故事和具体的技术变更说明，但本质仍是公司博客的发布公告，作者署名仅为公司名，缺少明确的个人观点或讨论入口。

收藏339 天前

PostgreSQL 时间点恢复（PITR）实战指南

PostgreSQL 17 增强了 PITR 时间点恢复能力，包括更快的 WAL 回放速度、改进的日志压缩和更细粒度的归档控制。本文从基础原理讲起，逐步演示了配置 WAL 归档、用 pg_basebackup 做基础备份、设置恢复目标时间点并完成数据库回滚的完整流程，同时梳理了 WAL 文件丢失、恢复性能瓶颈、时钟偏移等常见坑及对应解决方案。文章结构清晰、步骤可复现，适合 DBA 作为操作参考手册，但整体偏厂商博客风格，缺乏个人经验叙事和独特视角，读起来像文档翻译而非实战分享。

收藏612 天前

理解和减少 PostgreSQL 复制延迟

本文系统梳理了 PostgreSQL 流复制与逻辑复制两种方案的延迟成因，包括网络延迟、I/O 瓶颈、CPU/内存不足、主库写入过重和资源争抢等常见场景，并逐一给出可操作的优化手段（WAL 参数调优、启用压缩、异步复制、并行应用、批处理事务等）。文章还提供了 pg_stat_replication 和 pg_stat_subscription 的监控查询语句，以及一个 Python 可视化示例。内容结构完整、信息正确，但素材基本来自官方文档的整合搬运，两个"真实案例"缺乏具体公司名、数据细节和踩坑过程，更像是编撰的通用示例。整体是一篇机构号常规技术教程，无个人经验、无独特角度、无讨论入口，适合快速查阅配置参考，但缺乏让人点开和讨论的吸引力。

收藏628 天前