PostgreSQL 子事务缓存溢出：一个事务拖垮整个集群
PostgreSQL 一个事务积累超过 64 个子事务会导致整个集群性能暴跌，新只读副本也无法接受查询。实测 TPS 从 7200 骤降至 160，根因是子事务缓存溢出后所有查询都需要额外 SLRU 查找并产生锁竞争。新副本遇到溢出 RUNNING_XACTS 记录时会进入 STANDBY_SNAPSHOT_PENDING 状态，无法提供读流量。建议保持事务简短，监控最老运行事务。 
Planetscale
PlanetScale，全球最快、最具扩展能力的云数据库平台，基于 Vitess 与 PostgreSQL 构建，适用于现代高增长应用。
评论
点赞
收藏并发与吞吐：为什么更多并行会让数据库变慢
PlanetScale 的 MySQL 数据库因一个长事务卡住导致 16 分钟雪崩，错误峰值 1400 次/分钟，吞吐量跌至 1/10。根因不是锁竞争，而是 InnoDB 同时处理上万条快照读时版本链膨胀，使每请求成本随并发数平方增长。修复方案是将 Vitess 事务池从 10000 降回约 1000，并把满池时的报错改为排队等待。调整后峰值 26000 请求/秒涌入，错误为零，QPS 稳定在 6 万。 
大规模并行 Postgres 备份
PlanetScale 用大规模并行方式将分片 Postgres 数据库备份到 S3，8 个分片并行可在约 2.8 小时内完成原本需 22 小时的 32TB 数据库备份，峰值速率超过 50 GB/s。 
Postgres 备份机制深度解析：从 pg_dump 到连续归档的原理与工程实践
PlanetScale 详解 PostgreSQL 三种备份方式（逻辑备份、文件系统备份、连续归档），重点剖析 WAL 原理、事务回绕风险及大规模集群下的恢复策略。文章包含真实生产场景中的技术决策依据，如 pg_dump 在 30TB+ 数据库上可能触发只读模式、全页写入（FPW）如何修复“涂抹”数据、以及基于 LSN 的时间点恢复实现细节。 
PostgreSQL 19 新特性：在线表重组入核、JIT 默认关闭与查询优化增强
Postgres 19 Beta 2 发布，GA 预计 9-10 月。核心亮点：1. REPACK 命令入核，支持在线（CONCURRENTLY）重写表以收缩膨胀空间，替代 pg_repack，但需注意锁升级死锁风险和 MVCC 一致性限制；2. JIT 默认关闭，避免短查询因估算偏差承担编译开销；3. 查询优化器引入 eager aggregation 和 NOT IN 反连接优化，新增 pg_plan_advice 用于锁定执行计划。此外 lz4 成为 TOAST 默认压缩算法，并行 autovacuum 等新特性也值得关注。
如何让 768 台服务器看起来像 1 台
PlanetScale 分享将 768 台服务器组成的 Petabyte 级 Postgres 集群伪装成单节点的工程实践。文章深入剖析了从垂直扩展、只读副本到分片（Sharding）的演进瓶颈，重点讲解 Proxy 层如何通过路由、连接池和查询重写屏蔽底层复杂性。虽然带有 Neki/Vitess 推广色彩，但其关于写入瓶颈、备份延迟及分布式路由的具体技术细节，对处理大规模数据库架构的工程师具有极高的参考价值。 
数据库分片详解：原理、策略与工程实践
详解数据库分片（Sharding）原理与实战策略，涵盖范围分片、哈希分片的优劣对比，以及跨分片查询、数据一致性、延迟和数据持久性等关键工程考量。适合需要处理海量数据扩展的工程师参考架构设计。
死锁与停机：PostgreSQL的高频陷阱与防御策略
PostgreSQL死锁不仅导致事务报错，高频死锁还会引发重试风暴拖垮数据库。核心解法包括：保持事务内加锁顺序一致、缩短事务窗口、查询增加退避与抖动重试。PlanetScale还推出了Traffic Control功能，通过限制并发资源来主动拦截高风险查询，从数据库层面预防死锁雪崩。
Kubernetes 背后的反馈循环机制解析
PlanetScale 工程师从控制理论视角深度解析 Kubernetes Operator 机制。文章通过手动搭建 Postgres 集群的实战案例，逐步引出“期望状态”与“实际状态”的差异，解释了为何 Kubernetes 采用边缘触发通知配合电平触发逻辑的设计哲学。内容兼具工程实操细节与底层原理洞察，适合对分布式系统和云原生架构感兴趣的开发者。 
Postgres中唯一可扩展的删除方式是DROP TABLE
文章指出Postgres中大规模DELETE操作因MVCC机制会产生大量死元组和复制开销，建议通过表分区或DROP/TRUNCATE来替代批量删除。文中提供了具体的工程实践方案，如利用事务性DDL进行数据清洗，适合DBA和后端工程师参考。
极致容错的底层逻辑：PlanetScale 架构实践
PlanetScale 工程师详解其数据库架构的高容错设计原则，包括隔离性、冗余和静态稳定性。文章深入剖析了控制面与数据面的架构差异，以及故障转移、同步复制和渐进式发布等具体工程实践，展示了如何在云环境中构建极致的可靠性。 
如何避免在基准测试中犯低级错误
PlanetScale 工程师总结数据库基准测试的最佳实践，涵盖客户端延迟、资源匹配、工作负载模型（均匀与 Zipfian）、开环与闭环测试、吞吐量与延迟指标、预热、配置调优及一致性检查，强调避免常见陷阱和确保可复现性。 
你大概率不需要行级安全（RLS）
PlanetScale作者深入剖析PostgreSQL RLS在生产环境中的陷阱，包括与PgBouncer连接池的兼容性问题、性能损耗、攻击面扩大及维护复杂度。文章通过基准测试和代码示例论证，应用层鉴权比数据库层RLS更可控、高效且易于维护，适合对架构选型有深度需求的开发者。
限流器解剖学第三部分：客户端身份与优先级策略
本文是限流器系列文章的第三部分，深入探讨了限流客户端的身份识别、优先级排序机制以及豁免策略的风险与适用场景。作者通过具体案例分析了如何在保证系统稳定性的同时，对不同类别的任务进行细粒度的资源控制，并对比了合作模式与强制代理模式的优劣。
PostgreSQL 多租户架构方案解析与最佳实践
PlanetScale 发布关于 PostgreSQL 多租户架构的深度指南，对比了共享 Schema、独立 Schema 和独立数据库三种方案。文章明确推荐共享 Schema 模式，详细阐述了其实现细节、索引优化、分区策略及数据生命周期管理，并指出了其他两种方案在扩展性和运维上的局限性，适合后端架构师参考。 
B树与数据库索引：为什么UUID可能是个糟糕的主键选择
PlanetScale 工程师详解 B+树在 MySQL InnoDB 中的实现原理，重点对比了自增整数主键与 UUID 主键在插入性能、磁盘 I/O 和索引深度上的差异，并通过交互式动画直观展示数据分布对查询效率的影响。 
保持PostgreSQL队列健康：解决死元组堆积与自动清理困境
深入分析PostgreSQL中Job Queue导致表膨胀和性能下降的根本原因（MVCC Horizon与Autovacuum滞后），并通过重现经典故障场景，探讨了从超时配置到数据库流量控制的解决方案。 
Postgres内存占用高其实是好事
文章指出Postgres高内存占用通常是健康的表现，因为操作系统和数据库本身会利用空闲RAM作为缓存以减少磁盘IO。作者区分了可回收的Cache内存和可能导致OOM风险的RSS内存，强调不应仅因内存使用率高而恐慌，而应关注RSS增长和CPU负载。 
PlanetScale 发布数据库流量控制功能
PlanetScale 推出 Postgres 数据库流量控制功能，允许用户针对特定查询模式、应用名称或标签设置资源预算和限制，以应对突发流量或恶意查询，保护数据库性能。
深度解析：数据库流量控制是如何工作的
PlanetScale 深入解析其新推出的数据库流量控制功能。文章详细阐述了如何利用 Postgres 扩展钩子（Hooks）在查询执行前进行拦截，通过动态校准查询计划器成本与实际资源消耗的比例来预测开销，并采用反向漏桶算法管理并发与累计资源预算。同时介绍了基于 O(1) 复杂度的规则集匹配机制及通过配置文件实现秒级规则生效的工程细节。
用 Postgres 实现视频会议
作者基于PlanetScale的Postgres实例，利用逻辑复制功能实现了一个视频通话原型。文章详细解析了将音视频帧存入数据库并通过WAL流实时同步的技术细节，对比了LISTEN/NOTIFY和Unlogged表的局限性，最终结论是不建议生产使用，但展示了Postgres作为实时后端的潜力。 