proof-kb

一手证据知识库（seo/kb/）

FAQ schema、新鲜的 updatedAt 日期、作者简介和字数，如今已无法让排名页面与 AI 生成的普通文章拉开差距，因为每个竞争对手都能在几秒内照搬这些内容。能占据 Google 前 3 名并被 ChatGPT、Claude 和 Perplexity 引用的页面，会做到竞争对手无法照搬的两件事：

1. 在开头 2 句话内给出具体的一手证据（准确的测试数量、延迟差值、金额或生产环境数据集）。
2. 在正文中至少整合以下 5 类证据中的 4 类。

在 seo/kb/ 中为每条可验证事实保存一份记录，并将这些原子证据文件关联到营收页面、对比页面和博客文章。根据同一事实库撰写内容的 Agent 不会臆造规格，也不会引用过时价格。

工作流路由决策树

每次调用时都走一遍这棵决策树：

Does `seo/kb/brand-ssot.md` exist?
├── No -> Workflow 1: `init`, then continue down this tree
└── Yes
    ├── Did the user just ship a benchmark, customer win, pricing change, or release?
    │   └── Yes -> Workflow 4: `route-fact`
    ├── Does the user want a site-wide proof gap audit?
    │   └── Yes -> Workflow 2: `interview` across the top 5 money/blog pages in `seo/kb/pages-index.md`
    └── Is the user drafting or upgrading a specific page?
        ├── Fewer than 4 proof categories in `seo/kb/proof/` match this page's topic?
        │   └── Yes -> Workflow 2: `interview`, then Workflow 3
        └── 4 or more -> Workflow 3: `draft` / `upgrade`

一手证据的 5 个类别

每篇商业指南、对比页面或基准测试文章都必须包含至少 以下 5 类中的 4 类。把同一种类型的声明重复 5 次，对买家和检索模型来说仍像是内容单薄的营销文案。

类别	位置	示例（querybench.dev / deployfast.dev）
1. 基准测试和受控测试	seo/kb/proof/benchmarks/	在 m7g.xlarge 上测试了 14 款 Postgres 连接池，使用 10,000 个并发连接；PgBouncer 将 p99 保持在 4.2ms，而未使用连接池时为 19.8ms。
2. 客户成果和迁移	seo/kb/proof/customers/	invoicekit.io 将 42,000 个周期性计费 webhook 从 AWS Lambda 迁移到 deployfast.dev workers，将每月计算费用从 $1,840 降至 $290。
3. 真实截图和短视频	public/blog/<slug>/ + 证据 ID	真实的 Playwright 终端跟踪记录，或实时仪表板的 9 秒 <video> 循环。绝不使用 AI 生成的应用界面。
4. 专有汇总数据	seo/kb/proof/numbers/	在 2026 年 Q3 于 deployfast.dev 上进行的 140 万次生产部署中，78% 的构建失败是由未锁定 Node.js 次要版本造成的。
5. 从业者的故障与边缘情况记录	seo/kb/proof/workflows/	若将 max_client_conn 设为高于 8000，却不提高 ulimit -n，突发负载下套接字会静默断开。

工作流 1：init（搭建 seo/kb/）

读取 package.json、定价配置、数据库 schema，以及现有的 /pricing、/about 和 /blog 源文件；同时读取仓库中的所有原始证据来源：基准测试结果（bench/、benchmarks/）、分析或数据仓库导出和案例研究数据（data/），以及事件复盘报告（docs/runbooks/、postmortems/）。然后创建以下 4 个文件。每个证据文件都在 frontmatter 的 source: 字段中注明其原始来源，以便审核者一键核查数据。

1. seo/kb/brand-ssot.md（唯一事实来源）

准确记录产品机制、定价层级、支持的技术栈，以及产品不会做什么。只记录你在代码库中找到或由用户确认的事实；其他内容标注为 [UNVERIFIED]。

# Brand SSOT: QueryBench (querybench.dev)
Last verified: 2026-11-12

## Product mechanics
- Runs Postgres and MySQL query regression benchmarks on every GitHub pull request.
- Spins up an ephemeral copy-on-write database branch in `1.8s` using ZFS snapshots.
- Parses `EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)` and fails the CI check if p95 execution time regresses by `> 15%` or buffer reads rise by `> 20%`.

