Logseq DB - First impressions

Logseq DB is moving toward a stable beta, and early hands-on use delivers a clear upside: properties become dramatically easier to add and structure, with task management and page layouts feeling more purpose-built than in the older markdown-based workflow. The most immediate “wow” comes from property types—status, date finished, scheduled, and other fields can be created with specific types like date-time, and relationships can point to other nodes in the workspace. That shift matters because it turns what used to be a looser tagging-and-text approach into a more structured object model, where everything is treated as a node rather than a block of markdown.

Task handling also gets a more intuitive UI. Instead of the more manual feel from the markdown version, tasks can be organized with a status field plus priority, deadline, and scheduled dates. The distinction is practical: deadline indicates when something must be done, while scheduled indicates when the work is planned to happen. On top of that, tag pages support multiple views—list, gallery, and a work-in-progress kanban-style drag-and-drop layout—plus grouping options such as grouping by producer to cluster related items.

Yet the same object-based design that powers the improvements also creates friction for anyone migrating from Logseq OG. Tags change meaning: in markdown, tags often function as concept labels that generate pages; in DB, tags define object types. A “book” tag becomes an object category, while “person,” “meeting,” and “company” become distinct objects that can be related. That conceptual flip can quickly confuse users who expect tags to behave like simple links or labels.

Where information “lives” is another sticking point. In markdown, content is straightforwardly stored in page files as blocks, and moving it around usually preserves that mental model. In DB, the transcript describes moments where books appear on a day node and also on a book tag page, but it’s not obvious where the underlying entries are edited. Even basic interactions can feel clunky: adding items in a table view sometimes requires pressing Enter twice, and opening an item may require clicking an arrow or using a specific UI control to reveal the right-side details.

The “not so good” list is mostly about teething issues and UI placement. Adding properties in the correct place can be unintuitive—status fields may be editable in the wrong context, and renaming a property can fail if it’s already used elsewhere. Status type limitations also show up: a status property set to text may only offer a small fixed set of choices, forcing awkward workarounds. Plugins are also unreliable in this early stage, with commonly used ones (like journals, calendar, and bullet threading) disabled due to loading delays.

Other rough edges include quote entry behavior differing from the markdown version, and limited editing visibility for markdown content in DB contexts. Calendar integration and publishing are flagged as still to come, with planned calendar imports and built-in calendar support described as a major future win. In the meantime, the transcript offers practical tips: system properties like external URL and publish UR URL behave differently than user-defined links, and Control+Shift+V helps paste while preserving formatting.