I want to know if the page in the database version can be easily converted into PDF for sharing、printing. The export effect of the current plug -in is average and there is a linked jump failure.
When Logseq implements database as a way of storing the data, does that mean that file will no longer be in plaintext? I’m asking this mostly for GIt syncing.
Will there be a truly Portable version along the other installers? We need not install Logseq on all the devices we touch for privacy reasons. Also I don’t want any data to be left on a device where I start Logseq to note down journal entries along PKM and Task Management entries …
I never worked with databases except doing simple queries, and was wondering how is data stored in a file system? I guess it’s not one file representing one page. Where can I learn more about this, i.e. database and how is data stored on a filesystem.
SQLite uses a single file while PostgreSQL for example multiple files. I think Logseq will just use a single file.
Hi,
Do you think the database version will facilitate the migration from Roam Research?
I am asking because the migration process is taking me much more effort than I originally thought. This is due to two main issues:
- File name limitations on multiple platforms: I use MacOS, Android and IpadOS, meaning that I have to rename many of my pages to store them on all devices.
- I’m also extensively using nested page titles that are badly managed in Logseq.
I have the intuition that the database version could directly solve the first issue and maybe help with the second one. But if not, I’m interesting to know to avoid waiting in vain
Since many people seems to also consider migrating, this could be useful information in general.
Thank you
When are we getting the replies for these?
Latest update from discord:
I won’t be replying to the questions directly; the questions are input for a blog post I’m writing. You can find the outline of the questions I’ll tackle first in the OP of this thread.
What’s the internal schema design (page, block, property, link etc.) in DB version? I’ve worked with graph database and think it valuable to support more popular graph databases as a backend, or at least a exporting target
Will there be a way to write to the DB version from other apps? Currently I have scripts which write changes to the underlying md files to get information into LogSeq.
I’ve deleted the last two messages. @tjstankus and @Bryn_M: please use the DM functionality to chat. This thread is for questions only.
Sorry to be strict, but otherwise this thread will be impossible to work with if I have to weed out the questions from the discussions.
Related question: if I’m already using a lot of properties, how will the migration work when switching to the DB version?
If Postgres is used (faster, reliable), how will you manage the postgres versioning update process that requires user intervention? (at least on linux)
They use SQLite like most local apps that need a database because SQLite is the most reliable persistent storage you can have on PCs. PostgreSQL is a totally different beast and it is used when you have many different users of the database, so on servers. And the user intervention you are thinking about is the one by sysadmins on servers, not Linux users on PCs.
Any updates on when the database version will be released for beta or regular use?
I noticed that on the roadmap it indicates that it is complete but it does appear to be available in the wild?
I’m answering here as I keep seeing similar questions about when Logseq DB will be ready. But I’m not going to keep answering questions in this thread as the alpha test has just started and I don’t have all the answers yet. Please wait for the blog update once Logseq DB is more stable.
There’s no ETA. It’s done when it’s done.
That’s because we’re now in closed alpha testing, for which there’s an item on the public roadmap:
I’ll ASAP release the blog post with answers to (most of) the questions in this thread. However, there’s still a lot changing in Logseq DB because of the closed alpha test—which only started last week. That means anything I’d publish now could be incorrect or irrelevant next week. So once the state of Logseq DB has settled down a bit and I’ve put my testing hours in, I’m better able to write an informative blog update.
As for seeing Logseq in “the wild”: there’s a very early browser-based demo of Logseq DB, but we don’t recommend it for daily usage as data loss is very much possible and several features are still missing. Use it at your own risk, but please don’t send us any bug reports or feedback.
We only collect feedback from our alpha testers at this moment; they know where and how to report bugs and suggestions. The developers simply cannot handle hundreds of incoming issues all at once. That’s why we have a closed alpha test so things stay manageable.
As everything is still in flux, we cannot give any dates for when we expect it to be ready for general use. What gets added, changed, or removed all depends on the feedback of the alpha testers, which is completely unpredictable.
If you have any specific questions that you really cannot wait to have answered, please send me a DM.
This is an extremely important issue.
When the DB is in the alpha stage, the developers’ focus is on the product’s smoothness and functionality. However, when the DB reaches the beta version, allowing users to smoothly migrate their existing notes to the DB version without affecting the structure is an issue that cannot be ignored.
In terms of the Markdown version of Logseq, the current structure of most people’s pages is maintained through tags with
and namespace
. This is due to users following the functionality of the existing version.
I have tried to import and test the DB version (24/08/27), and after the import, the namespace
is no longer recognized as a hierarchy. What’s more serious is that those pages with tags have lost their original tag attributes due to the influence of the new tags
. This makes me foresee a great pressure on the organization of the DB version.
I’m not saying new tags
are bad, but the introduction of new tags
will bring a lot of changes to the original software workflow. Developers need to consider the connection between the two versions for users, instead of requiring adjustments to all notes one by one, which may lead to a significant loss of customers.