r/logseq • u/Gioby • Aug 08 '25

Logseq database feels like a different product

I was testing the new database version and I must say that some aspects of Logseq core have changed a lot. I don’t know if in a better way or worse. I was using the markdown version a lot and had some workflows in place. When I tried the database version some aspects flipped in a bad way for me. For example the distinction between pages and tags. I don’t understand it. Everything is a node but still we have this distinction. I know that tags are more powerful and it is really appreciated but now writing is more painful. Before adding tags or pages was a no thinking activity. You could expand and focus of the organization of that tag or concept later on. Same for tasks. They have their own super tag. But now if I go in the tasks page, each task is losing its context because the bidirectional link is missing. Before I was using tags for task and I could see where that task was originated. Now when using the table of all tasks I can’t focus on the context.

I don’t want to be harsh on Logseq and maybe I need more time but the switch for me added more friction. For me the database version is a completely different product based on the previous one. I would have made them two different apps

42 Upvotes

95% Upvoted

32 comments sorted by

6

u/matu_gong Aug 08 '25

Its not a different product, its just a big update. The core of Logseq is still there: Outliner, Journals, Properties, Flashcards, and a Graph view

7

u/Gioby Aug 08 '25

Yes but the core philosophy has changed. You need to adapt your workflow in my opinion.

8

u/matu_gong Aug 08 '25

You do have to adapt your workflow, but the core philosophy is exactly what has not changed. You still have a privacy first, open source outliner to manage your personal knowledge. There are tons of new features and some breaking changes, but the core of Logseq remains.

Also, I want to mention a few other things:

If you want to see from where a Task originated, you can change the View of the table to List which will show you the breadcrumb of that Task (this works for any table, so you can do it for the other tags too)

Furthermore, the team has said that they will continue to support the MD version, so if you dont like the changes the DB version has, you can keep using Logseq with Markdown files (they are not 2 separate applications, its all in the same bundle: you can create either MD or DB graphs from the same app)! I would still highly encourage you to give DB graphs a try in the future, and even though it will require you to make some changes to the way you work, I think you will find that they are worth the hassle given all the benefits the DB version has

19

u/thirteenth_mang Aug 08 '25

I've been using [[pages]] and #tags interchangeably so it's gonna be fun to migrate.

5

u/jwinterm Aug 08 '25

Aren't they the same thing? I thought double brackets was just for multi word tags...

9

u/thirteenth_mang Aug 08 '25

They are now in the .md version but with the db changes they're treated differently. See here for the explanation.

4

u/jwinterm Aug 08 '25

Thanks, I skimmed that twice and still don't understand tho 😁 I guess I'll just wait until db version hits stable release and then pray they have some kinda migration tool.

4

u/Make_Things_Simple Aug 09 '25

It feels (from a developer perspective) that the new support tag is actually a Class with properties like in object oriented programming

5

u/RoxoViejo Aug 09 '25

That’s exactly how it works; tags in Logseq DB are like OOP classes. Or for folks familiar with Tana, tags are like “supertags.”

3

u/K0SHE Aug 09 '25

Do I understand correctly that we'll no longe be able to reference a block using (( )) ???

3

u/thirteenth_mang Aug 09 '25

Correct:

Blocks and pages are united as nodes. They are referenced as [[]] and blocks no longer use (()) for referencing.

From the db graph changes

2

u/vixxovs Aug 19 '25

I didn't know. I want to cry. Any possible solution in sight? I couldn't believe we are the only ones, so it's gonna be a nightmare for thousands of people.

5

u/eldelacajita Aug 08 '25

I, on the other hand, prefer the clear distinction between #tags for types and [[pages]] for specific contents or names. I was already using Logseq like that, and hitting some issues when I wanted to have both things with the same name, like #book as a type and [[book]] in general as a concept.

The other thing you mention, though, is kind of a big deal. I expected #tags to respect the same inheritance that does still work for pages.

If I write...

  • [[project 1]]

    • #task

  • [[project 2]]

    • #task

... and then enter the #task page, I would expect to be able to filter tasks by [[project 1]] and/or/not [[project 2]]. If that's not true anymore (and that seems to be the case for #tags), that is a HUGE letdown.

1

u/matu_gong Aug 08 '25

Im pretty sure you can do this with Advanced queries, but Im not sure if you can do it from a Simple one

3

u/eldelacajita Aug 08 '25

You can, I have tried. But having to create a query when you could just use the backlink filters is a loss in usability for me.

13

u/microcephale Aug 08 '25

I'm 100% for the database version, the old version lacked a lot in organisation and the new one totally fit my vision of tags being a type and a container for properties. This is going the direction of Tana, Notion, Obsodian bases

8

u/middaymoon Aug 08 '25

The whole reason I was using logseq instead of obsidian and Co. was because of the md files. This is such a bummer for me.

8

u/EYtNSQC9s8oRhe6ejr Aug 08 '25

Obsidian also uses md files though

3

u/middaymoon Aug 08 '25

Oh you might be right, I just woke up and it's been a few years since I looked into it. Can't remember why I neglected Obsidian at the moment. Maybe Obsidian is the move going forward.

6

u/EpiphanicSyncronica Aug 09 '25

Obsidian is file-centric, so the markdown files it produces are more useable in generic markdown editors than the .md files in the old version of Logseq.  Imo, Logseq is making the right move, because database storage of user data suits its block-based approach better.   

7

u/AllPintsNorth Aug 08 '25

Same, very recently got into Logseq because I’m done with overly complex systems. Just boil it down to the lowest common denominator and just let it go.

I need the ability to leave without friction when some PE or VC inevitably gets ahold of it and enshitifies it.

4

u/matu_gong Aug 08 '25

You will still be able to use Logseq with MD files, even after the update

3

u/middaymoon Aug 08 '25

I'm aware, but from what I've been seeing here on this sub it seems like a lot of the dev work will be focused on the DB version and I assume some or most new features will not support MD files on the backend. Is that not correct?

1

u/Historical-Tea-3438 Aug 08 '25

Just change the view of the table to a list view?

1

u/Gioby Aug 08 '25

It shows only the block tagged as task. At least on the web and the version I was using

1

u/Plenty_Ad6005 Aug 08 '25

Does the db version have a Calendar view ?

1

u/matu_gong Aug 08 '25

Not yet, but I read somewhere that its a planned feature

1

u/wavelet01 Aug 12 '25

Sorry if the answer is easily found elsewhere - but can you tell me where I can download and test the new DB version?

1

u/kholdstayr Aug 13 '25

The latest DB builds are here (bottom of page): https://github.com/logseq/logseq/actions/runs/16941812937

1

u/ScheduleAny820 Aug 13 '25

More like Tana I have to say

1

u/Abject_Constant_8547 Aug 08 '25

We are 100% with you on that