Datalog Patterns Cookbook··5 recipes for mium power users

This cookbook is aimed at mium power users and developer profiles who have already brushed against [[advanced-query-datalog]] and are after concrete, copy-ready examples. Five recipes, each self-contained — anyone who only needs the orphan detector jumps straight to recipe 5. Datalog itself is a logic programming language from the 1970s; Rich Hickey rediscovered it with Datomic (Cognitect, since 2012) for practical everyday database work. mium uses a Datalog dialect to query its own block index.

Recipes

The five recipes are independent of one another. Cherry-pick what you need, or read linearly — both orders work. Every recipe has: a problem, a query, optionally a gotcha callout.

Recipe 1··Open tasks with a deadline in the current quarter

The standard sprint question: which tasks are open and have to be delivered by the end of the quarter? The query filters on `frist::` within the Q window and `status:: offen`, and returns the owner.

[:find ?block ?frist ?owner
 :where [?block :frist ?frist]
        [?block :status "offen"]
        [(>= ?frist "2026-04-01")]
        [(<= ?frist "2026-06-30")]
        [?block :owner ?owner]]

Recipe 2··Top 10 backlink hubs

Which blocks are referenced most often? The top 10 by incoming `:links-to` edges are the central nodes of your vault — often terms, people, projects.

[:find (count ?backlink) ?target
 :where [?backlink :links-to ?target]
 :order-by [(count ?backlink) :desc]
 :limit 10]

Recipe 3··Audit trail of a block

Who changed what, and when, on a block? The query reads the transaction history in reverse for a given block ID and returns `tx`, `attr`, `value`, and the `added` flag.

[:find ?tx ?attr ?value ?added
 :where [?block :db/id "<((uuid))>"]
        [?tx :tx/affected-block ?block]
        [?tx :tx/attr ?attr]
        [?tx :tx/value ?value]
        [?tx :tx/added ?added]]

Recipe 4··Cross-vault tag aggregation

How often does each client tag occur across all vaults? The query groups on `tags::` with the namespace prefix `#kunde-` and returns a sorted frequency list.

[:find (count ?block) ?tag
 :where [?block :tags ?tag]
        [(re-pattern "^#kunde-") ?tag]
 :group-by ?tag
 :order-by [(count ?block) :desc]]

Recipe 5··Orphan note detector

Which notes have no incoming backlinks and are not archived? These orphans are the dead ends of the vault — candidates for tidying, linking or archiving.

[:find ?block ?title
 :where [?block :title ?title]
        [?block :archiv? false]
        (not-join [?block]
          [?other :links-to ?block])]

When these recipes do NOT fit

Datalog queries are not a universal instrument. Three situations in which these recipes do not hold:

1. Full-text search in the block content — Datalog filters on properties and edges, not on prose. For “find every block that contains `Auftragsbestätigung` in its text”, the mium full-text index is the right instrument, not a Datalog query.
2. Very unstructured vaults with no property discipline — all five recipes assume that `frist::`, `status::`, `owner::`, `tags::` are maintained consistently. In a vault where 80% of blocks carry no properties, the queries return empty sets, not insight. Property discipline is groundwork, not a side effect.
3. Ad-hoc explorations with an unclear question — Datalog rewards precise questions. Anyone who just wants to “have a look at what is in the vault” gets there faster with the graph view or backlink browsing than with a query that still has to be designed.

An honest question

Which of the five recipes fit for you, and which ran into the void? If you put one of them into production: what did you parameterise differently — shifted the Q window, changed the tag namespace, raised the limit? And if none fit: where did we miss the gap? Cookbook recipes live by rubbing up against real vaults — feedback on which recipe #6 is missing here is welcome. Further on in this wave: [[advanced-query-datalog]] for the language fundamentals, [[simple-query]] for the gentler entry without Datalog syntax.