简化与演化
内容提要
本文记录了hypatia从DuckDB+SQLite组合迁移至纯SQLite架构的完整推理。作者指出DuckDB的OLAP特性与记忆系统的OLTP负载错配，导致空间浪费和并发问题。新架构利用SQLite的WAL模式支持多Agent并发，通过单事务保证原子性，并将向量索引外置为可重建文件。迁移后书架从5GB降至100MB，验证了“人守语义契约，AI完成方言翻译”的工作模式。
延伸解读
OLAP与OLTP的错配：为什么DuckDB不适合记忆系统
文章指出，DuckDB的OLAP特性（列存、向量化执行）适合批量分析，但hypatia作为记忆系统，实际负载是高频小事务、并发访问的OLTP形态。这种错配导致空间浪费（5GB中98%为死空间）和并发限制（单写者）。这提醒开发者，选择数据库引擎时，应基于实际负载模式，而非仅看技术亮点。
SQLite的WAL模式与原子性：多Agent协作的关键
SQLite的WAL模式支持多读者与单写者并行，配合busy_timeout自动重试，解决了多Agent并发读写冲突。更重要的是，单事务内完成数据与索引的原子更新，避免了旧架构跨库写入的撕裂态。这体现了在特定场景下，简单技术栈通过合理配置也能满足复杂需求。
语义契约与方言翻译：AI辅助重构的实践
作者将指令集视为语义契约，实现视为方言。在契约稳定后，通过AI将DuckDB方言翻译为SQLite实现，验证了“人守语义契约，AI完成方言翻译”的工作模式。这为技术迁移提供了一种方法论：先稳定接口，再借助AI工具降低迁移成本。
向量索引的取舍：外置可重建文件与等待官方扩展
向量检索是迁移的难点。作者选择将embedding存为BLOB（源真相），HNSW索引外置为可重建文件，避免引入异构存储。同时等待SQLite官方vec1扩展成熟。这种“数据与索引分离”的设计，既保证了单源真相，又保持了灵活性，值得借鉴。
Q&A
hypatia 为什么从 DuckDB+SQLite 组合迁移到纯 SQLite 架构？
因为 DuckDB 的 OLAP 特性与 hypatia 记忆系统的 OLTP 负载错配，导致空间浪费和并发问题。DuckDB 单进程单写者，缺乏成熟的并发控制，而 hypatia 需要多 Agent 并发读写，SQLite 的 WAL 模式更合适。
hypatia 新架构如何解决多 Agent 并发读写问题？
SQLite 的 WAL 模式支持多读者与单写者并行，读写互不阻塞，写写冲突由 busy_timeout 自动重试，适合多个 Agent 共享同一个书架的场景。
hypatia 迁移后书架空间从 5GB 降到 100MB，这 100MB 主要由什么构成？
100MB 中约三分之二是 embedding 本身（每条 1024 维 float32），这是数据的固有成本；其余为 knowledge 和 statement 等真实数据。
hypatia 如何处理向量索引？为什么选择外置文件而不是数据库内？
向量索引（HNSW 图）作为可重建的缓存存放在文件系统的独立快照中（使用 usearch），因为 SQLite 官方 vec1 扩展尚未发布，且其他方案存在内存不落库、维护停滞或许可证问题。外置文件坏了可从 BLOB 列重建，不牺牲单源真相。
hypatia 的 JSE 指令集在迁移中扮演什么角色？
JSE 指令集是 hypatia 与存储层之间的契约，固定在二十个算子上。指令集稳定后，语义与实现分离，AI 可以根据语义在 SQLite 上重新实现，实现“人守语义契约，AI 完成方言翻译”的工作模式。
hypatia 新架构如何保证数据与索引的一致性？
一次 CRUD 是 SQLite 内的单个事务，源表、文档锚点、JSON 倒排、全文索引同时生效，避免了旧架构跨库写入的撕裂态。查询时所有检索在同一连接和事务边界内完成。
hypatia 未来如果数据量达到亿级，空间和性能如何扩展？
未来亿级规模由本机的 PostgreSQL（pgvector）承担，这是有意留下的另一层。本地单文件方案不适用于亿级。
