TL;DR
-
In old Logseq, [[page]] and #tag behaved the same, which made tags feel redundant.
-
In Logseq DB, tags and pages are split — tags are property values, pages are documents — but they still look and act half-merged.
-
Problems: tags are writable but can’t have aliases, tags and pages share the same namespace (causing conflicts), and capitalisation hacks are needed to separate hubs from tags.
-
This creates confusion: sometimes a tag looks like a page, but doesn’t behave like one.
-
A unified model — where pages automatically function as tags and tag views are just special page queries — would avoid this inconsistency and give users the best of both worlds.
When Logseq introduced the new database backend, I was hopeful it would finally resolve something that always felt redundant in the old system: the separation of tags and pages.
In the old Logseq, [[page]] and #tag behaved almost identically — both created a page, both could be used as hubs, and both collected backlinks. In fact, tags often felt unnecessary, since pages could already fulfill their role. My hope was that the DB shift would unify the two concepts: let a page act as both a document and a taggable class.
Instead, Logseq DB has split them apart more strongly:
-
A page is a document — you can write on it, give it aliases, and use it as a hub.
-
A tag is a property value — it groups nodes, powers queries, and auto-generates a table of related entries.
This separation makes sense in terms of database schema, but from a user’s perspective it introduces several inconsistencies and dilemmas:
1. Tags look like pages — but aren’t
When you click on a tag (#career), you don’t just get a sterile DB view. You can write on the tag view, just like on a page. You can even link to tags with [[career]]. This blurs the line: tags feel page-like, but lack key page features such as aliases.
-
I can write notes at the top of #career, but I can’t alias it to #careers.
-
I can link to [[career]], but it doesn’t behave like a true page under the hood.
This half-page/half-tag state is what makes workflows messy. Sometimes I treat tags as hubs, sometimes as metadata, and the difference isn’t clear until it’s too late.
2. Tags and pages share a namespace
In DB, tags and pages aren’t fully separate. If I have #career as a tag, I can’t just create [[Career]] as a clean hub page — Logseq will redirect it to the lowercase tag view ([[career]]).
This collapses two different roles into one entity, but without giving me the power of both. It prevents me from cleanly separating:
-
Classification → using tags for grouping (#career).
-
Narrative → using a hub page for notes, aliases, and queries ([[Career]]).
3. A fragile workaround with capitalisation
I discovered a workaround: if I first create a page named Career, I can keep [[Career]] as a proper page, while #career remains a tag. That way I can:
-
Use [[Career]] as my hub (with aliases, context, queries).
-
Use #career as a property value for classification.
This gives me the best of both worlds, but it’s fragile:
-
It relies on capitalisation hacks.
-
It risks fragmenting backlinks if I accidentally use [[career]] instead of [[Career]].
-
Queries don’t automatically bridge the two — they treat page and tag as distinct entities.
This feels like an accidental loophole, not an intentional design.
4. Tags can’t be aliased or merged
Aliases were one of the most powerful features of pages in old Logseq. If I wanted career and careers to point to the same thing, I could just alias them. With tags, I can’t. That means either:
-
I lock myself into one spelling and hope I remember it forever, or
-
I fragment my graph with multiple near-duplicate tags.
What could have been better: a unified model
The database shift was a perfect opportunity to unify pages and tags into one concept:
-
Every [[Page]] could automatically behave like a tag value.
-
Tag views could simply be special presentations of a page with a built-in query.
-
Pages could keep their ability to hold notes, aliases, and metadata, while also powering the new DB grouping.
This would have:
-
Preserved the elegance of the old model (no redundant concepts).
-
Avoided confusion about when to use [[page]] vs #tag.
-
Given users the best of both worlds: structured queries and narrative hubs in a single place.
Why it matters
As a user, I don’t care about schema purity as much as I care about consistency and clarity in my workflow. Right now, Logseq DB gives me two different entities that behave almost the same, but not quite. That subtle gap (no aliases, namespace collisions, capitalisation hacks) is what creates friction and mess.
I believe the community would benefit if Logseq revisited this design choice and considered unifying tags and pages again — or at least making their roles clearer and more consistent.
Closing thought: If tags weren’t writable, I’d be nudged into using pages as hubs and tags as pure metadata, which would be cleaner. If pages had tag-like DB views, I’d only need one concept. But right now, we’re stuck in an awkward in-between: tags and pages overlap, yet neither fully replaces the other.