Logseq Sync will indeed be part of a subscription (currently it requires a donation, but we haven’t set a fixed price). But as I explained above, we will keep supporting and developing the plaintext versions/modes of Logseq, which work with any regular file sync solution.
We’re merely running into technical limitations using plain text as permanent storage (see this announcement for more background), so we’re adding a mode that uses a proper database as permanent storage. This will significantly improve performance of the local app, as well improve the performance of Logseq Sync and will enable real-time collaboration (for those who need it).
The trade-off of using a database file for storage is indeed that you can’t use a class of sync services created for syncing regular text and multimedia files (not binary files).
I’m not sure what you mean by “tiered software” in this context. Can you please explain?
You will have to find a tool/service that lets you sync binary files or is specifically made with .sqlite files in mind.
I don’t know how much you know about software architecture, but there are always trade-offs. In this case, the trade-off of Logseq DB is that we have to use a database/binary file to enable a certain set of features and provide a better syncing experience to those using Logseq Sync.
I want to emphasize that we’re not purposefully creating a lock-in. We’ve made the decision (after talking to hundreds, possibly thousands of users) to offer a version/mode of Logseq (along the existing, plain text, ones) for the people who need more performance, more reliable syncing, real-time collaboration—and are willing to make Logseq a sustainable project by paying for services like that.
If you don’t want to contribute to Logseq in a financial way (or you just don’t want to make use of cloud services, which is a fair point), you will have two choices:
- Use Logseq DB and move around backups manually, or just use your DB graph on a single device.
- Keep using the plain text modes of Logseq and use any off-the-shelf syncing solution (we always recommend Git and SyncThing over any other solution).
Hopefully over time there will also be third-party solutions that offer syncing of .sqlite files like SyncThing does. But this is tough technical challenge, because of which I think there aren’t any yet. I’ve seen some early signs that there are people working on such solutions, so feel free to reach out to me if you know more about this topic (not just you, but anyone).
I don’t want to speak for @tienson, but IIRC I’ve heard him mention that everything is/will be open source. So if you want to run your own sync service for yourself, you will be able to.
But most of our users aren’t that technical and just want a reliable, performant solution. And they want to see Logseq around for years to come, so they’re okay with paying for a service that makes their life easier.
If that’s not you (because you can’t afford it, don’t want to spend money, or simply don’t want to use hosted cloud services), that’s fine. Just realize that everything in software has a trade-off, and these are the trade-offs for Logseq DB.
I hope this makes sense. Let me know if you anything is unclear or you have other questions.