第 31 篇
工程技术
SQLite 与 PostgreSQL:根据负载选择存储形态
结合实际开发项目,讨论SQLite 与 PostgreSQL:根据负载选择存储形态,说明设计理由、关键源码、验证方法及适用边界。
本文目录 · 7 节
本文属于 Memory Center:AI 编程上下文与记忆系统工程实践,第 31 篇,位于“存储与运维治理”模块。案例背景统一采用实际开发项目;复现步骤使用脱敏教学样例,不代表特定生产事故。
从实际问题出发
个人本机服务希望部署简单,较大规模的检索又可能需要数据库原生向量能力。选择存储应从负载和运维条件出发,而不是把数据库名称当作系统先进程度的标志。
先比较真实需求
SQLite 的轻量部署降低初始成本,PostgreSQL 加 pgvector 提供另一种向量查询路径。两种后端在向量召回、并发与维护方式上并不等价,服务状态应该明确展示差异。

图中展示的是本篇关注的职责和顺序。正常流程之外,还要结合下面的源码与实验检查失败分支;它不是对某次线上调用的运行时追踪。
切换连接串不是数据迁移
新后端需要自己的目录数据、索引与备份流程。不能假定切换 URL 会自动导入原有 SQLite 数据,也不能只保留向量而忽略项目登记和知识记录。具体阈值应来自实际规模测试。
关键源码与阅读方法
源码基线为 Memory Center 6e90553(文档标注 5.0.0b24)。定位:memory_center/service/app.py,函数 storage_status,起始行 51。
以下为当前基线中的函数代码;依赖项目模块,不能作为独立脚本执行。
def storage_status(config: ServiceConfig) -> dict[str, Any]:
"""后端能力边界;SQLite 与 PostgreSQL 并不等价,必须对调用方与页面显式可见。"""
if config.database_url:
return {
'backend': 'postgresql',
'persistence': 'postgres+pgvector',
'vector_recall': 'distance_index',
'hnsw_max_dimension': 2000,
'exact_scan_chunk_limit': 0,
'note': '向量按距离查询;维度不超过 2000 的模型档案建立 HNSW 索引,更高维度退回精确检索。',
}
budget = sqlite_vector_limit()
return {
'backend': 'sqlite',
'persistence': 'sqlite',
'vector_recall': 'exact_scan',
'hnsw_max_dimension': 0,
'exact_scan_chunk_limit': budget,
'note': f'SQLite 向量使用流式精确召回,只保留 Top-K 候选;扫描上限 {budget}(0 为不限制)。耗时随分块数量增长,大规模或高并发建议 PostgreSQL + pgvector。',
}
阅读时先找输入由谁提供,再区分纯计算、读取和写入;遇到异常或提前返回,追问调用方会得到什么,以及已有状态是否仍然有效。上面的代码只证明展示范围内的实现,跨模块行为应继续查看调用处和相应测试。
用一个小实验核对设计
建议在独立临时目录和隔离数据中操作,使用虚构的接口、文档与项目名称。
- 建立两种隔离部署并查看状态。
- 使用相同脱敏样本查询。
- 对比安装、备份和恢复步骤。
**要核对的结果:**报告实际运行形态与测量条件,不将某个小样例结论推广到所有负载。
可把观察记录为下表;没有执行的项写“未执行”,不能用设计预期冒充实测结果。
| 核对项 | 应保留的证据 |
|---|---|
| 使用条件 | 源码版本、配置、输入与项目范围 |
| 正常行为 | 实际返回、来源位置或状态变化 |
| 关键失败分支 | 错误码、可见结果与原状态是否保留 |
| 结论范围 | 已覆盖、未覆盖和需要进一步验证的条件 |
适用边界与继续阅读
本篇以静态源码与项目设计为依据,给出可执行的核对方法,未据此宣称已经完成新的性能或生产环境测试。不同版本的入口、默认值和底层实现可能变化,应先核对当前合同,再把方法用于自己的实际开发项目。
理解这一节后,可以回到专题总导航,沿同一模块继续阅读;顺序学习时使用专栏内的上一篇和下一篇。涉及具体技术选择,应连同本篇的代价与限制一起采用。