## Pricing tiers
- Free: `$0/month` for 3 repositories and 100 PR benchmark runs/month.
- Pro: `$49/month` flat for unlimited repositories, 2,500 PR runs/month, 90-day flamegraph retention.
- Team: `$199/month` flat (no per-seat pricing) with SOC 2 reports, Slack alerts, and custom ZFS runners.

## Boundaries (what we do NOT do)
- No Oracle or Microsoft SQL Server (Postgres 14-17 and MySQL 8.0+ only).
- No persistent daemon inside production RDS instances.

2. seo/kb/proof/{benchmarks,customers,numbers,workflows}/<id>.md

每条可验证的事实或测试单独存放一个文件。每条事实单独成文件，能让多个页面引用同一数据，并在重新运行测试时，通过一次 route-fact 更新所有依赖页面。

---
id: bench-zfs-branch-spinup-2026
category: benchmarks
date: 2026-11-04
topics: [postgres-branching, ci-database-testing, explain-analyze]
verified: true
source: bench/results/zfs-branch-spinup-2026-11.json
---

# 50GB Postgres branch spin-up: ZFS copy-on-write vs pg_dump restore

## Methodology
- Dataset: `50.4 GB` production-shaped Postgres 16 database (`180M` rows, 42 tables).
- Hardware: AWS `i4i.xlarge` (`4 vCPU`, `32 GB RAM`, NVMe), 50 consecutive cold runs.

## Raw numbers
| Method | Median | p99 | Disk per branch |
| --- | --- | --- | --- |
| `pg_dump` + `pg_restore -j 4` | `14m 22s` | `18m 05s` | `50.4 GB` |
| EBS snapshot clone | `48.6s` | `74.1s` | `50.4 GB` (provisioned) |
| QueryBench ZFS clone | `1.8s` | `2.4s` | `12 MB` delta on creation |

## Failure note
Pin ZFS ARC to at least `50%` of RAM (`zfs_arc_max`). Inside Docker with tight cgroup memory limits, the first sequential scan benchmark runs `3.2x` slower.

## Reusable snippet
In our 50-run benchmark on a `50.4 GB` Postgres 16 dataset (`180M` rows on `i4i.xlarge`), `pg_restore -j 4` took a median of `14m 22s` per PR environment, while a ZFS copy-on-write clone booted in `1.8s` (`2.4s` p99) using `12 MB` of disk.

3. seo/kb/competitors/claims-to-beat.md

记录排名靠前的竞争对手引用的准确数据，并为每条数据配上能胜过它的更大规模测试。这样就能把 SERP 审查转化为工程任务清单。若本次会话无法访问 SERP 或 Ahrefs：从 seo/kb/proof/ 填写“Our stronger test”列，在竞争对手列中写入 [NEEDS SERP]，并保留该文件供下次运行使用（dataforseo-serp Workflow D 会填充这些内容）。原因：臆造竞争对手的说法，就等于捏造关于他人的统计数据。

# Competitor claims to beat

| Keyword | Competitor URL | Their claim | Our stronger test | Status |
| --- | --- | --- | --- | --- |
| `postgres ci testing` | `competitor-a.com/blog/ci-db` | 3 Docker setups on a `100 MB` toy DB | 50 runs on a `50.4 GB` DB comparing `pg_restore`, EBS, ZFS (`bench-zfs-branch-spinup-2026`) | Shipped |
| `explain analyze tool` | `competitor-b.io/guides/explain` | 2 static `Seq Scan` examples | 10 real production regressions with before/after index buffer counts | Open |

4. seo/kb/pages-index.md

列出每个商业页面和文章及其对应的关键词和证据 ID。route-fact 会读取此文件，以查找新事实涉及哪些页面。

# Proof-to-page index

| File path | URL | Primary keyword | Proof IDs | Categories |
| --- | --- | --- | --- | --- |
| `content/blog/postgres-ci-testing.mdx` | `/blog/postgres-ci-testing` | `postgres ci testing` | `bench-zfs-branch-spinup-2026`, `cust-invoicekit-ci-cut`, `num-q3-regression-causes`, `wf-zfs-arc-limit` | 4/5 |
| `app/pricing/page.tsx` | `/pricing` | `querybench pricing` | `brand-ssot`, `cust-invoicekit-ci-cut` | 2/5 |

