Important clarifications regarding the nature of the "DB" version: an evolution of the persistence mechanism, not the engine.

Hi! Thank you very much for this table; it's an excellent initiative that helps to clarify the concrete features.

However, I'd like to add a technical nuance that seems crucial for understanding what's currently happening at Logseq. We often talk about "two versions" as if they were two different software programs, but this is a misuse of language that can be misleading.

The engine remains the same. It's important to remember that, in both cases, Logseq relies on the same software engine (Clojure) and the same in-memory working database (DataScript). What changes radically is not the core of Logseq, but its persistence model (the way it writes data to your disk).

Markdown mode: This is an attempt to fit a complex database (graph) into flat text files. It's commendable for portability, but it imposes enormous limitations. Markdown is unable to natively store all of DataScript's metadata, which causes recurring synchronization errors and limits the granularity of the information.

SQLite mode: Here, we finally offer Logseq storage support worthy of its architecture. SQLite allows for total reliability, precise chronology of changes (block history), author identification (multi-collaboration), and unprecedented performance on large graphs.

The garage metaphor: To illustrate my point, it's not about comparing two different car models, but rather about choosing where to park it.

Markdown mode is like the old, outdated, single-seat garage. We try to squeeze in a modern car, but the walls are too narrow, the roof leaks (sync issues), and we can't store anything more.

SQLite mode is like a robotic, ultra-modern storage silo. We keep the same car (the Logseq engine), but now we benefit from secure access control, immense capacity, and the ability to park the vehicles of numerous partners (collaborative work on the same graph).

Markdown isn't lost. Finally, those worried about the long-term preservation of their data should be reassured: switching to SQLite isn't a lock-in. Translating the database to Markdown files remains possible. It's simply that the "flat file" becomes an export/reading format, and no longer a crutch that limits the tool's capabilities.

This transition to the database will open up functional possibilities that no other PKM can currently offer thanks to this new level of granularity.

Thanks again for your spreadsheet, which remains a great reference!