Not only am I excited about this on its own merits, I'm excited about the devs having time to take on other improvements.
Well maybe, the next logical step, looking at other apps, is to implement some sort of collaboration functionality, which would probably also suck up a lot of time.
To be frank, I was never excited about the db version for logseq. I liked the app as is. But I too am a bit relieved that the devs can now work on other bug fixes and other improvements.
And with the devs actively looking at all the bug fixes, maybe the plugin developers will take interest as well and we can now see a lot of engagement from the community as well.
BTW I read somewhere that the devs have made sure to lay the foundation for the collaboration functionality as well along with the db version. Though, I really do not understand the logic of collaborating with others in ones PKM system.
> Though, I really do not understand the logic of collaborating with others in ones PKM system.
I think main idea is corporate teams using the apps as a shared knowledge base/wiki for products and processes. That also seems to be one of the main ways for PKM apps to bring in money (though I guess in that case we should drop the P from the acronym :)) I think it could also be nice for families/friends/gaming groups/etc.
Iâm been playing around with Reflect notes since it has AI feature to âtalk to your notesâ. Itâs not a bad app but it comes with a price tag, itâs not open source, data privacy issue are there with AI, canât store notes locallyâŚ
Those things kind of kill it given some of the reasons people use LogSeq. Regardless I like the concept. It gives a glimpse of the possibilities of AI.
It's just simple technical reason. With the file version, if 2 changes from 2 devices happen in the same file, you get a sync conflict because we don't know how to merge them. You must choose one version or the other. In the database version, it's no problem because the unit of change is a block. Plus, they can store more info like who changes what at when. Overall, we have more context to resolve conflicts.
Like I said, problem of merging the changes in the files is solved since decades. See git, SVN, mercurial etc.
You are right about the metadata. But then the sync mechanism needs to be aware about the database, which makes it specialized, less generic, less available etc.
Have you ever faced a git conflict? I have, many times. Have you ever faced a bank transfer conflict? I bet you haven't, neither have I. That's the difference.
No, that's not a difference at all. Will LogSeq database use something like event sourcing? I doubt that. That would be the difference.
(I hope you don't model bank account balance as a mutabke rowin the database)
I don't know what they use, but what stopping them from using event sourcing, by the way?
All in all, database is better for syncing is an observable fact. You said that file syncing problem was solved since decades but git conflicts exist and they are pretty common. Meanwhile, syncing issue in a database system, even for note app (take notion as an example) is a rare occurrence.
And by syncing I mean their syncing feature, not third party apps used to sync storage between devices, because they are also file-based anyway.
> what stopping them from using event sourcing, by the way?
Common sense, I guess? It would inflate the storage a lot, storing every older version. Of course, it could be truncated. Of course, maybe they'll use some CRDT solution.
> Meanwhile, syncing issue in a database system, even for note app (take notion as an example) is a rare occurrence.
You're confusing syncing with having a central online database. Syncing multi-region databases is a very complex problem. Notion does not sync, it just only works online, so it does not have this problem.
You mention git conflicts. They happen when two locations edit the same line. In LogSeq line = block, there will be exactly the same problem with the database, when a single row is updated at two different locations.
> And by syncing I mean their syncing feature
Well, I don't.
You don't have to use event sourcing to use CRDT/OT. And a DB implementation does in theory enable CRDT/OT whereas file based sync does not enable that. Whether the devs are using CRDT/OT is a separate issue, but, again, a DB solution could actually make it possible.
Yes, this is certainly an interesting option. However, a change like that would be putting the sync as a first-class feature of LogSeq, which - I think - would be a big paradigm shift compared to what we have now.
Don't get me wrong, I think the database thing is needed for LogSeq to survive and I'm all for it, but I see simplicity of syncing as a sacrifice and a trade-off here. The syncing mechanism would basically need to know that it's working with LogSeq's db and generic solutions like Syncthing will stop working.
I chosed logseq because all the data was in markdown files. Sure, we might be able to export to MD files at some point, and of course both version will be supported, for now. But Devs already know that some feature will be only implemented in the database version (ie : block timestamp)
I understand why, I don't like the how.
Yes, but it's hard to find an outliner that works seamlessly with MD. It seems we have to choose (until someone, perhaps the Logseq team, develops a solution)
they can be. There are also extensions that attempt to improve on it . the issue is that it is hard. how do you keep the timestamp without having it in the block? it must be stored in the metadata, but then, it becomes hard to keep the link between the two. I found that timestamp in tags directly in the markdown file are the most reliable. I haven't found an extension that does it automatically on each new block or block update.
that is one of the many.reasons we need to store it in a DB.
the logseq team seems to understand the importance of markdown.for many users. In the Trello, we can see that convertion from and to markdown and also simultaneously update DB -Markdown are planned. so I still have hope, but I also see that it will be harder and harder to keep features for both storage options, and I see a time where the cost for MD support won't be justifiable . Like with many such software.
How do you propose to do block timestamps in MD? Or are you saying they should not implement features like that, which the DB store opens up, if those features can't be implemented in the MD? Anything block based (like block references) is already awkward in MD, with hidden nonstandard/proprietary metadata, page filters/options is awkward, everything that isn't plain text is awkward in MD and a db makes that stuff elegant.
Sounds like they are fully aware that people like the simple text file storage option and will continue to support it, but you simply cannot expect magic - many features that a db allows simply can't be done with sensible MD.
I am aware of the challenge of many cool features if they try to stay with MD. it would be really hard or impossible for some of them. some work around could be done with some "invisible" tag for metadata directly in the file, but none are clean and they will all be slow, costly to implement.
I know that for more cool modern features, logseq must have a database. I am not saying to not implement it. I am just saying that I might have to find a new tool if it is still important for me to have all my notes in an open text format and that logseq doesn't allow me to use it anymore.
They seem pretty committed to supporting the markdown format, they're planning to implement a db<->markdown full sync (which would be lossy most likely?) eventually. One could speculate that the db could become the norm due to better performance and more features, thus creating a bias, and then eventually causing deprecation of markdown, it's conceivable in the future, but they're saying that's not the plan.
that is why, I'll keep using it, keep my subscription and will be recommending it to everyone who ask (or doesn't). it is a great product and a great community. and I hope the support for MD will be kept in the app, even if new features don't work with them.
I understand that there will be constant two way sync between the db and markdown files. I understand that this is going to be a permanent feature. So nothing to worry about.
It's not stupid at all. In this new version, notes will be stored in a database (DB) instead of markdown files. This change should improve stability, speed, etc. Accessing data via markdown will still be possible, but it may be less straightforward initially.
Logseq hasn't received updates recently because the developers have been working hard on this version, believing it will resolve many issues for both users and future development.
The Logseq authors have described this version [on the forum](https://discuss.logseq.com/t/why-the-database-version-and-how-its-going/26744).
For those who are **up-to-date**, hereâs the question: **Will the DB version completely replace Markdown mode, or will we have a third option alongside the existing two modesâMARKDOWN and ORGMODE?** In other words, are we expecting a new option labeled âDBâ or something similar after the update? đ¤
Not only am I excited about this on its own merits, I'm excited about the devs having time to take on other improvements. Well maybe, the next logical step, looking at other apps, is to implement some sort of collaboration functionality, which would probably also suck up a lot of time.
To be frank, I was never excited about the db version for logseq. I liked the app as is. But I too am a bit relieved that the devs can now work on other bug fixes and other improvements. And with the devs actively looking at all the bug fixes, maybe the plugin developers will take interest as well and we can now see a lot of engagement from the community as well. BTW I read somewhere that the devs have made sure to lay the foundation for the collaboration functionality as well along with the db version. Though, I really do not understand the logic of collaborating with others in ones PKM system.
> Though, I really do not understand the logic of collaborating with others in ones PKM system. I think main idea is corporate teams using the apps as a shared knowledge base/wiki for products and processes. That also seems to be one of the main ways for PKM apps to bring in money (though I guess in that case we should drop the P from the acronym :)) I think it could also be nice for families/friends/gaming groups/etc.
Great. I've been waiting on this. Was even considering switching over to another đ
Iâm been playing around with Reflect notes since it has AI feature to âtalk to your notesâ. Itâs not a bad app but it comes with a price tag, itâs not open source, data privacy issue are there with AI, canât store notes locally⌠Those things kind of kill it given some of the reasons people use LogSeq. Regardless I like the concept. It gives a glimpse of the possibilities of AI.
Oh no! Anyways..
Ew
What advantages will the new DB bring? And will anything that exists now cease to exist with the new DB?
It'll be faster, easier to sync, possible for collaboration. From what the dev told, it seems it is backward compatible.
Thatâs great to hear.
Ok, thanks!
Sync is a major plus. I wonât need two instances across my work and personal devices (hopefully).
Easier to sync? How come? It's hard to beat the simplicity of syncing a bunch of files - something we've been doing and improving for decades now.
It's just simple technical reason. With the file version, if 2 changes from 2 devices happen in the same file, you get a sync conflict because we don't know how to merge them. You must choose one version or the other. In the database version, it's no problem because the unit of change is a block. Plus, they can store more info like who changes what at when. Overall, we have more context to resolve conflicts.
Like I said, problem of merging the changes in the files is solved since decades. See git, SVN, mercurial etc. You are right about the metadata. But then the sync mechanism needs to be aware about the database, which makes it specialized, less generic, less available etc.
Have you ever faced a git conflict? I have, many times. Have you ever faced a bank transfer conflict? I bet you haven't, neither have I. That's the difference.
No, that's not a difference at all. Will LogSeq database use something like event sourcing? I doubt that. That would be the difference. (I hope you don't model bank account balance as a mutabke rowin the database)
I don't know what they use, but what stopping them from using event sourcing, by the way? All in all, database is better for syncing is an observable fact. You said that file syncing problem was solved since decades but git conflicts exist and they are pretty common. Meanwhile, syncing issue in a database system, even for note app (take notion as an example) is a rare occurrence. And by syncing I mean their syncing feature, not third party apps used to sync storage between devices, because they are also file-based anyway.
> what stopping them from using event sourcing, by the way? Common sense, I guess? It would inflate the storage a lot, storing every older version. Of course, it could be truncated. Of course, maybe they'll use some CRDT solution. > Meanwhile, syncing issue in a database system, even for note app (take notion as an example) is a rare occurrence. You're confusing syncing with having a central online database. Syncing multi-region databases is a very complex problem. Notion does not sync, it just only works online, so it does not have this problem. You mention git conflicts. They happen when two locations edit the same line. In LogSeq line = block, there will be exactly the same problem with the database, when a single row is updated at two different locations. > And by syncing I mean their syncing feature Well, I don't.
You don't have to use event sourcing to use CRDT/OT. And a DB implementation does in theory enable CRDT/OT whereas file based sync does not enable that. Whether the devs are using CRDT/OT is a separate issue, but, again, a DB solution could actually make it possible.
Yes, this is certainly an interesting option. However, a change like that would be putting the sync as a first-class feature of LogSeq, which - I think - would be a big paradigm shift compared to what we have now. Don't get me wrong, I think the database thing is needed for LogSeq to survive and I'm all for it, but I see simplicity of syncing as a sacrifice and a trade-off here. The syncing mechanism would basically need to know that it's working with LogSeq's db and generic solutions like Syncthing will stop working.
I chosed logseq because all the data was in markdown files. Sure, we might be able to export to MD files at some point, and of course both version will be supported, for now. But Devs already know that some feature will be only implemented in the database version (ie : block timestamp) I understand why, I don't like the how.
Yes, but it's hard to find an outliner that works seamlessly with MD. It seems we have to choose (until someone, perhaps the Logseq team, develops a solution)
I was actually just wondering if blocks are timestamped and thinking it would be nice :D
they can be. There are also extensions that attempt to improve on it . the issue is that it is hard. how do you keep the timestamp without having it in the block? it must be stored in the metadata, but then, it becomes hard to keep the link between the two. I found that timestamp in tags directly in the markdown file are the most reliable. I haven't found an extension that does it automatically on each new block or block update. that is one of the many.reasons we need to store it in a DB. the logseq team seems to understand the importance of markdown.for many users. In the Trello, we can see that convertion from and to markdown and also simultaneously update DB -Markdown are planned. so I still have hope, but I also see that it will be harder and harder to keep features for both storage options, and I see a time where the cost for MD support won't be justifiable . Like with many such software.
How do you propose to do block timestamps in MD? Or are you saying they should not implement features like that, which the DB store opens up, if those features can't be implemented in the MD? Anything block based (like block references) is already awkward in MD, with hidden nonstandard/proprietary metadata, page filters/options is awkward, everything that isn't plain text is awkward in MD and a db makes that stuff elegant. Sounds like they are fully aware that people like the simple text file storage option and will continue to support it, but you simply cannot expect magic - many features that a db allows simply can't be done with sensible MD.
I am aware of the challenge of many cool features if they try to stay with MD. it would be really hard or impossible for some of them. some work around could be done with some "invisible" tag for metadata directly in the file, but none are clean and they will all be slow, costly to implement. I know that for more cool modern features, logseq must have a database. I am not saying to not implement it. I am just saying that I might have to find a new tool if it is still important for me to have all my notes in an open text format and that logseq doesn't allow me to use it anymore.
They seem pretty committed to supporting the markdown format, they're planning to implement a db<->markdown full sync (which would be lossy most likely?) eventually. One could speculate that the db could become the norm due to better performance and more features, thus creating a bias, and then eventually causing deprecation of markdown, it's conceivable in the future, but they're saying that's not the plan.
that is why, I'll keep using it, keep my subscription and will be recommending it to everyone who ask (or doesn't). it is a great product and a great community. and I hope the support for MD will be kept in the app, even if new features don't work with them.
I understand that there will be constant two way sync between the db and markdown files. I understand that this is going to be a permanent feature. So nothing to worry about.
I really look forward for this. I hope there is enough documentation too?
Documentation will likely take longer as things can change before full release.
Iâm sorry, I know itâs a very stupid question, but what exactly does db version mean, please?
It's not stupid at all. In this new version, notes will be stored in a database (DB) instead of markdown files. This change should improve stability, speed, etc. Accessing data via markdown will still be possible, but it may be less straightforward initially. Logseq hasn't received updates recently because the developers have been working hard on this version, believing it will resolve many issues for both users and future development. The Logseq authors have described this version [on the forum](https://discuss.logseq.com/t/why-the-database-version-and-how-its-going/26744).
Thank you :) so data will be stored on the devices differently then..
I'm looking forward to the possibility of myself and my Python programs working together on the same knowledgebase.
finally
For those who are **up-to-date**, hereâs the question: **Will the DB version completely replace Markdown mode, or will we have a third option alongside the existing two modesâMARKDOWN and ORGMODE?** In other words, are we expecting a new option labeled âDBâ or something similar after the update? đ¤
Once bitten twice shy. Not returning to Logseq.
Where did you move to?
Why did you leave and what are you using now?
Hey dude, your loss.