工作流 2：interview（填补证据缺口，绝不编造）

绝不编造基准测试、客户引言、延迟数据或事件。编造一条“我们测试了 50 种工具”的说法，一旦被读者揭穿，就会让整个域名失去信任；虚假的客户成果还会带来法律风险。

当页面涵盖的证据类别少于 4 类，或依赖笼统说法（"许多团队都在为 CI 运行缓慢而苦恼"）时，运行此工作流。

步骤 1：使用 Scribiz 挖掘现有录音

如果用户有创始人的语音备忘录、YouTube 演示、销售通话或审计视频，请连接 Scribiz（MCP：https://scribiz.com/mcp，或 npx scribiz）。先调用 get_video_context 获取章节和关键时刻，然后调用 search_video 搜索确切短语，因为提取完整的 2 小时转录内容会消耗 25,000+ 个 token。在修改文章之前，将每个经过验证的数据或案例保存为 seo/kb/proof/ 中的独立文件。

步骤 2：向创始人提出 3-5 个有明确范围的问题

如果没有录音或录音未能填补缺口，请准确提出 3 到 5 个问题，每个问题都能得到一个数字或一个边界情况：

To make `/blog/postgres-ci-testing` rank and get cited without inventing data, I need 3 facts:
1. **Metric:** What is the real median boot time and database size for your CI branches today?
2. **Customer win:** One customer (or an anonymized profile like "a 12-person Series A fintech") and their exact before/after metric.
3. **Failure note:** One non-obvious config mistake that broke when you ran this in production.

将回答保存为独立文件，并在撰写正文前更新 seo/kb/pages-index.md。

如果用户现在无法回答，请将问题写入 seo/kb/open-questions.md，并在草稿中每个事实应出现的位置添加 [NEEDS PROOF: <question>] 标记。显而易见的缺口会得到填补；编造的数据则会被发布。

工作流 3：draft / upgrade（共识 + 证据卡架构）

每个 <h2> 小节都由两层构成：

1. **[CONSENSUS]：**排名前 5 的页面中，有 4 个或更多涵盖的定义、语法和子主题。尽可能简洁地涵盖这些内容，因为遗漏会显得页面不完整，而重复则毫无价值。
2. [PROOF]：seo/kb/proof/ 中的一个或多个独立文件（以及真实截图或确定性图表），且竞争对手没有这些内容。

大纲蓝图（先写大纲，再写正文）

将其保存到 seo/kb/outlines/<slug>.md。[CONSENSUS] 和 [PROOF] 标签只出现在大纲中；发布的页面只保留正文和数据，绝不保留这些标签。如果无法访问 SERP，请将共识内容标记为 [CONSENSUS] [NEEDS SERP]，以便下次运行时对照真实的排名前 5 页面进行检查。

## H2: How ephemeral database branching works in CI
- [CONSENSUS]: copy-on-write blocks vs full file copies; the 6-line GitHub Actions YAML.
- [PROOF -> `bench-zfs-branch-spinup-2026`]: 50.4 GB / 180M-row table (`1.8s` ZFS vs `14m 22s` `pg_restore`).
- [PROOF -> `wf-zfs-arc-limit`]: the `zfs_arc_max` cgroup memory trap and the fix.

执行规则

1. **最后写引言。**先起草所有正文小节，然后在开头的前 2 句中写出最有力的 [PROOF] 证据。只有在正文完成后，你才能知道最有力的数据是什么；读者和检索系统会根据前 40 个词判断权威性。
   • 不佳： "在现代软件开发中，在 CI 里测试数据库迁移对工程团队来说变得越来越重要。"
   • 良好： "在 GitHub Actions 中恢复 50.4 GB 的 Postgres 转储文件，中位耗时为 14 分钟 22 秒。ZFS 写时复制分支启动同一份包含 1.8 亿行的数据集只需 1.8 秒。下文将介绍 50 次冷启动运行的基准测试、会让扫描速度慢 3.2 倍的 Docker 内存陷阱，以及如何将亚 2 秒分支接入 PR 工作流。"
