database · E1 预消化简报(2026-08-29)
实例：Jay | 时间：2026-08-29 20:20 (Asia/Shanghai) | 轮次：R-53 E1 预消化 | 主题：database
📋 检查范围
工作队列：/shared/research-kb/organized/queue/work-queue.md ✅ 已读
活文档：/shared/research-kb/knowledge/database.md ❌ 不存在（R-52/R-51/R-50 均注明"已知"但文件实际未创建）
inbox 来源（近 2 天，database 相关过滤）：
| 来源 | 文件 | database 相关内容 |
|---|---|---|
| jay | 2026-08-29T1505-jay-five-category-briefing.md |
🆕 D1: pgvector 0.7.0 量化变体 + AWS Aurora 50M 向量基准 vs Qdrant + 🆕 D2: 2026 向量数据库选型决策树更新（含 pgvectorscale 阈值变化） |
| jay | 2026-08-29-engineering-e1prep.md |
Qdrant vs pgvector vs Pinecone 2026 Q1 量化基准对比（多源交叉验证）+ pgvector HNSW 性能数据 |
| jay | 2026-08-29T2100-jay-evening-inference-stack-substack-acm-survey-2026.md |
MAX 推理引擎（非 database 主轴）；无 database 实质增量 |
| jay | 2026-08-28-database-e1prep.md |
R-52 基准：pgvector 0.8 特性（Iterative Scan / 并行 HNSW / halfvec）+ 2026 Tier 框架 + Percona MySQL + Pigsty/OpenEverest + LMCache |
| jay | 2026-08-29-ai-engineering-backend-deployment.md |
🆕 CSDN 向量数据库选型（Qdrant/Milvus/pgvector，CSDN/DeepSeek）+ 🆕 InfoQ Relyt-V 内核（Relaxed Monotonicity / CBO 优化器 / 无锁并发） |
| jay | 2026-08-29-1140-news-x-tech-radar.md |
无 database 实质增量 |
| jay | 2026-08-28-1140-news-x-tech-radar.md |
无 database 实质增量 |
| jay | 2026-08-28_engineering-friday.md |
Percona MySQL 8.4.11-11 / Pigsty / OpenEverest v2（已见 R-52） |
| jay | 2026-08-28T1950-jay-engineering-filter.md |
LMCache KV connector（已见 R-52） |
| jay | 2026-08-28T1735-jay-evening-research-briefing-llm-inference-agent-stack-vecdb.md |
pgvector 2026 生产部署重申；FalkorDB 图数据库；vecdb benchmark（已见 R-52） |
| tom | 2026-08-29-rag-e1prep.md |
无 database 主轴净增；RAG-adjacent（CritICL 2608.27455） |
| tom | 2026-08-28-rag-e1prep.md |
RAG 主轴；db-adjacent |
| tom | 2026-08-28-inference-e1prep.md |
无 database 实质增量 |
| flyp | 2026-08-29-risk-e1prep.md |
无 database 实质增量 |
| flyp | 2026-08-28-coding-agents-e1prep.md |
无 database 实质增量 |
| spark | 2026-08-29-agent-e1prep.md |
无 database 实质增量 |
| spark | 2026-08-28-llm-infra-e1prep.md |
无 database 实质增量 |
| stephen | 2026-08-29-ai-industry-e1prep.md |
无 database 实质增量 |
| stephen | 2026-08-29-1245-stephen-coordination-check-noon.md |
无 database 实质增量 |
| tom/flyp/spark/stephen 其余 inbox | 近 2 天均无 database 实质净增 | — |
paper_cards 近 3 天新卡（2026-08-26 后建卡，database 主分类过滤）：
| ID | arXiv | 标题 | 主分类 | 邻接关系 |
|---|---|---|---|---|
| — | 2608.19269 | What Does an Evaluation License?（Inspect Evals） | llm-infra | 非 database |
| — | 2608.23943 | Luce（3D Gaussian） | multimodal | 非 database |
| — | 2608.11367 | Gaze Target Estimation | multimodal | 非 database |
| — | 2608.16328 | GRNEdit（Video Editing） | multimodal | 非 database |
| 其余近 3 天新卡 | — | agent/evaluation/llm-infra/engineering 主轴 | 均无 database 主分类 | 均已归档至各自主分类 |
database 主分类 paper_cards 近 3 天新卡：0 张净增。
📊 增量判定
结论：3 条主轴新增 + 0 条邻接参考，database 主轴今日以向量数据库量化基准为主增量。
R-52（2026-08-28 20:20）已归档 pgvector 0.8 特性（Iterative Scan / 并行 HNSW / halfvec）+ 2026 Tier 框架 + Percona MySQL 8.4.11-11 + Pigsty/OpenEverest。今日（2026-08-29）database 主轴有 pgvector 0.7.0 量化变体（Aurora 实测）、选型决策树更新（pgvectorscale 阈值扩展）、Qdrant vs pgvector vs Pinecone 2026 Q1 基准量化（CSDN/InfoQ 补充）共 3 条增量。
🔍 增量条目详情
🟡 增量 1（主轴新增）· pgvector 0.7.0 量化变体 + AWS Aurora 50M 向量基准对比 Qdrant
来源：jay/2026-08-29T1505-jay-five-category-briefing.md（§D1）
原始来源：AWS / Instaclustr 2026 基准测试
发布时间：2026 年
可信度：⭐⭐⭐⭐（AWS Aurora 官方实测，r7gd.16xlarge + r7i.16xlarge + PostgreSQL 16.2，64 parallel workers）
核心内容：
-
pgvector 0.7.0 新量化变体： -
scalar float16：2-byte float 量化，存储减少 50%，召回率略有下降但 p99 延迟改善 -binary quantization：二值化向量，极低成本存储，适合"先粗筛后精排"两阶段架构 - 与 pgvector 0.4.1 对比：HNSW 索引构建时间减少，IVFFlat 召回率提升 -
AWS Aurora pgvector 50M 向量 @ 90% recall 实测： - 测试环境：两台 r7gd.16xlarge（local NVMe）+ r7i.16xlarge（gp3），PostgreSQL 16.2，64 parallel workers - Aurora pgvector（HNSW m=16, ef_construction=64）50M 向量 90% recall 性能对比 Qdrant - Qdrant 对比数据（alphacorp.ai）：p50 4.74ms / p99 5.79ms @ 50M 向量
-
pgvectorscale 影响：StreamingDiskANN + pgvector 0.7.0 scalar/binary quantization 组合使 10M-100M 向量均可使用 pgvector，而无需迁移至专用向量数据库
关键生产结论： - <10M 向量 + 已有 Postgres → pgvector HNSW（零新增服务，够用） - 10M-100M 向量 → pgvector 0.7.0 + pgvectorscale（scalar/binary quantization 组合缩小差距） - >100M 向量 → 专用向量数据库（Qdrant/Milvus）
与活文档现有脉络的关系：
- R-52 §增量 1（pgvector 0.8 Iterative Scan）——pgvector 0.7.0 scalar/binary quantization 是同一版本演进线的不同维度：Iterative Scan 解决"filter+向量混合查询截断"问题，scalar/binary quantization 解决"存储成本+召回率权衡"问题——两者互补，构成 pgvector 2026 完整生产图谱
- R-52 §邻接 A（2026 VectorDB Tier 框架）——Aurora 50M 基准数据直接支撑 Tier 框架中"pgvector 10M-100M 可用性"的量化依据；pgvector 0.7.0 + pgvectorscale 将"10M 迁移临界点"向上推移至"100M"
- R-52 §增量 1（pgvector 0.8 选型结论）——选型结论更新：pgvector 0.8 确认 ACID+向量一体化路线；pgvector 0.7.0 提供具体的量化存储方案（scalar/binary）
- 活文档不存在（
/shared/research-kb/knowledge/database.md尚未创建）——pgvector 0.7.0 量化变体 + Aurora 50M 基准应作为向量数据库选型章节的核心量化条目
建议归入：向量数据库选型决策树五元矩阵 + §2.1 主流向量数据库生态 pgvector/pgvectorscale 演进方向；★ 高档（2026 选型直接参考，Aurora 生产数据）
🟡 增量 2（主轴新增）· 2026 向量数据库选型决策树更新——pgvector 0.7.0/pgvectorscale 改变 10M-100M 阈值
来源：jay/2026-08-29T1505-jay-five-category-briefing.md（§D2）
原始来源：firecrawl.dev / alphacorp.ai / kunalganglani.com 多源综合
发布时间：2026-08 月度更新
可信度：⭐⭐⭐⭐（多源独立评测一致：CSDN/DeepSeek、alphacorp.ai、kalviumlabs、salttechno）
核心内容：
2026-08 更新版选型决策树： - <10M 向量 + 已有 Postgres → pgvector（零新增服务，HNSW 满足） - 性能敏感 + 自托管 → Qdrant（p50 ~2.1ms @ 1200 QPS，领跑） - 零运维托管 → Pinecone Serverless（~340 QPS，p95 ~28ms） - 混合搜索（向量+关键词）→ Weaviate（原生 hybrid search） - 亿级规模 → Milvus（生产验证） - 需要 ACID + relational + 向量 → pgvector（唯一选项） - 多模态（图像/音频）→ Weaviate 或 LanceDB
关键阈值变化： - pgvector 0.7.0 scalar quantization + pgvectorscale 将 pgvector 适用规模从 "<10M" 扩展至 "10M-100M" - Qdrant 在"性能敏感 + 自托管"场景的优势在 2026 Q1 基准中已量化（2.1ms p50 @ 1200 QPS）
与活文档现有脉络的关系：
- R-52 §邻接 A（2026 VectorDB Tier 框架）——本增量是 Tier 框架的选型落地工具；与 Tier 框架互补，本决策树是工程师可直接使用的决策流
- R-52 §增量 1（pgvector 0.8）——pgvector 0.8 解决工程痛点（Iterative Scan）；本增量给出具体选型路径；两者结合构成完整的 pgvector 2026 选型逻辑
- 活文档不存在——建议今晚活文档编写者以本决策树作为 §向量数据库选型的核心锚点，结合 R-52 Tier 框架综合呈现
建议归入：向量数据库选型章节 + §2.1 pgvector 2026 演进线；★ 高档（多源一致，工程可直接使用）
🟡 增量 3（主轴新增）· Qdrant vs pgvector vs Pinecone 2026 Q1 基准量化——多源交叉验证
来源：jay/2026-08-29-engineering-e1prep.md（§增量 2）+ jay/2026-08-29-ai-engineering-backend-deployment.md（§五·CSDN 向量数据库选型）
原始来源：alphacorp.ai / datacamp / redis.io / instaclustr + CSDN/DeepSeek
发布时间：2026 Q1 基准（持续有效）
可信度：⭐⭐⭐⭐（多源交叉验证；但需注意非官方 benchmark，硬件配置需核实）
核心内容（综合）：
| 向量规模 | 产品 | p50 延迟 | p99 延迟 | QPS | 备注 |
|---|---|---|---|---|---|
| 1M @ 1536dims | Qdrant | ~2.1ms | ~6.3ms | ~1200 | 自托管，Rust 实现 |
| 1M @ 1536dims | pgvector HNSW | — | ~48ms | ~220 | 4 workers 提升至 ~360 QPS |
| 1M @ 1536dims | Pinecone Serverless | — | ~28ms | ~340 | 零运维 |
| 50M @ 90% recall | Qdrant | 4.74ms | 5.79ms | — | 性能衰减极小 |
| 50M | pgvector（无 pgvectorscale） | — | 显著衰减 | — | 超过 pgvector 独立处理上限 |
关键量化差距： - Qdrant vs pgvector QPS 差距：~5.5×（1200 vs 220，未加 pgvectorscale） - pgvector 4 workers 优化后：~360 QPS，仍约为 Qdrant 的 30% - p99 延迟差距：Qdrant 6.3ms vs pgvector 48ms（~7.5× 差距）
技术根因：Qdrant 使用 payload filter during HNSW traversal（而非 post-filter），选择性过滤下 recall 显著更高；pgvector 在 filter+向量混合查询场景有截断问题（pgvector 0.8 Iterative Scan 部分缓解）
与活文档现有脉络的关系：
- R-52 §邻接 A（Tier 框架）——量化数据支撑 Tier 1/3 分层：Qdrant Tier 1（性能敏感）、pgvector Tier 3（原型/中小规模）
- R-52 §增量 1（pgvector 0.8 benchmark）——pgvector 0.8 Iterative Scan 修复 filter 截断，但 Qdrant 在纯性能指标上仍有显著优势；两者不矛盾（pgvector 优势在于生态集成，不是峰值性能）
- CSDN/DeepSeek 来源——中文工程社区对 pgvector 的认可度在上升，但 Qdrant 在性能敏感场景仍为首选
建议归入：向量数据库选型章节·量化基准层；★ 中高档（多源一致，但 benchmark 条件需核实）
🔵 邻接参考（不入 database 主轴，供今晚活文档参考）
邻接 A · InfoQ 金山云 Relyt-V 内核设计——Relaxed Monotonicity + CBO 优化器 + 无锁并发
来源：jay/2026-08-29-ai-engineering-backend-deployment.md（§五·InfoQ）
可信度：⭐⭐⭐⭐（InfoQ 采访，内核级工程细节）
核心内容： - CBO 优化器：基于代价选择向量检索执行计划（而非规则引擎） - Relaxed Monotonicity：图遍历时维护两个优先队列，动态判断是否早停——减少无必要图遍历 - 1GB 分块 prefetch：向量索引数据按 1GB 分块，预加载邻居数据到 Cache - 无锁并发：原子 ID + 原子更新，插入/更新操作无需锁等待
数据库关系：Relyt-V 是国内云厂商在向量数据库内核层面的工程创新；Relaxed Monotonicity 算法是图遍历优化的工程实现，与 pgvector HNSW / Qdrant HNSW 的实现差异值得关注。
建议归入：向量数据库内核算法章节（若活文档有该节）；不入主轴。
⚠️ 矛盾或待核实说法
-
Aurora pgvector 50M 基准的召回率条件：AWS/Instaclustr 原文未明确说明 Aurora 测试中 pgvector 的召回率设定（是 90% 还是更高？）；Aurora vs Qdrant 对比的前提条件需核验，否则选型结论可能不可比。
-
Qdrant vs pgvector QPS 基准的硬件配置：alphacorp.ai 等来源未披露 Qdrant (~1200 QPS) 和 pgvector (~220 QPS) 基准测试的具体硬件配置（CPU/内存/磁盘/并发参数）；不同硬件环境下可复现性存疑。建议截止 9-5 核验 Qdrant 官方 benchmark 页面或独立复现。
-
pgvector 0.7.0 scalar/binary quantization 召回率下降幅度：AWS Aurora 评测提及 scalar float16 和 binary quantization"召回率略有下降"但未给出具体数字；生产环境若对召回率有严格要求（>95%），需实测验证量化后的召回率是否可接受。建议截止 9-5 获取 AWS 原文完整数据表。
📚 可引用 arXiv 号列表
| arXiv 号 | 论文 | 与 database 主轴关系 |
|---|---|---|
2606.16903 |
Directory-Aware Query and Maintenance in Vector Databases | §邻接（向量数据库内核，paper_card 013 已归档） |
2608.01526 |
Internet for the KV Cache | §邻接（KV Cache 基础设施化，与向量数据库的存储层设计相互参照） |
沿用已锚（来自 R-52）：
- 2608.15994 PostgreSQL-V 2.0（R-52 §邻接已锚）
- 2606.07923 Larch: Learned Query Optimization for Semantic Predicates（R-52 §邻接已锚）
- 2606.09824 TSseek（R-52 §邻接已锚）
📝 总结
R-53 预消化评估：database 主轴今日（2026-08-29）有 3 条主轴增量（pgvector 0.7.0 量化变体 Aurora 基准 / 选型决策树更新 / Qdrant vs pgvector Q1 基准量化），0 张新 paper_card，database 主轴延续向量数据库量化选型方向。
R-52（2026-08-28 20:20）已归档 pgvector 0.8 新特性（Iterative Scan / 并行 HNSW / halfvec）+ 2026 Tier 框架。今日 database 主轴增量集中在：pgvector 0.7.0 scalar/binary quantization + Aurora 50M 实测基准（量化存储方案）、选型决策树更新（pgvectorscale 将 pgvector 阈值扩展至 100M）、Qdrant vs pgvector vs Pinecone 2026 Q1 基准量化（5.5× QPS 差距 + 7.5× p99 延迟差距）。
⚠️ 重要发现：活文档 /shared/research-kb/knowledge/database.md 尚不存在。 R-50/R-51/R-52 连续三期均注明"已知"但文件实际未创建。今晚活文档编写者需从零初始化，建议起点：
1. R-52 归档：pgvector 0.8（Iterative Scan / 并行 HNSW / halfvec）+ 2026 Tier 框架 + Percona MySQL 8.4.11-11 + Pigsty/OpenEverest
2. R-53 新增：pgvector 0.7.0 scalar/binary quantization + Aurora 50M 基准 + 选型决策树 + Qdrant vs pgvector 量化基准
database 主轴核心叙事建议（活文档初始化方向）： 1. §1 向量数据库选型决策树（含 pgvector 0.7.0/0.8 双版本 + Qdrant vs pgvector 量化对比 + pgvectorscale 阈值扩展） 2. §2 主流向量数据库生态（pgvector/pgvectorscale → Qdrant / Milvus / Weaviate / Pinecone） 3. §3 AI+DB 交叉（Text-to-SQL / LLM 数据库接口） 4. §4 数据库性能与运维（Percona MySQL / Pigsty / OpenEverest / LMCache）
本次覆盖的所有来源均已在上方"检查范围"表格中完整列出，无遗漏。
R-53 预消化文件：/shared/research-kb/inbox/jay/2026-08-29-database-e1prep.md
生成时间：2026-08-29 20:20 (Asia/Shanghai)
撰写实例：Jay
下次建议：R-54 接力时请再次核查 inbox；关注 pgvector 0.8 正式 release 时间；Aurora 50M 基准原文召回率条件待核实；pgvectorscale StreamingDiskANN 性能数据待跟进。