Logseq在GitHub上放出了「Desktop APP 2.0.1」的公测版本，release note写得很克制：早期beta，会有粗糙边缘,建议测试前备份数据。这条低调的公告背后，其实是这款笔记软件三个月前就已官宣的一次产品分裂——Logseq正式拆成两条线，一条继续维护老用户熟悉的Markdown文件版（代号OG），另一条转向本地SQLite数据库存储，这次公测的就是后者。
对于长期把Logseq当作Obsidian平替、看重"文件即数据"这套哲学的用户来说，这不是一次普通的版本升级。
从文件到数据库，代价是什么
Logseq过去的核心卖点很清楚：所有笔记就是本地Markdown文件，可以用Git做版本控制，能被任何文本编辑器打开，插件生态也建立在这套文件结构上。但纯文件存储在大图谱、复杂查询、多设备同步上一直吃力，这也是Notion、Tana、Anytype这类数据库型笔记工具这几年能抢走一部分用户心智的原因。
2.0数据库版的应对方式，是把存储底层换成本地SQLite（db.sqlite），页面和块统一成"node"模型，属性系统改成带类型的结构化字段。官方披露的一项性能测试里，某个图谱的启动时间从大约20秒压到了1到2秒，大表格和搜索的响应也明显更快。
代价同样具体：闪卡功能是全新实现，跟旧版SRS数据不兼容；白板、Slides、Excalidraw这些内置功能直接消失；文件格式只支持Markdown，Org-mode被砍掉。对依赖Git做版本管理、用外部编辑器改笔记的用户，这几乎是釜底抽薪——SQLite不是能直接grep的文本文件。
官方给出的折中方案是Markdown Mirror：为数据库图谱生成一份只读的Markdown镜像，方便grep和Git继续用。但目前只能数据库单向导出到Markdown，双向同步还在开发中，也就是说这份镜像改了也传不回数据库版。
一个独立仓库,暴露了故障率有多高
官方把数据库版的bug报告单独引导去了logseq/db-test仓库，而不是主仓库的issue tracker。这个安排本身就是个信号——如果稳定性和主版本差不多，没必要专门开一条隔离通道。
db-test里已经有几个值得警惕的开放issue：迁移导入报错、Markdown图谱转数据库版时出现的"破坏性回归"，以及双设备同步时的数据丢失。官方文档也承认，标准Markdown导出并非无损，时间戳和部分属性可能丢失；更完整的EDN导出格式虽然存在，但官方自己都不建议把它当唯一备份手段。本地自动备份倒是有，存放在图谱的backups目录，但目前只保留最近12份。
专门开bug仓库,本身就是稳定性尚未达标的自认。
社区的反馈也印证了这种谨慎。论坛上既有用户认为数据库版把Logseq的每日日志、大纲、反向链接工作流保留了下来，同时补上了结构化属性和查询能力,某种程度上是"Logseq底子加Tana式属性"的组合；也有测试了数月的老用户最终退回Obsidian，理由是稳定性问题、图谱损坏的担忧，以及对SQLite取代可读文件这个方向本身的不适——他们看重的正是文件可移植性。
- 风险.正在用Git管理Markdown图谱、依赖插件或Org-mode的用户，现阶段不建议迁移到数据库版，backup做好三份（Markdown、EDN、SQLite文件本身）再动手。
谁该现在动手,谁该再等等
对新用户或轻度使用者，数据库版的表格、查询、结构化属性确实比老版本更接近Tana这类工具的体验，可以在非关键图谱上先试。对已经建立起成熟Git工作流、依赖白板或Org-mode的老用户，留在OG版是更现实的选择——这条线仍在维护，不会被强制淘汰。
插件开发者需要多一分耐心：数据库版的插件API还没成熟，现有插件在新架构下能不能用尚不确定。Sync这类多设备协作功能目前是付费邀请制，也支持自托管，但距离大规模开放还有距离。
接下来值得盯的，是Markdown Mirror什么时候补上双向同步、db-test里那几个数据丢失类issue修复得有多快。这些进展,比公测本身更能说明Logseq这次押注能不能成。