Logseq Namespaces - How to use (or not use) them

Namespaces in Logseq—built around the forward-slash “/” syntax—are a powerful way to create hierarchy and disambiguate similarly named notes, but they can become a maintenance burden as personal information systems evolve. The core takeaway is pragmatic: namespaces earn their keep for specific problems like “same name, different thing” and for building navigable indexes, yet they’re often harder to refactor than alternatives like page properties.

At a basic level, namespaces function like folder paths. In Logseq, “projects/Logseq Street/tutorials” creates a structured set of pages where each slash adds another layer. That hierarchy matters because it enables namespace queries that return an index of all pages under a given namespace, letting users jump across multiple levels of related content quickly. The transcript highlights this with examples such as PKM notes and Enneagram material: a namespace query can assemble a structured index for a topic (e.g., PKM) and then drill down into sub-areas like “PKM challenges.” For course-related content, namespaces also support public indexing—an updates site can pull a lesson index by querying pages under a tutorial namespace.

The most important use case is disambiguation. When the same label must refer to different concepts, namespaces let users “add a surname” to the name. The transcript uses “principles” as a book versus a page: “principles/book” and “principles/page” prevent links from landing on the wrong note. Similar logic applies to “waking up” (book versus other notes) and to therapy-related references where multiple people might otherwise share overlapping names. Another example is writing notes about books: instead of “write-up of Anamkara,” the system uses “Anamkara/write-ups” so searches and navigation stay fast and unambiguous.

Despite these benefits, the drawbacks loom larger in the creator’s own workflow. Renaming namespaces is described as a “hack” that becomes dangerous when the structure changes; refactoring can be difficult enough that a PowerShell attempt “lost” data. Namespaces also create compatibility issues: the forward slash is stored as “%2f” in filenames, which looks messy and less durable when syncing or using other tools—especially when paired with Obsidian. That mismatch can make long-term maintenance unpleasant.

The verdict is not “never use namespaces,” but “don’t default to them.” If an index is genuinely needed, namespaces can be justified. If the structure might change, page properties are presented as a more maintainable, bottom-up approach for generating indexes and organizing meaning without hardcoding a top-down path. The transcript’s final guidance is to avoid namespaces unless the use case is clear—like disambiguation or a stable, navigational hierarchy—and to lean on properties for flexibility as systems grow and evolve.