效率火箭公众号文章2026-10-22

Logseq DB 版体验：告别本地 Markdown，数据同步与「本地优先」该何去何从？

最近，我下载了 Logseq 最新的公开测试版，也就是所谓的 DB 版。它采用了 SQLite 数据库代替原本的 Markdown 文件库。

公众号 · 10 篇文章

最近，我下载了 Logseq 最新的公开测试版，也就是所谓的 DB 版。它采用了 SQLite 数据库代替原本的 Markdown 文件库。

我尝试把原来的 Markdown 笔记导入 DB。大约 1000 个节点，导入后用起来依然流畅。有几个节点显示兼容问题，总体问题不大。

性能还没有专门测试，超大库的表现暂时不好下结论。目前既能导入旧笔记，也能直接创建原生数据库图谱。

但是，这次变化让我更在意的是，原来的文件同步方式在未来将处于什么位置。

本地 Markdown 文件给我安全感

我们知道，Logseq 以前的笔记就是一批 Markdown 文件。我可以自己选同步工具、自己做备份，某一篇出问题，就打开那篇检查。即使换个编辑器，正文也能继续读写。

同步时，Markdown 也可能有冲突。两台设备同时改一篇笔记，虽然概率不大，但仍需协调处理。比如同步未完成、错误覆盖之类的情况。

Logseq 的块引用和查询，也未必能被其它 Markdown 笔记软件完整解析。但是只要是 Markdown 文件，涉及个别文件的问题，通常可以局部单独处理。

对我来说，本地优先的吸引力就在于：数据可以放在自己的电脑上，自己信任的云盘上，完全自主掌握。

Logseq DB 版把图谱内容及配置放进 db.sqlite，附件仍单独存放。两台电脑即使改的是不同笔记，除了附件以外，也很可能分别产生一个不同版本的数据库。

网盘能传输数据库文件，却未必（几乎肯定不会）懂得合并里面的节点。直接挑一个「较新的文件」覆盖过去，另一台设备的修改可能就丢了。

我们知道，数据库本身有事务保护，不容易损坏。但是粗暴的文件级别同步就很难说了。我几乎不会再考虑普通基于文件的同步方式了。

过去能逐篇打开、逐篇修复的内容，现在更依赖专门机制。如果出了问题，用户很难直接处理，也许有专门的数据库修复机制，或者就应该多做备份。

如果撇开传统的文件备份，Logseq DB 也提供了官方的 Sync 服务，类似 Obsidian 的官方 Sync，另外，Logseq DB 也支持自托管同步。用户还是有些选择权的。

可是，选择一个熟悉的网盘，与部署维护一套同步服务，对普通用户来说是不同的门槛。如果你执意要使用 DB 版的话，官方服务可能因此成为许多人最现实的选择。

现在的 2.0.2 桌面版还提供 Markdown Mirror，把数据库内容反向生成出 Markdown 文件。但它是单向输出，修改镜像文件不会回写到数据库，也不能把它当成保证完整恢复图谱的备份。

作为一种备份手段，这有一些价值，但是不大。

我们可以这样理解，Markdown Mirror 更像是一种审计，Logseq 能产生出凭证，让你放心 DB 里面有这些内容，由于直接访问 DB 对于一般人来说门槛太高，所以生成 Markdown 文本这种大家能看懂的文件作为凭证，而且查看可以独立于 Logseq 本身，使用任何文本编辑器即可。

我的心情有点复杂。Logseq DB 版应该是在性能上做出了极大进化，原来那种基于分散文件存储的方式，效率肯定是低下的，巨大数量节点的解析一定是痛苦的，现在这个问题算是解决了。

但是，数据的主动权、同步的便利性、基于纯文本的透明性也都失去了。

其实 Logseq 应该参考 Obsidian，MD 文件仍旧保持，同时在不同设备上建立自己本地的数据库索引，这样可以兼顾数据同步和访问效率。

准备迁移的老用户，一定要先用一个副本尝试 DB 版，把同步和恢复的机制弄清楚，再决定是否迁移主库。测试版阶段尤其应该留住原始 Markdown 文件。

如果管理自己数据的能力，越来越依赖专门服务和技术知识，那么即使数据库还在硬盘上，本地优先原来吸引我的意义，也已经打了折扣。希望有个开源且兼顾文件和 DB 版本的 Logseq 出现，在不久的将来，也许 AI 能为我们带来一个。

内容来自公众号，可前往微信查看原文。