PostgreSQL

背景 一个 Go 1.21 + pgx v5.5 的订单写入服务，K8s 部署 6 副本（每副本 4C8G），下游 PostgreSQL 15.4（16C64G，NVMe），中间套了一层 PgBouncer 1.21（transaction

先说结论：我见过绝大多数团队的索引数量是"长"出来的，不是"算"出来的。加的时候有理由，减的时候没流程。而写放大的代价是隐性的、持续的、累积的——你永远不会收到一条"你的第 7 个二级索引今天又让 INSERT 慢了 0.3ms"的告警，但

一、现象与背景 一台 PostgreSQL 15.4 实例（32C 128G，NVMe SSD 2TB，"shared_buffers=48GB"），承载两个业务： - 在线查询服务：HikariCP "maximumPoolSize=64

【背景】 我在做一条金融级实时风控事件流管道：Kafka → 自研消费服务（JDK 17 + Spring Boot 3.2 + HikariCP 5.1）→ PostgreSQL 15（单主库，32C128G，NVMe SSD）。写入端

【背景】 我负责一个多租户 SaaS 的数据分析查询服务：JDK 17 + Spring Boot 3 + PostgreSQL 15（单主库，16C64G）+ PgBouncer（transaction 模式，pool_size=20/租

背景 做了 5 年大数据平台，我见过太多团队在"要不要把半结构化数据塞进 JSON 字段"这件事上反复横跳。尤其是 MySQL 5.7+ 有了原生 JSON 类型、PostgreSQL 有 JSONB + GIN 索引之后，这个选项从"忍一

一、现象与背景：同一个 bug，今天能复现明天就不行 先摆数字。2024 年 Q3，我们团队（8 人，负责一条支付清算链路）的夜间回归套件是 860 个接口用例，跑在 3 人共享的 "staging" 环境上。三个月里： - 回归失败率长期