工程实践 ClickHouse Engineering 2026/11/06
文章记录作者对 ClickHouse Managed Postgres 内置 WalShadow 的为期一个月私有预览测试，比较其与 ClickPipes 从 Postgres 向 ClickHouse 同步变更的延迟和运维表现。作者让同一源库并行运行两条链路，以提交到目标可见为口径，在每秒 1 千至 20 万行写入下测量延迟，并校验行数、求和与哈希一致性。结果显示 WalShadow 中位延迟稳定在约 0.4 秒，而 ClickPipes 在约每秒 5 万行以内受 Sync interval 影响、超过后持续积压。文章还验证仅写 Postgres 时聚合正确，模式变更、源库重启/扩缩容、目标停止等可自动恢复，并列出按表并行可见、初始加载 _commit_ts/_lsn、大事务阻塞等边界，结论限于私有预览环境。
推荐收录：文章提供了同源同目标的并行对比实验，给出提交到可见延迟、吞吐拐点和数据一致性校验等直接证据，并系统测试扩缩容、重启、目标停止等运维场景。适合数据库工程师、数据平台与实时分析架构师评估 Postgres CDC 方案；其测量口径、故障场景清单和目的地表使用注意事项可迁移到其他同步链路。需注意这是厂商博客中的私有预览结果，默认值和性能结论可能随正式版变化。
工程实践 PlanetScale Blog 2026/11/05
文章介绍 PlanetScale Neki 为 Postgres 分片设计非计划故障转移的机制。Admin 不会仅凭自身健康检查失败就提升副本，而是用可达副本的 pg_stat_wal_receiver 状态交叉验证主库是否有效不可用，并结合同步复制 ANY 1 语义判断写入是否阻塞。确认后，系统在 primary_conninfo 主机名前加 // 断开副本，既阻止旧主回归后重新获得确认，也冻结各副本 WAL 位置；再按最高 receive_lsn、其次 replay_lsn 选择可提升副本，并把旧主标记 TEARDOWN、暂不自动回收。文章还覆盖进程退出、拒连、丢包和冻结进程的检测方式，以及异步持久化、跨 AZ 确认和 Admin 自身故障等边界。
推荐收录：文章完整呈现了非计划故障转移从不确定性检测、副本证据交叉验证、WAL 位置选主到旧主隔离的决策链，并明确同步/异步持久化与跨 AZ 确认的边界。适合数据库内核、分布式系统、SRE 和基础架构读者，其“不依赖单一健康检查、用可观测证据收敛、冻结副本并按最大 WAL 位置选主”的方法可迁移到其他有状态主从系统。风险是方案与 Neki/Postgres 实现强绑定，需结合自身复制协议评估。
工程实践 ClickHouse Engineering 2026/11/04
文章讨论托管 PostgreSQL 在主库可能仍存活时的 fencing：仅提升备库并切换 DNS 无法阻止旧主库继续写入，异步复制、quorum commit 和客户端取消查询都可能造成脑裂。作者介绍 Ubicloud 控制面的并行 fencing 策略：裸金属在宿主机关闭 veth，AWS 强制解绑承载用户流量的第二块网卡，GCP 删除 Dynamic NIC，并给出实测延迟。文中也指出 pg_stop 重启后失效、pg_hba 只影响新连接等局限，以及所有机制失败仍提升备库的 fail-open 取舍。结论依赖各云平台网卡可解绑能力，核心是可用性与一致性之间的显式权衡。
推荐收录：文章以真实托管 PostgreSQL 故障切换为背景，给出跨裸金属、AWS、GCP 的具体 fencing 实现、失败路径和实测耗时，而非概念性介绍。对负责数据库高可用、控制面或云基础设施的工程师，可直接借鉴“先阻断旧主库写入再提升”的流程设计、并行机制与 fail-open 取舍；注意其结论受各平台网卡解绑能力约束。
技术文章 ClickHouse Engineering 2026/11/03
文章围绕“应用变慢时该给应用加一份本地数据副本，还是直接用更快的 Postgres”展开架构权衡。作者先拆解同步引擎的机制：应用以声明方式订阅逻辑复制流中的表、行、列子集，在客户端或边缘节点物化，读走本地、写仍回中心库；代价是要维护第二份有生命周期的数据，并在乐观更新与提交变更到达之间做对账。文章认为只有离线、弱网或大量客户端重复读同一稳定工作集时，本地副本才划算，而 AI Agent 的查询路径随任务变化，使子集边界、渐进加载与同步扇出更难摊薄。作者建议先确认瓶颈是否在托管库的网络存储，包括 IOPS 与延迟、WAL、VACUUM 争用 I/O；随后介绍本地 NVMe、只读副本、跨 AZ standby 同步复制，以及 WalShadow 把分析负载下沉到 ClickHouse 的分层方案，并承认 NVMe 无法解决低效查询，连接池、查询优化和并发控制仍不可少。
推荐收录：文章把“加缓存或同步层”的常见反应拆成存储瓶颈、读写路径、数据副本生命周期、Agent 工作集可预测性四个可判断维度，并给出适用边界（离线、弱网、重复读同一工作集）与反例，对做后端与数据架构选型的读者有可迁移价值。需注意它出自 ClickHouse 官方博客，NVMe 与 PostgresBench 的对比数据属厂商自测，结论应结合自身负载复核后再采纳。
工程实践 PlanetScale Blog 2026/10/29
文章介绍 PlanetScale Neki 中 Postgres 分片的计划内主备切换设计，并与需要故障检测的非计划故障转移对比。流程分为预检、目标副本追平并晋升、客户端恢复三阶段；为避免 WAL 位置继续前移，Admin 先让路由器缓冲主库查询、将新事务设为只读，再断开其他副本，取采样位点与最终 receive_lsn 较高值，等待目标回放。晋升前准备复制槽和同步复制配置，确保至少一个副本参与 ANY 1 同步确认；若追平超时或校验失败则回滚并恢复旧主库。路由器缓存写查询并在新拓扑下重发，应用只感知延迟而非错误，但缓冲容量、查询截止时间和路由器确认并非强一致保证。最终保证同步持久化下已确认提交不丢失。
推荐收录。文章给出可验证的工程细节：三阶段切换、用断开副本获得最终 WAL 位点、同步复制配置准备、Router 主动缓冲与超时回滚，并明确缓冲容量和截止时间等边界。适合数据库基础设施、Postgres 高可用和 SRE 读者，其“先校验再动作、保留回退路径、将客户端恢复纳入切换协议”的思路可迁移到其他有状态服务运维设计。
技术文章 PlanetScale Blog 2026/10/27
文章追问 Postgres 何时成为默认选择，按时间线串联其可扩展设计与 BSD 许可证、Postgres95 转向 SQL 和社区治理、Oracle 收购 MySQL 后的信任变化、Heroku 默认托管、JSONB 回应文档数据库，以及 2023 年调查超越 MySQL。作者结合 DB-Engines 与 LLM 选择数据，认为没有单一转折点，而是刻意设计与偶然托管选择共同作用。文章也承认 Postgres 在水平分片和大规模性能上仍需追赶，MySQL/Vitess 仍有成熟负载。结尾含 PlanetScale 推广，结论需考虑 vendor 立场。
推荐收录：文章以 Stack Overflow、DB-Engines 和 LLM 数据库选择数据为直接依据，按节点解释 Postgres 的生态、许可证、托管便利与 NoSQL 竞争，适合数据库选型、平台工程和开源治理读者理解技术采纳路径。可迁移的是从社区治理、默认托管和扩展生态评估数据库长期走向；主要风险是作者来自 PlanetScale，文末含产品推广，需对结论保持 vendor 视角。
工程实践 ClickHouse Engineering 2026/10/23
文章是 ClickHouse 的客户案例，讲述 Shipsidekick 将基于 Vercel/Next.js 的物流 SaaS 从 Neon Postgres 迁移到 ClickHouse Managed Postgres。作者先复盘 Neon 在 Vercel Fluid 计算下因 Prisma、Vercel 与 Neon PgBouncer 多层连接池导致的池耗尽、CPU 打满和故障，再说明选型时对实例规格、单 standby 异步复制和成本取舍的考虑。迁移通过 ClickPipes 逻辑复制完成，约 500 GB 数据在 4-5 小时内同步，期间用删除并重建部分唯一索引解决在途事务冲突。迁移后 CPU 从 100% 降至 5-10%，缓存命中率从 30-35% 升至 99%，月数据查询约 10 倍加速，并补充了 AI agent 只读查询挤占主库后加超时和独立只读副本的经验。文章还指出厂商客户故事的单案例属性，性能数字未经独立复现，适合作为迁移排查线索而非通用基准。
推荐作为工程案例收录：文中给出了连接池分层、PgBouncer 托管、ClickPipes 逻辑复制、在途事务触发唯一索引冲突、单 standby 成本/一致性取舍以及 AI 只读查询限流等可迁移细节。适合正在评估 Serverless Postgres、做数据库迁移或治理高并发连接池的团队参考。但它是 ClickHouse 的客户故事，性能数字和可靠性结论缺少独立验证，读者应将其视为迁移经验与排障线索，而非中立 benchmark。
技术文章 PlanetScale Blog 2026/10/23
文章围绕分布式数据库的分片设计展开，核心论点是分片不应从表结构出发，而应从高频查询和事务共享的键出发，把相关表放入同一 shard group。文中以 storefront 为例说明如何用 xxhash 和 customer_id 定义默认 shard index，并通过 key_ranges 将 64 位键空间划分到物理 shard；customers 表可继承默认索引但改用 id，使订单、商品、地址共置。文章还讨论 reference tables 全量复制、按 SKU 的独立 shard group、SQL 表达式分片键、range/modulo 索引，以及无分片键查询使用 GSI 以两次单分片读取替代全分片扫描。边界方面，它强调跨分片事务不具备原子提交和共享快照，modulo 扩缩容会移动大量行，且内容绑定 Neki/PlanetScale 的配置与工作流，缺少通用基准验证。
推荐收录。文章用可执行的数据拓扑配置和具体查询样例，展示了查询驱动分片、共置、参考表、GSI 与扩缩容工作流之间的取舍，并明确指出跨分片事务和 modulo 的代价。适合正在设计或评估分片 PostgreSQL 的架构师、DBA 和后端工程师，其“先找查询共享键再定表”的方法可迁移到其他分片系统；需注意语法和迁移流程绑定 Neki/PlanetScale，且无独立性能基准。
技术文章 PlanetScale Blog 2026/10/21
文章反对在 Postgres 中轻率使用 ON DELETE CASCADE：多级级联删除会在单事务内产生大量死元组、索引更新和 WAL，并对所有涉及表持有 RowExclusiveLock。迁移中的 ALTER TABLE 需要 AccessExclusiveLock，会被长时间级联删除阻塞，导致写入堆积甚至拖慢同步复制；未索引外键还会让单行删除退化为全表扫描。逻辑复制也有陷阱：订阅端默认跳过外键触发器，未完整发布外键树或缺少 replica identity 会产生孤儿行或删除失败。作者因此建议用 deleted_at 软删除、后台分批清理并保持事务短小。该方案需要应用读取过滤和清理任务，主要适用于 Postgres/OLTP 大规模删除场景。
推荐收录：文章用具体的锁链、WAL 放大和逻辑复制触发器行为，解释 ON DELETE CASCADE 从便利设计演变为线上故障的路径，并给出软删除与分批清理的可执行替代方案。对负责 Postgres 模式设计、迁移和规模化删除的后端/数据库工程师尤其有用，其中“保持事务短小且有界”的取舍可直接迁移；但方案要求应用层读取过滤，落地成本需单独评估。
工程实践 PlanetScale Blog 2026/10/14
文章介绍 PlanetScale 分片 Postgres 系统 Neki 如何在分布式查询规划器中实现 Postgres sequences，重点是 volatile 表达式与跨分片同步求值。作者区分 immutable、stable、volatile，指出 now() 等 stable 表达式受 GUC 影响，而 nextval() 等序列操作必须由 router 集中执行，避免分片重复发号。文章用 table expression 和行基数说明 volatile 表达式必须按最终结果行逐行求值，不能因 join 复制而少算；工程上 Neki 尽量下推 immutable 表达式，对 UPDATE 场景先取主键/分片键并 FOR UPDATE，再逐行生成序列值下发。文章未覆盖序列 reset/cycle、全部优化器决策和更复杂 DML，且 join 顺序可能导致含 volatile 谓词的结果不总确定但语义正确。
推荐收录，因为文章以 Neki 的真实查询规划器为对象，给出了 volatile 表达式、table expression、行基数和 nextval() 跨分片协调的具体机制，并展示 UPDATE 场景下的锁与逐行下发方案。对分布式数据库、查询优化器和 Postgres 兼容层实现者而言，这些约束、取舍和实现证据具有直接迁移价值；文章也明确说明 join 顺序与序列 reset/cycle 等边界，避免读者误用。
工程实践 TiDB 社区博客 - 实践案例 2026/10/12
文章完整复盘将 PostgreSQL Citus + PostGIS 分片集群迁移至自建 TiDB 的实操过程，先对比两者分布式机制差异（Citus 中间件分片 vs TiDB 存储层 Region 自动调度），再给出全量导出 + 增量回放 + 灰度切流的迁移方案及结构适配、数据校验步骤。核心踩坑是自建 TiDB（TiKV 行存）虽支持 GEOMETRY 与基础 ST 函数，但会忽略 CREATE SPATIAL INDEX，空间谓词全表扫描导致查询数十秒。作者给出三套选型，最终采用拆分经纬度字段、建 Btree 复合索引、业务层 GeoHash 粗筛加内存精确计算替代 PostGIS 索引。结论是 TiDB 可替代 Citus 简化运维并提升吞吐，但空间查询不能直接平移，TiDB Cloud Lake 列存虽支持空间索引却不适合 OLTP。
推荐收录，因为它给出了从分片方案对比、迁移步骤到空间索引兼容性踩坑的完整证据链，尤其是自建 TiDB 忽略 SPATIAL 索引这一具体根因和 GeoHash + 内存校验的替代实现，可直接迁移到类似异构数据库迁移场景。适合负责分片数据库迁移、地理空间数据处理或 TiDB 选型落地的工程读者，文中方案适用范围（OLTP 百万级点位）与列存 OLAP 的边界也交代清楚。
技术文章 PlanetScale Blog 2026/10/12
文章系统解析 PostgreSQL 的 TOAST 机制：当行超过 2032 字节阈值，变长列会被压缩或移入 TOAST 表分块存储，并受 PLAIN、EXTENDED、EXTERNAL、MAIN 存储策略控制。作者通过重复文本、随机字符、JSON 订单和 bytea 中段读取等实验，对比 pglz 与 LZ4 的压缩率、写入速度、页访问量和内存开销。结论是 LZ4 因速度快更适合作为多数表的默认压缩，pglz 在 JSON 键重复和短前缀预览场景可能更省空间；已压缩数据或需中段读取的大 bytea 应使用 EXTERNAL。文章还区分 TOAST 与 large object 的容量、生命周期和适用边界，结论依赖 Postgres 版本及 LZ4 支持。
推荐收录：文章不仅解释 TOAST 的 2032 字节阈值、分块与存储策略，还用可复现实验量化 pglz 与 LZ4 在压缩率、加载耗时和页访问上的取舍，并给出 EXTERNAL 的适用场景。对 PostgreSQL DBA、后端工程师和做存储/性能优化的人，可直接用于选择列压缩算法、排查大字段读写开销和理解 large object 边界。主要风险是结论依赖特定版本、数据分布和 PlanetScale 环境，迁移前需在本地验证。
工程实践 ClickHouse Engineering 2026/10/08
Clera 是一家 AI 招聘代理公司，其原有 Postgres 数据库出现点查被后台分析查询阻塞、CPU 长期打满、超时与写入失败等问题。团队把负载拆分为热读、点查和后台分析三类，用约 500 GB 生产数据回放以及 sysbench TPC-C 基准，对 Supabase、Neon、PlanetScale 和 ClickHouse Managed Postgres 作对比，认为基于本地 NVMe 存储的方案在延迟与吞吐上更优。迁移通过两条 ClickPipes 管道在夜间完成 500+ 张表从 EU 到 US 的搬迁，随后重建触发器、索引与序列并进行对账和切流，迁移后 CPU 从 100% 降到 10–20%。文章附有开源基准仓库便于复核，但作为厂商博客的客户故事，其基准结论和选型建议带有明显推广倾向，技术细节也偏叙事而非深入权衡。
推荐收录：文中给出把生产负载分为热读、点查、后台分析三类的分析方法，以及用 500 GB 数据回放加 sysbench TPC-C 并公开基准仓库的评测流程，对计划做数据库选型或迁移的团队有可迁移价值，迁移中处理扩展、触发器、索引与切流的约束也可参考。主要风险是内容出自厂商博客的客户故事，基准与选型倾向明显偏向 ClickHouse，读者应结合自身负载验证。
工程实践 PlanetScale Blog 2026/10/08
TIN v1.0.6 为 PlanetScale 的 Postgres 全文检索扩展加入 stemming，支持 rust_stemmers/Snowball 的 18 种语言，并优化 top-k ORDER BY 的 tiebreaker，使其与普通排序共用 block-max 执行计划。基准显示，在 85 GB Stack Exchange、1.5 亿文档的只读 BM25 top-10 查询中，TIN 默认打分在 x86-64 与 ARM64 上吞吐和 p99 均优于 ParadeDB 0.26.0。默认打分省略文档频率超过 10% 的词以节省 CPU，但匹配逻辑不受影响，可用 tin.full_score 或 dense_ratio 调整。stemming 需重建索引，TIN 索引格式未变可原地升级；作者也提醒基准是索引约为共享缓冲区两倍的理想只读场景，x86 AVX-512 对文本搜索更有利。
推荐收录。文章不仅公布版本更新，还给出 stemming、tiebreaker 执行计划和 BM25 高频词省略策略等可验证细节，并提供跨 x86-64/ARM64 的可复现基准与明确边界。适合使用 Postgres 全文检索、做搜索索引性能评估或对比 ParadeDB/TIN 的工程师，但生产选型仍需复测写入、混合负载和索引重建成本。
技术文章 PlanetScale Blog 2026/10/07
文章从青铜时代的漏水钟讲到现代软件，梳理漏桶（leaky bucket）作为准入控制（admission control）机制的由来与实现。作者区分漏桶在软件中的两种用途：作为计量器即时决定工作是否放行，作为队列决定可等待的工作量，并给出惰性排空公式，说明实现上只需保存上次水位与时间戳，开销极低。文中以 Shopify GraphQL Admin API 的文档化限流为例，说明按查询预估成本扣费、执行后多退少补、响应中回传桶状态让调用方提前降速的设计。随后对比 Oracle（1999）、SQL Server（2008）的资源管理器与 Postgres 的 statement_timeout，指出开源数据库缺少事前拒绝能力，并介绍 PlanetScale Database Traffic Control 以 token bucket、server share、burst limit、单查询上限和最大并发 worker 在查询执行前做准入决策。后半部分带有明显产品推广性质，读者需区分通用机制与厂商方案。
推荐收录：文章把漏桶的历史渊源、惰性排空的实现公式、Shopify 按查询成本计费的限流设计，以及 Oracle/SQL Server/Postgres 在准入控制能力上的差异串成一条可迁移的机制脉络，适合后端、数据库与 API 设计读者理解限流与资源预算的取舍。主要风险是后半部分对 PlanetScale Traffic Control 的介绍带产品推广色彩，读者应把通用机制与厂商实现分开评估。
工程实践 ClickHouse Engineering 2026/10/02
文章解释 ClickHouse Managed Postgres 为何在备份时启用 Linux Direct I/O：默认缓冲读会经页缓存，备份流式读取数百 GB 会驱逐 Postgres 的温数据，并增加内核拷贝与 CPU 开销。作者用 wal-g 在四块 NVMe RAID0、467 GB pgbench 数据库上做对照实验，发现 Direct I/O 能保留 40 GiB 温表、把备份期间查询 p99 从约 0.18 ms 降至 0.06 ms，并减少约 14% CPU。但 Direct I/O 同时失去内核预读，默认 128 KiB 小读在 RAID0 上只命中单盘，需要按阵列宽度设置 4 MiB 读并调整并行 reader 数；密集 NVMe 和小规格机器需使用更多 reader。最终配置按服务器 vCPU、内存、盘数和实例族生成，并保留回退开关。
推荐收录：文章给出真实硬件上的对照实验和可复现配置（四盘 RAID0、467 GB 数据库、wal-g 的 WALG_DIRECT_IO_BLOCK_COUNT 与 WALG_UPLOAD_DISK_CONCURRENCY），量化了页缓存驱逐、p99 延迟、CPU 与盘利用率取舍。适合 PostgreSQL DBA、SRE、存储与后端性能工程师阅读，可迁移到备份、迁移等顺序扫盘场景；但结论依赖 wal-g、RAID0 和实例盘型，落地前需按自身阵列和负载验证。
工程实践 PlanetScale Blog 2026/10/01
文章介绍 PlanetScale 的 PostgreSQL 分片路由 Neki 如何围绕“少做事”设计性能。由于路由层必然增加网络跳数，Neki 尽量不解码不需要理解的结果：它不像 Vitess 那样把结果转为 protobuf Row 和 Value，而是让 ExecuteResponse 保留 PostgreSQL 原始响应消息，并用 DataRows 在原始字节、行切片、指针切片三种表示间按需推进。点查可完全透传字节，LIMIT 只需扫描行边界，排序只解码排序键并缓存，投影通过列区间 runs 复制原始列帧，只有跨分片聚合等必须计算时才构造类型化值。文章也说明了该方案需维护缓冲区生命周期、三索引切片、缓存内存计账等不变量，并兼容 NULL、文本/二进制格式、编码和扩展类型，复杂度仍是主要代价。
推荐收录。文章给出了直接可验证的工程证据：以协议级代码和消息格式说明 Neki 如何在点查、LIMIT、排序、投影、聚合中逐层决定是否解码，并明确对比 Vitess 的 eager conversion。对数据库代理、分片中间件、PostgreSQL 协议和低延迟后端工程师，文中的 lazy/composable 行表示、原地投影和 Bind 帧复用方法可迁移；需注意其复杂度和不变量维护成本。
工程实践 ClickHouse Engineering 2026/09/30
文章讨论在 Postgres 扩展中引入 C++ 代码时的内存安全与错误处理冲突。Postgres 使用基于 MemoryContext 的 palloc/pfree 分配，并以基于 setjmp/longjmp 的 PG_TRY/PG_CATCH/PG_FINALLY 处理错误，而 C++ 依赖 new/delete、析构函数和异常；setjmp/longjmp 会跳过 C++ 清理（属未定义行为），异常也会绕过 PG_CATCH/PG_FINALLY，未捕获异常还会 abort 进程，甚至导致 postmaster 重启并触发集群范围崩溃恢复。作者以 ClickHouse 的四个扩展给出不同策略：pg_clickhouse 彻底移除 C++ 并重写 C 库 clickhouse-c；pg_re2 把 C++ 限制在单个文件且分配全部包在 try/catch 内；pg_chdb 将 libchdb 移入独立 helper 可执行文件；pg_stat_ch 把 C++ 隔离到后台 worker，并用 terminate handler 将未捕获异常转为 ereport(FATAL)。文章明确 FATAL 方案只是缓解而非通用崩溃隔离，无法修复不一致的共享内存，并复盘了 PR #126 中中断出队导致重复释放的所有权缺陷，以及 PR #129 向 helper 进程迁移的长期方向。
推荐收录，因为文章给出了 C/C++ 混合编程在 Postgres 内存与错误模型下的具体冲突证据（setjmp/longjmp 跳过析构、异常绕过 PG_CATCH、abort 引发集群恢复），并用四个真实扩展展示了从消除 C++、单文件隔离、独立 helper 进程到 terminate handler 的递进式取舍。适合开发 Postgres 扩展、编写 C/C++ 互操作代码或负责数据库稳定性的工程师，其隔离层次划分与对 FATAL 缓解边界的反思可直接迁移到类似场景。
工程实践 ClickHouse Engineering 2026/09/28
文章讨论 Postgres 在坏查询和内存压力下的可靠性，先解释 work_mem 按查询节点和后台进程分别生效、hash_mem_multiplier 与并行 worker 会成倍放大内存占用，并说明递归 CTE 的 UNION 去重哈希表无法落盘、会持续增长到查询结束。随后用一个约 1260 万节点的递归 UNION 查询，在 ClickHouse Managed Postgres、Cloud SQL、PlanetScale Postgres 和 Amazon RDS 上做并发压测，比较查询失败、会话失败和集群崩溃三种失败模式。结论是 ClickHouse 通过禁用内存 overcommit 并设置上限，让单个查询以 SQL ERROR 失败而集群保持存活；RDS 等则可能触发 OOM killer 并进入数分钟崩溃恢复。边界在于这是厂商自测，各服务的配置、内存上限和缓存策略不同，结论可能有利于自身策略。
推荐收录，因为文章既讲清了 Postgres work_mem、并行 worker 和递归 CTE 内存不可控的具体机制，又给出跨四家托管服务的可复现压测方法与失败模式分类。适合 DBA、SRE 和后端工程师在数据库选型、坏查询防护、内存上限与故障隔离设计时参考，但需警惕厂商自测和配置差异带来的公平性风险。
技术文章 PlanetScale Blog 2026/09/25
文章讨论云端 Postgres 选择 x86-64 还是 aarch64 的实际影响。作者从超线程与 vCPU 定义切入：x86 常把超线程线程计为 vCPU，而 Graviton、Axion 等 ARM 芯片每 vCPU 对应完整物理核，因此 ARM 适合高并发小查询，x86 凭借更高单核频率适合少量 CPU 密集型大查询。文章还比较向量宽度，指出 x86 的 AVX2/AVX-512 比 Graviton 的 128 位向量更有利于 TIN 索引和 pgvector 的部分计算。随后说明 Postgres 文件不可跨架构直接复制，并用 pg_trgm 的 char 符号性差异解释复制风险，切换需逻辑复制到新集群。最后建议普通负载默认 ARM，CPU 重型负载重点测试 x86，迁移前做同数据同并发基准并衡量成本。
推荐收录：文章把架构选择落到 vCPU 语义、单核/多核取舍、向量指令宽度和 Postgres 物理复制限制上，并给出 PlanetScale 生产约束与迁移路径，证据具体而非泛泛而谈。适合数据库/基础设施工程师在选型、性能调优或跨架构迁移前阅读，可迁移到其他依赖底层架构的数据库与搜索负载。风险是部分结论来自厂商视角，读者仍需自行用同数据同并发基准验证。
技术文章 PlanetScale Blog 2026/09/22
文章系统讲解全文搜索倒排索引的内部结构，并落到 Postgres 场景说明工程实现。核心组件包括词项字典、postings list、位置数据与词频统计；postings 通常有序存储，并用差值编码、位图压缩减少空间，以支持并集/交集、短语和跨度查询。查询侧还讨论 tokenizer、停用词、词干化带来的精度取舍，以及 BM25 打分和 top-k 通过块级统计跳过 postings 的优化。更新删除依赖不可变 segment、tombstone 和后台 merge，但合并带来大量 I/O 与临时空间，删除则造成空间放大和过滤开销。最后分析 Postgres 集成约束，包括 ctid 映射、WAL、VACUUM、可见性映射、查询规划器与 CustomScan。文章偏概念性综述，TIN 的性能数据和实现细节需阅读另一篇深潜。
推荐收录：文章完整解释倒排索引的词项字典、postings 压缩、BM25、segment 合并与 Postgres 集成约束，技术证据密度高。适合数据库、搜索和后端工程师建立系统认知，也可迁移到 Lucene、Elasticsearch 类系统的选型与调优。主要局限是概念综述，TIN 的具体性能数据需参考另一篇深潜。
工程实践 ClickHouse Engineering 2026/09/21
文章以 Postgres 在本地 NVMe 上的性能表现为切入点，在 482 GiB 数据集上对比 NVMe 与 gp3 EBS，测得 NVMe 吞吐约 9.2 倍、UPDATE 延迟 4.0 ms 对 36.9 ms。作者用 pg_stat_activity 和 CPU profile 解释：EBS 下大量后端阻塞在 DataFileRead，NVMe 将缓存未命中从毫秒级降到微秒级，并改善 VACUUM 与逻辑解码。针对本地 NVMe 的临时性，文章提出跨 AZ quorum 同步复制加 WAL-G 持续归档来保证持久性与可恢复性。随后论证存储加速只能提高行存上限，无法替代列存做大规模扫描，需用 CDC 将数据同步到 ClickHouse。适用时需注意 NVMe 容量受实例限制、复制与归档增加运维复杂度，且查询下推覆盖度需验证。
推荐收录：文章给出可复现的 benchmark 设计（pgbench 33,000、482 GiB、NVMe 对 EBS）和从 pg_stat_activity、CPU profile 到 VACUUM、逻辑解码的分层证据，并讨论本地 NVMe 临时性下的 quorum 复制与 WAL 归档方案。适合负责 PostgreSQL 性能、存储选型或 HTAP/CDC 架构的工程师，其中“存储解决 OLTP、列存解决 OLAP”的拆分逻辑可迁移。需注意文章来自 ClickHouse 厂商，benchmark 与产品推荐带有一定立场，pushdown 和运维复杂度仍需结合场景验证。
工程实践 PlanetScale Blog 2026/09/21
文章介绍 PlanetScale Postgres 为何会在主从切换时因逻辑复制槽未就绪而主动阻断 cutover。作者先区分物理槽与逻辑槽：物理槽供副本记录 WAL 进度，逻辑槽则把 WAL 解码为面向 CDC 消费者的事件流；若提升的副本没有同步的逻辑槽书签，下游会丢失事件或停摆。PlanetScale 的 Kubernetes operator 会检测 failover、hot_standby_feedback、sync_replication_slots 等配置，发出告警并在计划内切换前等待槽 ready，从而避免静默数据丢失。正确配置包括创建槽时设置 failover=true、在控制台登记槽名，并开启 hot_standby_feedback 与 sync_replication_slots；后者默认关闭，因为会带来 vacuum horizon 固定、主库膨胀和长事务风险。该方法主要面向 PlanetScale Postgres 和逻辑复制槽场景，并非完整搭建指南，且宽限期后仍允许强行切换。
推荐收录，因为文章给出了具体可验证的故障模式、参数配置和平台阻断策略，清楚解释了逻辑复制槽未同步时切换会造成下游数据丢失。适合 PostgreSQL、SRE、CDC 与数据管道维护者阅读，其 failover=true、slot 登记和 hot_standby_feedback 权衡可迁移到自建高可用集群；注意其行为与 PlanetScale 平台托管能力强绑定，原生 Postgres 需自行补齐自动化与保护逻辑。
工程实践 PlanetScale Blog 2026/09/18
本文从底层拆解 Neki 的分片架构：它不 fork Postgres，而是在原生 Postgres 实例上扩展，用 PostgresManager 管理实例、Sidecar 连接池，并将主从副本组成 shard。Admin 处理故障检测、切换和持久性策略，Operator 在 Kubernetes 上编排生命周期；Router 对客户端提供单一 wire-protocol 入口，基于权威 shard catalog 解析并规划分片查询，必要时做跨分片 join/聚合。etcd 保存 Data Topology，Replicator 支撑 MoveTables、Reshard 和 OnlineDDL，并通过 Router 缓冲完成 cutover。文章适合理解分布式数据库控制面与数据面设计，但作为厂商架构概览，缺少性能基准、故障边界和成本权衡。
推荐收录：文章把 Neki 的数据库控制面与数据面逐层拆成 PostgresManager、Sidecar、Shard、Admin、Operator、Router、Data Topology 和 Replicator，并说明 OID 一致性、连接池分类、跨分片 join、etcd 拓扑和 cutover 缓冲等具体机制。适合分布式数据库、基础设施和 Kubernetes 平台工程师参考，可迁移到分片系统设计与在线数据迁移场景；但它是厂商架构概览，尚无性能基准和故障边界验证，需结合后续实测判断。
技术文章 pganalyze Blog 2026/09/17
本文面向从 SQL Server 转向 Postgres 的 DBA，系统梳理 Postgres 监控数据的来源与配置方法。作者先用任务对照表指出两者的本质差异：SQL Server 的诊断多为查询时决策，而 Postgres 必须在事件发生前决定是否记录，未写出的日志行事后无法恢复。文章介绍 pg_stat_activity（实时快照而非累计值）、pg_stat_* 累计视图与 pg_stat_statements（聚合查询统计）的定位与读法，并给出具体配置：启用 pg_stat_statements 需改 shared_preload_libraries 并重启、log_directory 要移出 $PGDATA、log_line_prefix 建议含 %m/%p/%q 及用户数据库应用字段、log_min_duration_statement 配合采样、开启 log_lock_waits 与 log_temp_files，以及用 pg_monitor 授予非超级用户监控权限。文中还剖析日志目录权限导致采集代理无法遍历、前缀尾部空格被复制丢失等常见陷阱，并辩证对比 Query Store、Extended Events 与 auto_explain 的取舍。结论是 Postgres 记录内容高度可配置但默认保守，需提前规划才能支撑事后排障。
推荐收录。文章给出了可直接落地的配置项（pg_stat_statements、log_line_prefix、log_min_duration_statement、pg_monitor 授权）和一张按问题定位数据源的对照表，并解释了 Postgres 与 SQL Server 在“记录时机”上的本质差异及 $PGDATA 权限等真实踩坑点。适合从 SQL Server 迁移或负责 Postgres 监控的 DBA、SRE 与后端工程师；需注意其出自监控厂商，部分建议带有工具倾向。
技术文章 pganalyze Blog 2026/09/16
本文是 pg_stat_statements 深入系列第七篇，讲解生产事故中如何查询该视图定位慢查询和高开销查询。作者指出 pg_stat_statements 只记录已完成语句且指标累计、没有时间线，因此应先查 pg_stat_activity 判断是否存在正在运行的长事务。获取时间窗口可用两种方法：隔时取两个临时表快照做差值，或在可重复负载下 reset 后重新查询，并用 pg_stat_statements_info 查看重置时间。排序不应只看 total_exec_time，还可按 calls、mean_exec_time、temp_blks_written 等发现高频、均值慢或写临时文件的查询。文章给出 SQL 示例和演示，并提醒最慢查询未必最值得优化；选择监控工具时要关注完整查询文本、采样频率、重置恢复和多工具锁竞争。其内容偏 PostgreSQL 监控实践，不展开执行计划内部原因。
推荐收录。文章给出可直接执行的 SQL 诊断流程，覆盖 pg_stat_activity 优先检查、快照差值/reset 两种时间窗口、多列排序指标和监控工具选型要点，证据具体且可迁移到生产 PostgreSQL 性能排查。适合 DBA、SRE 和后端工程师；需注意作者来自 pganalyze，工具选型部分有厂商视角，但核心方法仍具长期参考价值。
工程实践 PlanetScale Blog 2026/09/16
PlanetScale 发布并 GA 全文搜索扩展 TIN，目标是在事务、复制与并发更新下支持布尔/短语/模糊/正则查询、COUNT(*) 和 BM25 top-k。其核心设计是直接用 Postgres ctid 作为 posting 标识，省去顺序 docid 到 ctid 的映射；再用页面级与偏移级位图压缩 48 位 ctid，并借助 AVX2/AVX-512 向量化交并和 POPCNT 计数。TIN 通过堆检查、可见性映射和 liveness bitmap 保证 MVCC 与 VACUUM 正确性，分段合并时因 ctid 不变可复用位图、降低写放大。基准在 85GB Stack Exchange 语料、8 vCPU/32GB 容器中对比 ParadeDB、pg_textsearch 与 GIN，TIN 吞吐至少高 8 倍。但这是厂商自测且查询轨迹合成，跨工作负载的独立验证和运维边界仍需观察。
推荐收录：文章虽为产品发布，但给出了 TIN 以 ctid 为文档标识、位图压缩与向量化执行、MVCC/VACUUM 集成的完整设计解释，并用可复现的容器配置和对比基准量化性能。适合数据库内核、搜索索引和性能工程读者，其“复用存储引擎原生标识以减少映射和合并开销”的思路可迁移到其他索引系统；风险是厂商自测、合成查询，需结合独立验证。
工程实践 ClickHouse Engineering 2026/09/10
ClickHouse 发布开源引擎 WalShadow，直接消费 Postgres 物理 WAL 将数据复制到 ClickHouse，绕开逻辑复制槽与逻辑解码插件。其架构分四阶段：在影子 Postgres 实例中回放 catalog WAL 以维护实时 schema，并行解码堆记录，按表批量组装成 ClickHouse 原生 block，再由独立插入池并发写入。为在并行乱序下保持正确性，每行携带源 WAL 位置 _lsn，schema 变更与 truncate 等操作设置屏障等待前序数据落盘。官方基准（同区域 c8i.2xlarge）给出提交到可见延迟约 200ms、吞吐 28.9 万行/秒，对比 PeerDB 的约 10 秒与 12 万行/秒，并支持加列、改列名、删列、建表等 schema 演进。文章属产品发布稿，性能数据来自单表受限场景，未深入讨论失败模式与运维成本。
收录理由在于它给出了可迁移的 CDC 设计证据：物理 WAL 替代逻辑解码的四阶段流水线、用 _lsn 加屏障解决并行乱序正确性，以及带方法说明的延迟/吞吐基准（约 200ms、28.9 万行/秒 vs PeerDB 约 10s、12 万行/秒）。适合正在设计 Postgres→OLAP 实时同步链路的数据与平台工程师参考。需注意其厂商产品发布属性、单表基准的局限，以及托管版仍处私有预览，落地前应自行验证 schema 变更与故障恢复路径。
技术文章 Crunchy Data Blog 2026/09/02
文章深入剖析 PostgreSQL（以及其他 SQL 数据库）中 NULL 的三值逻辑语义。作者从 NULL 代表“未知”而非某个值出发，依次讲解了比较运算、布尔逻辑、算术、NOT IN、聚合、窗口函数、字符串拼接和排序中 NULL 的行为差异，并用大量可运行的查询示例展示常见错误。例如 active OR NOT active 并非永真，NOT IN 遇到 NULL 会返回空集，聚合函数会忽略 NULL 而 COUNT(*) 不会，窗口函数中的 lag/first_value 不会自动跳过 NULL，字符串拼接 || 遇到 NULL 直接返回 NULL 而 concat 会将其视为空串，NULL 默认排序高于所有真实值。文章还介绍了 IS NOT DISTINCT FROM、COALESCE、NOT EXISTS、FILTER、concat_ws、NULLS FIRST/LAST 等处理手段，并预告 Postgres 19 的 IGNORE NULLS 子句。最后强调应根据业务规则显式处理 NULL，或在表结构中用 NOT NULL 约束从源头避免歧义。适合所有使用 SQL 的开发者阅读。
推荐收录。文章不是简单罗列语法，而是从三值逻辑原理出发系统解释 NULL 在各 SQL 子句中的一致与不一致表现，并给出可迁移的排查清单。案例覆盖 WHERE、NOT IN、聚合、窗口函数、拼接、排序等高频场景，对数据工程师、后端开发者和数据库维护者都有直接参考价值。其清晰的问题定位方式和标准引用也适合作为团队内部 SQL 培训材料。风险在于示例基于 Postgres，部分行为在其他数据库略有差异，但核心概念通用。
技术文章 ClickHouse Engineering 2026/09/02
文章系统介绍 PostgreSQL 19 新增的四个系统视图，并结合作者亲自演示给出查询示例与语义边界。pg_stat_lock 提供按锁类型聚合的集群级锁等待统计，但 waits 与 wait_time 仅统计等待超过 deadlock_timeout 且最终成功的锁，fastpath_exceeded 可提示分区密集负载需调高 max_locks_per_transaction。pg_stat_recovery 以单次原子快照返回备库恢复状态，解决了多次函数调用间数值不一致的问题；pg_stat_autovacuum_scores 暴露新的 autovacuum 优先级评分与各分量权重；pg_dsm_registry_allocations 让运行时动态共享内存分配可见。作者提醒 PG19 仍处 beta、列名可能变更，且评分视图基于当前统计，只是 autovacuum 行为的提示而非保证。
推荐收录。文章不止罗列新视图，还用可复现的会话示例讲清语义细节与陷阱，例如 pg_stat_lock 只在等待超过 deadlock_timeout 时计数、fastpath_exceeded 与 max_locks_per_transaction 的关联，以及评分视图的近似性。适合 DBA、SRE 和构建 Postgres 监控与 HA 工具的读者，作为升级 PG19 时观测能力的参考。
工程实践 PlanetScale Blog 2026/09/01
文章深入解析了 PlanetScale 的 Neki 路由器在分片 PostgreSQL 数据库中的核心作用与实现机制。它指出分片数据库的难点在于决定查询应路由到哪些分片，Neki 为此引入了双层计划：先由路由器基于数据拓扑生成 Neki 计划，再将改写后的 SQL 交给各分片上的 PostgreSQL 生成传统执行计划。文章通过单点路由和 scatter-gather 两个具体示例，展示了路由器如何识别分片键、绑定参数、推送 limit、汇总多分片结果，并利用侧车进程通过 gRPC 转发工作。同时说明了路由器无状态、可独立扩展的特点，以及与 PgBouncer 等连接池工具的差异。文章还点明了 Neki 的两个缩放维度：分片扩展数据和 PostgreSQL 引擎，路由集群扩展分布式查询处理与连接管理。整体对理解分布式数据库查询路由与分片架构具有很好的参考价值。
推荐收录。文章不是抽象的理论介绍，而是直接展示 Neki 路由器的双层计划、分片路由和 scatter-gather 的具体实现，包含 EXPLAIN 输出和架构组件说明，证据具体。适合数据库内核工程师、分片库用户及分布式系统架构师阅读；其中关于无状态路由器、连接处理与查询处理分离的设计思路，可迁移到其他分布式数据库或网关类系统。
工程实践 PlanetScale Blog 2026/08/31
文章以GitHub面试题为引，解析了一个真实数据库故障链路：一个应用异常导致事务未提交，连接持有读锁；随后一个需要排他锁的schema change被阻塞，而后续所有对同一表的查询都排队等待，最终整个应用无法执行查询。作者用Postgres和MySQL的例子逐步复现了该过程，并指出根因之一是Postgres默认关闭的idle_in_transaction_session_timeout。文章随后介绍了PlanetScale提供的连接管理工具，包括Dashboard和CLI，可以查看阻塞连接、取消查询、终止事务或断开连接，并强调了保留管理连接以应对连接耗尽场景的设计。最后也涉及了该场景下如何避免锁等待以及Vitess在线DDL的优势，但文章带有明显的产品推广倾向。
文章清晰还原了未提交事务阻塞迁移并拖垮整个数据库的典型故障链路，提供了可复现的实验步骤和根因解释，对数据库运维、DBA和应用开发者都有直接参考价值。虽然结尾有PlanetScale产品推广，但核心的技术分析和锁排队原理可迁移到任何关系型数据库场景，值得收录。
工程实践 Andy Atkinson 2026/08/26
文章记录了生产环境中将PostgreSQL主键从UUID v1/v4迁移到UUID v7后获得的性能收益。作者在Postgres 18.4上通过alter table修改列默认值为uuidv7()，针对部分高频插入表观察到平均插入耗时最多降低23倍，并以表格形式列出6x、8x、9x、20x、23x五档提升案例。文中解释了随机UUID（v4）导致B-tree索引页分裂、缓存命中率下降的机制，对比v7单调递增带来的热页优势；同时重点讨论了在线切换的难点——ALTER TABLE需要ACCESS EXCLUSIVE锁，作者通过设置lock_timeout和statement_timeout配合PL/pgSQL循环重试（带抖动退避）找到了锁窗口，并预告了取消阻塞查询的预案。文章最后指出v7时间戳会暴露记录创建时间这一隐私边界，以及该方案并非对所有表都有效。
这是一篇真实、可验证的PostgreSQL性能优化工程案例，提供了从性能问题分析、方案选型、锁管理到线上实施验证的完整链路。适合使用PostgreSQL并关心写入性能或在线DDL的DBA与后端工程师，文中的锁超时加重试策略和UUID选择依据可以直接迁移到类似系统。
技术文章 ClickHouse Engineering 2026/08/25
文章介绍 PostgreSQL 19 新增的 WAIT FOR 命令，用于在异步流复制下实现 read-your-writes 一致性。作者先描述陈旧读问题：主库提交后从库需重放 WAL 才能看到变更，并对比 synchronous_commit=remote_apply、应用侧轮询 pg_last_wal_replay_lsn()、直接读主库三种旧方案在延迟与扩展性上的代价。核心方法是在主库写入后用 pg_current_wal_insert_lsn() 取 LSN，把它传给从库会话执行 WAIT FOR，阻塞至 WAL 重放到该位置；命令支持 standby_replay/standby_write/standby_flush/primary_flush 四种模式及 TIMEOUT、NO_THROW 选项。文章还解释它必须是顶层工具命令的原因：会话持有快照会阻塞 WAL 重放，形成自死锁，因此不能放进函数、过程或高隔离级别事务。边界在于 PostgreSQL 19 仍处 beta、细节可能变化，且 LSN 比较不识别 timeline，主从切换后需谨慎对待。
该文以官方文档、SQL 示例和提交历史为依据，给出 WAIT FOR 的可用语法、四种等待模式与 LSN 传递方式，并深入解释“必须顶层运行、不能持有快照”的自死锁成因，属于可长期复用的数据库机制解析。适合使用 PostgreSQL 异步复制、希望在不付同步复制开销下获得读己之写一致性的后端与 DBA 读者，也可迁移到连接池或协议感知代理注入 WAIT FOR 的设计；需注意其基于 beta 版本且 LSN 不识别 timeline。
工程实践 PlanetScale Blog 2026/08/25
文章围绕 Postgres 大表引发的工程问题展开，先从真实案例说明级联删除导致 WAL 放大、网络饱和和副本延迟，最终演变为业务中断。随后系统剖析大表在 autovacuum 启动阈值过高与执行缓慢、空间回收失败与 bloat、长查询占用连接、备份与恢复变慢、索引膨胀以及宽行 TOAST 的 OID 限制等方面的详细机制。作者对比分区、垂直扩展和分片三种解决方案的适用边界，指出分区能细分堆并改善 vacuum，垂直扩展仅能临时缓解，而分片可将大数据表拆到独立集群，避免单集群的全局性限制。文章也提醒分区不能解决 xmin 的集群级快照钉扎，分片需要选好 shard key。适合需要设计高可扩展数据库架构的工程师参考，但结尾对自有产品 Neki 的推广属于商业内容。
本文不是泛泛的问题清单，而是通过真实故障案例和具体参数（如 autovacuum 阈值、32 位 XID、TOAST OID）揭示大表问题的本质，对分区、垂直扩展和分片做了清晰的权衡对比。适合数据库管理员、SRE 和高并发应用后端工程师，文中诊断大表问题的框架和解决方案取舍可以迁移到自有系统中。注意文章末尾有产品推广，但技术分析独立完整，是长期有效的参考资料。
技术文章 PlanetScale Blog 2026/08/24
文章回顾了Postgres分片技术二十年来的演进。作者先从“shard”一词在Ultima Online游戏中的起源讲起，说明MySQL因LAMP生态先行形成了Vitess等成熟方案，而Postgres则长期依赖各公司自建。随后梳理了Skype的PL/Proxy、Instagram的逻辑分片、Citus扩展、PgDog代理、Aurora以及Spanner/CockroachDB/Yugabyte等Postgres兼容分布式数据库，逐一分析其架构与取舍。核心观点是显式分片比自动分片更可预测，原生Postgres集群比兼容层更可控。文章最后介绍PlanetScale推出的Neki，宣称结合历史经验提供显式分片、水平扩展路由器并托管备份恢复，但该部分带有明确的产品推广色彩。整体适合作为了解Postgres分片方案演进的入门综述，但对Neki的介绍需要以批判视角审视。
推荐收录，因为文章系统梳理了Postgres分片从PL/Proxy到Citus再到Spanner兼容方案的完整脉络，并给出了每个方案在运维复杂度、路由瓶颈、跨分片查询上的具体取舍，能帮助数据库团队在做分片决策时建立历史坐标系。适合数据库工程师、架构师阅读。需注意文章后半部分是PlanetScale自家产品Neki的推广，作为技术评述存在立场偏差，读者应区分事实与产品主张。
工程实践 ClickHouse Engineering 2026/08/21
文章讨论 ClickHouse Managed Postgres 如何在同一个 VM 上隔离 Postgres 与周边支撑进程（PgBouncer、WAL-G 备份代理、各类 exporter、本地 Prometheus、日志收集器和看门狗），避免它们反过来拖垮数据库。核心是三层内存防护：Go 运行时的 GOMEMLIMIT 先触发更积极的 GC，cgroup v2 的 memory.high 触发直接回收与限流，memory.max 作为硬上限并在该 cgroup 内触发 OOM，从而把 OOM 受害者限定在支撑服务而非 Postgres。CPU 用调度权重、备份缓冲区固定比例、日志内存限制和导出指标白名单分别设卡；磁盘打满时看门狗读取 pg_stat_activity 终止普通应用会话，但豁免复制与监控用户以保持 WAL 流和可观测性。局限是偏设计说明，缺少压测与故障复盘数据。
推荐收录：文章给出了可迁移的资源隔离模型——运行时预算加 cgroup 软硬上限、资源白名单、带豁免的应急终止路径，并逐条说明每种边界存在的理由。对自建或托管 Postgres、需要把监控备份等边车进程与主库共置的 SRE 和 DBA 读者有直接参考价值。主要不足是缺少压测与故障复盘数据，结论偏经验性。
工程实践 ClickHouse Engineering 2026/08/20
文章复盘 POSETTE 2026 演讲，围绕 PostgreSQL 规模化后的五类症状（写入变慢、P95 读延迟不稳、autovacuum 落后、checkpoint 争抢 I/O、逻辑复制积压），论证根因常被误判，实际多来自存储。作者用 8 个相同 m6id.4xlarge 集群、3.3 亿行 pgbench 随机 UPDATE 负载，对比本地 NVMe 与 3000 IOPS 的 baseline gp3 EBS，结果 NVMe 中位 16,030 TPS 对 EBS 1,734 TPS（约 9.24×），事务中位延迟从 36.9ms 降到 4.0ms。延迟拆解显示差距主要来自页读取、WAL fsync 与锁/调度等待，CPU 本身耗时接近；等待事件与 CPU profile 也印证 EBS 更多进程处于离 CPU 等待。作者随后给出本地 NVMe 生产架构：quorum 双 standby 同步复制、WAL-G 持续备份至独立对象存储，并明确结论仅适用于该负载与存储配置。
推荐收录：文章给出了可复现的对照实验设置、量化指标（TPS、延迟拆解、等待事件、CPU profile）以及面向生产的架构取舍，而非单纯观点宣导或产品广告。适合运行大规模 PostgreSQL、关注存储选型与高可用设计的数据库/SRE 读者，其“数据库与存储一起诊断”的思路及 NVMe+quorum 复制+对象存储备份的组合可迁移到类似系统；但需注意基准使用 3000 IOPS 基线 gp3，不同 EBS 配置结论会变化。
工程实践 Crunchy Data Blog 2026/08/18
文章围绕 Postgres 19 的 beta 功能，回顾 Crunchy Data 多年来关于数据加载、TOAST、BRIN 索引、覆盖索引和分区管理的既有建议，并逐项说明哪些版本改变了这些建议的落点。作者指出核心原则仍成立：批量导入优先用 COPY，JSON 存 jsonb，索引是权衡，分区主要服务生命周期管理。主要变化包括 async I/O 显著加速堆扫描与 vacuum，COPY 新增 ON_ERROR 与 REJECT_LIMIT 等容错选项，LZ4 成为默认 TOAST 压缩算法，BRIN 增加 minmax_multi 与 Bloom 形状，B-tree skip scan 覆盖更多查询，以及并发 detach、merge/split 分区等新 DDL。文章给出了大量可直接使用的 SQL 示例和调参建议，并强调这些功能基于 beta，正式发布细节可能调整，升级后应结合 EXPLAIN (ANALYZE, BUFFERS, IO) 重新验证。
建议收录。它不是零散的版本新闻，而是把 Postgres 11 到 19 的功能演进与真实运维建议逐条对照，给出了从 COPY 容错、LZ4 压缩、BRIN 调优到分区在线操作的可执行路径。适合数据库管理员、后端工程师和依赖 PostgreSQL 的团队在升级前做功能核查与基准测试；文中先验证再调整的决策方式，也能迁移到其他数据库平台。注意文章内容基于 beta，部分行为需以正式版文档为准。
技术文章 ClickHouse Engineering 2026/08/18
文章梳理 PostgreSQL 19 的监控与可观测性改进：log_lock_waits 默认开启、log_min_messages 可按进程类型分级、autovacuum 与 autoanalyze 日志分离。pg_stat_wal 新增 wal_fpi_bytes 统计全页镜像字节数，并引入 CopyFromRead、CopyToWrite、WaitForWalWrite 等新等待事件。作者还解释 WAL 全页镜像为何主导 WAL 体积、multixact 膨胀如何判读，以及远程复制/FDW 消息统一格式化和回卷告警阈值提高到 1 亿的变化。文末给出面向日志解析、指标采集、等待事件字典与告警阈值的升级检查清单，但内容基于 beta 版，细节可能调整。
推荐收录，因为文章不仅罗列 PostgreSQL 19 的监控变更，还结合提交记录解释 WAL 全页镜像、multixact 膨胀等底层机制，并给出可执行的工具升级清单。适合数据库运维、SRE 与可观测性工具开发者在升级前排查兼容性风险；需注意内容基于 beta 版，最终以正式发行说明为准。
工程实践 PlanetScale Blog 2026/08/18
文章介绍了连接池被“污染”导致 Postgres 集群出现只读错误的问题。作者以一次真实线上故障为例，说明当客户端通过 PgBouncer 事务模式复用底层连接时，如果某个请求执行了 SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY 或设置 default_transaction_read_only，随后离开连接池而未重置状态，就会让后续复用到该连接的查询错误地进入只读模式，并抛出 25006 错误。文中区分了连接池中毒与数据库集群只读、只读副本等不同错误特征，并给出了立即恢复手段 DISCARD ALL、通过 pscale 排查可疑会话，以及从应用侧避免设置会话级只读、改用副本路由或严格事务超时等预防措施。内容还提到 PlanetScale 的 MCP 编排工具可辅助定位代码中修改会话状态的路径。全文兼具具体故障现象、根因分析和可操作的恢复与预防方案。
推荐收录，因为它揭示了一个常见但容易被忽视的数据库连接池陷阱，从故障现象、根因到恢复和预防都有清晰说明，且不依赖特定框架。对使用 Postgres、PgBouncer 或任何事务模式连接池的工程师，文中关于会话状态泄漏、错误码识别和 DISCARD ALL 的处置方法可以直接迁移到实际系统中。
工程实践 ClickHouse Engineering 2026/08/17
文章解释 Linux 内存 overcommit 策略为何对 Postgres 格外关键：默认策略下 OOM killer 会 SIGKILL 某个 backend，而 Postgres 只能假设共享内存段可能已损坏，于是终止所有 backend 并走崩溃恢复，等于整个实例重启。严格 overcommit（vm.overcommit_memory=2）让内核在物理内存耗尽前就以 ENOMEM 拒绝分配，Postgres 将其视为普通错误，仅报错并回滚当前事务。作者在同一台 EC2（m7i.2xlarge）上用相同 pgbench 负载对比两种策略，并给出 commit limit 的推导：先扣除预留的 huge pages，再按剩余内存的 80% 加 2GB 作为 sidecar 头寸，约为总内存的 60% 加 2GB。实验显示默认策略下 20 个旁观连接全部被断开、新连接中断约 30 秒，严格策略下仅 1 个查询失败、0 个连接受影响，且两者吞吐差异落在噪声范围内。边界是结论基于单一硬件与特定 shared_buffers、huge pages 配置。
推荐收录：文章用同一台 EC2 上默认与严格 overcommit 的对照实验，给出 CommitLimit 推导依据、OOM 杀死 backend 后的崩溃恢复日志以及 pgbench 吞吐对比，证据完整而非泛泛而谈。适合负责 Postgres/Linux 生产部署的 DBA 与 SRE，可把内存耗尽的影响从实例级重启降为单查询失败；限额计算与验证方法也可迁移到其他数据库。风险是结论依赖单一硬件与 huge pages 配置，需按实际内存布局重新核算。
技术文章 PlanetScale Blog 2026/08/17
本文介绍 PlanetScale 分布式数据库 Neki 中的数据拓扑概念。数据拓扑是一个 JSON 配置，将 PostgreSQL 逻辑表映射到物理分片，并为路由器提供查询路由所需信息。文章详细解析其三个构建块：分片索引（支持 hash、modulo、range 三种策略）、分片组（物理分片集合与路由键范围）和数据库绑定（遵循 PostgreSQL 的 database/schema/table 层级）。通过一个按 customer_id 对 customers 表分片的示例，展示了路由键如何计算并落到对应分片。文章还指出数据拓扑不管理物理分片，并在 resharding、表迁移等过程中动态更新。该文是 Neki 内部架构的说明，适用于理解分布式数据库的分片与路由设计。
推荐收录，因为文章以清晰的结构解析了数据拓扑这一分布式数据库关键机制，且来自有大规模运维经验的实际团队，配置抽象与路由策略可迁移到其他分片系统。适合数据库架构师、分布式系统开发者和对 Vitess/PostgreSQL 分片感兴趣的读者。主要风险是内容偏向 Neki 特有实现，但核心概念与分类仍有长期参考价值。
技术文章 pganalyze Blog 2026/08/13
本文是 pg_stat_statements 深度系列第六篇，聚焦高基数查询负载的诊断。作者将高基数定义为工作负载持续产生的唯一归一化查询数超过 pg_stat_statements.max 容量，导致扩展无法保留调优所需指标。文章指出唯一查询主要来自 ORM、动态 SQL、即席报表、AI 辅助工具以及 Postgres 17 及以下的变长 IN 列表。通过 Bluebox 演示，相同负载在 Postgres 17 产生 671 条唯一语句，Postgres 18 仅 120 条，验证了 IN 列表归一化的效果。文章给出五项诊断检查：了解 max 设置、观察重置后回填速度、监控释放计数器、查找缺失查询、观察 top 查询变化；并建议调整设置、升级到 Postgres 18、与开发团队协作。边界是演示基于特定工具，经验性建议需结合具体环境。
推荐收录。文章提供了可操作的五项诊断检查（如观察 pg_stat_statements_info 释放计数器、重置后回填速度），并给出 Postgres 17 与 18 的量化对比（671 vs 120 条唯一语句），帮助 DBA 和 SRE 判断监控数据是否因高基数负载而丢失。适合 PostgreSQL 运维、性能调优和可观测性建设场景，其诊断思路和工具来源分析可迁移到其他数据库监控实践。风险在于内容源于厂商博客且为经验总结，需结合自身负载验证。
工程实践 ClickHouse Engineering 2026/08/11
文章介绍 pg_clickhouse v0.10.0 的更新，重点是扩大 PostgreSQL 查询向 ClickHouse 下推的范围。作者以 TPC-H 为度量，将完全下推的查询从 22 条中的 12 条提升到 16 条；Q17 从 32.7 秒降至 37 毫秒，并快于原生 PostgreSQL 的 2.1 秒。技术核心是把相关子查询与 NOT IN 下推为半连接/反连接，同时用额外空值守卫弥合 PostgreSQL 三值逻辑与 ClickHouse 二值逻辑在 NULL 上的语义差异。工程侧还改用 clickhouse-c 重写 C 驱动，统一 HTTP 与二进制 Native 协议，修复并发扫描连接冲突，并扩展统计聚合、有序集聚合和分区聚合下推。文章明确仍剩 6 条 TPC-H 查询未下推，受限于 join tree 两侧遍历，且相关子查询要求 ClickHouse 25.8 以上，否则回退本地执行。
推荐收录：文章不仅列出 pg_clickhouse 新功能，还给出可验证的 TPC-H 性能改进（Q17 32.7s→37ms）、三值/二值逻辑差异导致的正确性陷阱及守卫实现，以及驱动层从 C++ 到 C 的架构权衡和并发修复。对使用 PostgreSQL FDW、构建异构数据库查询下推、OLAP 加速或数据库扩展开发的工程师具有直接参考价值，其语义兼容性验证思路可迁移到其他数据源集成场景。
工程实践 ClickHouse Engineering 2026/08/05
文章解释 ClickHouse Managed Postgres 为何以及如何对 Postgres 施加 WAL 写入背压。Postgres 先把所有变更写入 WAL，归档器再把完成的段上传到对象存储，未上传的段无法删除；一旦写入快于归档，WAL 会堆积直至撑满磁盘，而磁盘耗尽会触发 PANIC 导致实例宕机。系统用一个 systemd 定时器每 15 秒统计积压段数，通过 cgroup v2 I/O 控制器按 80%/50%/20% 三档限制客户端后端的写带宽，并把归档、检查点、日志等排空路径按进程名划入不受限的 immune 组。作者在单台 m7i.2xlarge、500MB/s gp3 上以限速 4MB/s 的 archive_command 做 35 分钟 pgbench 实验，验证分级限流按阈值触发、积压清零后自动解除、数据盘始终未超 33%。文中也指出一个边界：该负载写入几乎全是 WAL，限流对吞吐的削减远大于对 WAL 生成的抑制（仅约 10%），效果取决于写负载的数据密度。
推荐收录。文章把“WAL 归档跟不上会导致磁盘写满并 PANIC”这一真实运维风险，拆解为基于 cgroup v2 的分级写带宽限流方案，并给出可复现的 35 分钟压测时间线、cgroup 分类证据和限流对 WAL 生成抑制有限的明确边界。适合负责 Postgres/数据库托管、可靠性与容量控制的工程师，其中“不限制排空路径、只在数据面自我保护、按积压分级降速”的取舍可迁移到其他写入放大与异步归档场景。
工程实践 ClickHouse Engineering 2026/07/30
文章基于开源可复现的 PostgresBench 基准，用 pgbench 的类 TPC-B 短事务高并发负载，在相同 AWS r8gd 实例（本地 NVMe、一主两同步备、quorum 复制）上对比 ClickHouse Managed Postgres 与 PlanetScale Metal。结果显示 ClickHouse 在 16vCPU/128GB 与 4vCPU/32GB 两种配置下均领先：100GB 数据集吞吐高约 34%–51%，500GB 数据集高约 54%，平均延迟与 P95/P99 也更低。作者把差异归因于系统级优化，如 2MB 大页、wal_compression=lz4、按实例规模调整 max_wal_size 等，并指出 PlanetScale 暴露的配置中巨大页与 WAL 压缩关闭、max_wal_size 仅 8GB。文章也承认仍存在未通过 pg_settings 暴露的实现差异，建议用户用自己的负载做概念验证。
推荐收录，因为它提供了可复现的开源基准 PostgresBench、明确的 pgbench 命令与硬件/复制配置，并对比了两项服务可见的 Postgres 配置差异（大页、WAL 压缩、max_wal_size），这些调优要点可迁移到自建或托管 Postgres 的运维中。适合评估托管 Postgres 或做 OLTP 性能调优的读者。主要风险是它由 ClickHouse 自测、属厂商对比，具体 TPS 数字会随产品迭代过时，应结合自身负载验证。
工程实践 ClickHouse Engineering 2026/07/21
文章介绍 ClickHouse 团队开源的 PostgresBench 在加入高可用（HA）配置后的第二轮结果，对比 ClickHouse Managed Postgres、Crunchy Bridge、AWS RDS、Aurora 与 Neon 在匹配主库算力、相近持久化级别下的表现。作者把托管 Postgres 的 HA 实现分为共享无（本地存储 + PostgreSQL 流复制 + 热备节点）与共享存储（计算存储分离、提交路径写多份 WAL）两类，并以“主库故障后 2 分钟内恢复且零数据丢失”作为 HA 定义。在 16 vCPU/64 GB、500 GB 数据集、10 分钟压测下，同步复制代价明显：ClickHouse 双同步备库 TPS 降至单机 79%、p99 升至 254%，RDS Multi-AZ 集群 p99 升至 627%。结论是匹配持久化级别时 ClickHouse Managed Postgres 吞吐与延迟优于其他托管服务；但数据为厂商自测、存储后端冗余配置未公开，对 Neon 的评价带明显倾向，需谨慎解读。
推荐收录：文章给出可复现的开源基准、明确的 HA 定义（2 分钟 RTO + 零丢失）、各厂商实例配置，并用数据量化同步复制对 p99 尾延迟的放大（最高 6 倍以上），对做数据库选型与 HA 架构权衡的工程师有直接参考价值。风险在于这是厂商自测且对比自家产品的稿件，Aurora/Neon 存储冗余未公开、对 Neon 评价带倾向，建议以方法学与相对趋势为主，而非绝对排名。
技术文章 Andy Pavlo Database Blog 2026/01/04
Andy Pavlo 撰写的 2025 年数据库年度回顾，以 PostgreSQL 的持续主导为主线，梳理全年行业格局与技术动向。文中记录了 Databricks 以 10 亿美元收购 Neon、Snowflake 收购 CrunchyData、微软推出 HorizonDB 等交易，并分析 Multigres、Neki、PgDog 三个分布式分片项目对 PostgreSQL 水平扩展能力的意义。作者还评述各 DBMS 竞相推出 MCP 服务器接入 LLM/Agent 及其权限与防护风险、MongoDB 起诉 FerretDB 的专利商标纠纷，以及 FastLanes、F3、Vortex、AnyBlox 等新列式文件格式对 Parquet 的挑战。文章同时汇总全年收购、合并与融资清单，并附作者点评与历史脉络考证。其内容以行业观察与主观判断为主，并非技术教程，趋势预测带有个人立场，读者需结合原始资料核实。
推荐收录：作者为 CMU 数据库教授，该系列已成为数据库领域公认的年度权威综述，文中对 PostgreSQL 生态并购、MCP 接入 LLM 的安全隐患、列式文件格式竞争给出了有据可查的事实与判断。适合数据库工程师、架构师与研究者快速建立年度技术脉络，可作为长期索引；但内容偏向行业观察与个人观点，具体机制仍需回到原始资料与论文核实。
技术文章 Andy Pavlo Database Blog 2023/06/07
文章围绕 PostgreSQL 的 MVCC 实现，系统讨论版本复制、表膨胀、二级索引维护和 vacuum 管理四类问题及优化手段。作者指出，更新复制整行、死元组与活元组同页存储、索引写放大以及 autovacuum 配置复杂，会带来存储浪费、I/O 升高和查询变慢，其中版本复制不重写内核难以根治。优化上建议用 pgstattuple 或估算脚本监控膨胀，用 pg_repack 在线回收空间，通过 pg_stat_all_indexes 清理重复和未使用索引；vacuum 方面则需表级调小 autovacuum_vacuum_scale_factor、监控长事务与进度，并调优 work_mem、cost_limit、cost_delay。文章结论是 PostgreSQL 虽有问题仍值得坚持，但优化高度依赖人工判断，pg_repack 和杀事务等操作需在低峰并评估业务风险。
推荐收录，因为文章由数据库研究者撰写，针对 PostgreSQL MVCC 的版本复制、膨胀、索引维护和 vacuum 四个具体问题，给出了 pgstattuple、pg_repack、pg_stat_* 视图与 autovacuum 参数的诊断/调优路径，技术证据明确。适合 DBA、后端工程师和数据库系统研究者用于生产运维、容量规划和 MVCC 权衡；但部分操作需低峰执行并评估杀事务风险，且文中含 OtterTune 产品推广。
技术文章 Andy Pavlo Database Blog 2023/04/26
文章由 Andy Pavlo 与 Bohan Zhang 合作，系统批评 PostgreSQL 的 MVCC 实现。核心指出 PostgreSQL 采用 append-only 版本存储、O2N 版本链和每版本索引项，导致版本复制、表膨胀、二级索引写放大和 autovacuum 管理困难四大问题。作者对比 MySQL、Oracle 使用 delta 存储与逻辑指针的做法，说明 PostgreSQL 设计是 1980 年代遗留方案，不推荐新 DBMS 效仿。文中引用 CMU 研究与 OtterTune 客户监控数据，包括 Uber 从 Postgres 迁移 MySQL 的案例，但结论更偏向写密集负载，并非完整中立的 benchmark。
推荐收录：文章以存储布局、版本链、索引维护和 autovacuum 行为等具体机制，直接说明 PostgreSQL append-only MVCC 的性能代价，并给出与 MySQL/Oracle 的对照证据。适合数据库内核、DBA、后端架构师和云数据库选型者阅读，可迁移到 MVCC 设计、写放大评估、索引优化和 vacuum 调优场景；需注意其结论偏向写密集工作负载。