After recently reading @Luhmann ‘s very detailed post regarding NewTags in LogseqDB, the significance of this “Re-write” struck me. NewTags has the potential to be the only true competitor to Tana’s Super Tags which in my opinion are incredibly powerful and possibly the new direction in modern note taking / PKM.
Very Solid Implementation.
From what’s described here, LogseqDB’s NewTags have:
- Properties/fields that auto-populate when you tag something
-
Automatic table views of all tagged items -
Relations between NewTags (the contact-to-contact example) -
Custom property types (checkbox, mood emoji, etc.) -
UI positioning options (like putting checkbox at start of block)
What I’m not sure of or dident see, or missed:
- Inheritance (can one NewTag extend another?)
-
Calculated/formula fields -
Automated workflows/commands beyond basic property population
#Tag vs. [[page]]
This is the big architectural decision that changes everything:
Before (Logseq MD): #tag and [[page]] were the same thing
After (LogseqDB): #tag = structured type, [[page]] = link/reference
This is actually closer to how Tana works - where you have regular page references AND Super Tags as distinct concepts. It’s a breaking change from Logseq’s original philosophy, but necessary to make this work.
Workflows
How @Luhmann used these is very smart.
- The #ck trick: Just adding a checkbox without full task overhead - great for simple checklists
-
Combining NewTags: Using #task + #question together to get both task management AND question tracking. This suggests you CAN apply multiple NewTags to the same block -
The #diary + mood emoji: Using UI positioning to make properties feel native rather than metadata-heavy -
#project as orchestrator: Using it to group notes, contacts, and tasks around a goal
Tradeoff
@Luhmann mentions -
“Compared with Logseq MD, it can be a bit harder to modify your setup after you have started to use it."
This is the tradeoff with structured data. Once you commit to a schema, changing it affects all your existing data. Tana has this same issue.
What’s potentially Missing (That Tana Has)
- Commands/Actions: Tana lets you attach custom commands to Super Tags. Not mentioned here.
-
Complex inheritance chains: The ability to have #employee extend #person extend #entity -
Calculated fields: Auto-calculating totals, counting related items, etc. -
Conditional logic: "If X then Y" type automation
These might exist and/or they might be planned for later alphas.
Thoughts
- This is great for the ecosystem: Competition drives innovation drives pricing… etc. If Logseq nails this, it validates the concept and might push Tana to improve too.
-
Logseq has an advantage: Being open-source and local-first means the community can build plugins/extensions on top of NewTags in ways that might not be possible in Tana. -
The learning curve: The @Luhmann warning about "requiring thought and experimentation" is worth noting. This isn't plug-and-play - you have to architect your own system. -
The alpha warning: Data loss risk + changing schema = don't use for production. But the fact that @Luhmann IS using it daily suggests it's already pretty functional / stable and might be further along than thought.
Future
If LogseqDB launches with NewTags as a core feature and it’s stable, I believe we’ll see:
- A wave of Tana users experimenting with Logseq (especially those who want local-first/open-source)
-
Other PKM tools scrambling to add similar features -
Super Tags" (or whatever the name) becoming a standard feature category, like "bidirectional linking" became
This might be the moment where structured outlining goes mainstream beyond just Tana’s niche.
My apologies if this went long. Excited to see the final outcome.