pgmicro: 披上 PG外衣的SQLite单刀直入AI记忆系统

无限续杯, PG 推出嵌入式数据库 pgmicro 直击 AI 代理数据存储

https://github.com/glommer/pgmicro

pgmicro 产品解读

这个产品的野心比"让SQLite支持PG wire protocol"更深一层，值得拆解。

技术本质：不是协议层的兼容，而是语言层的编译

大多数"SQLite + PostgreSQL兼容"方案的思路是：

PG SQL → 转译 → SQLite SQL → SQLite引擎  

pgmicro的路径完全不同：

PG SQL → libpg_query（真正的PG解析器）→ PG AST  
       → Translator → Turso AST  
       → Turso编译器 → VDBE字节码  
       → SQLite存储引擎  

关键在于绕过了SQLite的SQL层，直接编译到字节码。这意味着它不受SQLite SQL方言限制，SERIAL、:: cast、

、PostgreSQL JSON操作符这些东西可以原生支持，而不是靠字符串替换hack出来的。

类型系统的例子很说明问题——他们没有把PG类型"翻译"成SQLite类型，而是给Turso本身加了自定义类型支持，然后在上面实现PG类型。这是往下建基础，而不是往上打补丁。

pgmicro 产品定位：针对AI时代的数据库爆炸

README里有一句话定义了目标场景：

ephemeral, low-touch, short-lived, and small — a scratch database for a task, a session store that lives for minutes, a per-user sandbox.

这不是要替代生产PostgreSQL，而是针对一个新兴的需求形态：

SQLite解决了"轻量"问题，但开发者写的是PostgreSQL——无论是因为熟悉度、类型系统还是JSON能力。pgmicro想消除这个摩擦。

三种模式的战略意义

你提到的三种模式其实覆盖了完整的使用谱系：

• 内存模式：最轻量，agent临时任务、单元测试，进程结束即销毁
• 文件持久化模式：单文件数据库，可以用任何SQLite工具检查，数据可携带
• 服务端模式（PG wire protocol） ：现有PG工具链（psql、ORM、BI工具）零改造接入

服务端模式目前作者自己说"very simple"，它更多是验证兼容性的测试工具，而不是主打功能——作者本人预期主要价值在内存和文件模式。

一个有意思的设计决策

作者是Turso的创始人，pgmicro是Turso的fork。这个身份很微妙——他既能深度修改Turso核心，又在README里明确要求最小化对Turso core的改动，让改动upstream化。

这实际上是一种开源战略：pgmicro验证需求，成熟的功能推回Turso主线，两个项目互相喂养。

局限性

• 不是真正的PostgreSQL，复杂查询计划、窗口函数、高级特性的覆盖度还是未知数
• 单文件、无并发写入，天花板在那里
• 处于 v0.6.0-pre.7，作者自己说"no guarantees"

总结：这个产品的核心赌注是 —— AI时代会产生海量小型、短命、嵌入式数据库的需求，而这些场景的开发者想用PostgreSQL语法。如果这个判断是对的，pgmicro 卡住了一个很好的位置。