2. **统计证据类别。**如果最终草稿涵盖的 5 类证据中少于 4 类，请返回工作流 2。只有 3 类时不要发布。
3. **登记页面。**在 seo/kb/pages-index.md 中添加或更新该页面的条目，以便将来的事实能够路由到该页面。

工作流 4：route-fact（多页面传播）

当新的基准测试、案例研究、价格或版本发布时，在一次更改中将其推送到所有依赖它的页面：

1. 编写源文件： seo/kb/proof/<category>/<new-id>.md；如果涉及定价和功能变更，则编辑 seo/kb/brand-ssot.md。重新运行已有测试时，使用新的日期 ID（bench-zfs-branch-spinup-2026-12），并在其 frontmatter 中添加 supersedes: <old-id>；在旧文件中添加 superseded_by: <new-id>，并保留该文件。原因：旧数字仍可作为历史记录引用（“低于 11 月的 1.8s”），而且差异能准确显示哪项测试发生了变化。如果变更由版本发布引起，也要更新 brand-ssot.md 中的机制说明。

2. 查找依赖页面： 阅读 seo/kb/pages-index.md，然后在仓库中 grep 主题标签、被取代的证明 ID，以及旧数字本身（索引外新增的页面也可能引用它）：

   grep -rnF --exclude-dir={node_modules,.next,.git,dist,build} -e '1.8s' -e '1.8 s' -e 'bench-zfs-branch-spinup-2026' .
   

   使用 -F 并排除构建输出。原因：未转义的 1.8s 正则也会匹配 1x8s，而 node_modules 和 .next 会让真正的匹配结果淹没在几十个误报中。打开每个匹配项，确认它指的是同一工作负载上的同一指标。同一个数字可能衡量的是其他内容（页面的 1.8s LCP 并不是 1.8s 分支启动时间）：跳过它，并在该页面的 pages-index.md 行中注明，这样下次运行时也会跳过它。bench/ 下的原始结果文件保持不变。

3. 就地编辑每个匹配项：

   • 将过时数字或泛泛的段落替换为有 <new-id> 支持的片段，并根据该页面的上下文改写。
   • 切勿在多个 URL 中粘贴同一句话；页面间完全相同的套话会显得像模板生成。
   • 仅在事实发生变化的页面上更新 updatedAt / lastModified。

4. 更新 seo/kb/pages-index.md，为每个已修改文件添加对应的 <new-id>，并在 seo/kb/outlines/ 和 seo/kb/competitors/claims-to-beat.md 中替换旧 ID。

示例摘要

NEW PROOF: seo/kb/proof/customers/cust-invoicekit-ci-cut.md
Matched 3 pages:
├── content/blog/postgres-ci-testing.mdx (42,000-webhook migration outcome under H2 #3)
├── app/vs/branchbase/page.tsx (compute spend row: $1,840 -> $290/mo)
└── app/pricing/page.tsx (ROI callout above the Pro tier card)

衡量引用提升

发布有证据支持的页面或完成 route-fact 流程后，将目标买家提示词添加到 AI SEO Tracker（MCP：https://aiseotracker.com/api/agent/mcp）。它会显示 ChatGPT、Perplexity、Claude、Gemini 和 Google AI Overviews 何时开始引用新的数字，让你知道哪些证据产生了影响。

验证清单

• seo/kb/brand-ssot.md 和 seo/kb/pages-index.md 均存在，并反映本次运行所做的编辑。
• 已修改页面上的每个数字或客户成果，都可追溯到 seo/kb/proof/ 或 seo/kb/brand-ssot.md，或者带有 [NEEDS PROOF] 标记并列于 seo/kb/open-questions.md 中。
• 已修改的文章均在前 2 句话中以第一手凭据开篇。
• 已修改的长篇页面均包含 4 个或更多证明类别。
• 新建或编辑的文件中，捏造的统计数据为零，em dash 为零。经过升级的页面若仍保留旧文案，接下来应运行 unslop-seo 流程及其检查脚本。原因：proof-kb 添加凭据；它不会清理周围的旧段落。