habedi-work/useful-notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add a note file for Datomic

Browse Source
This commit is contained in:
Hassan Abedi 2026-03-26 16:07:16 +01:00
parent bd64f88496
commit 809e102f95
1 changed files with 22 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
hassan/010-datomic-for-geolog.md
View File

@ -2,31 +2,31 @@
### Short Answer
Datomic could plausibly serve as the **persistence layer** for Geolog, but not as the full **logic/runtime backend**.
Datomic could plausibly serve as the persistence layer for Geolog, but not as the full logic/runtime backend.
It matches Geolog's desire for:
* **Persistent, append-only storage** with history
* **Interactive mutation** over evolving instances
* **Datalog-style querying** over stored facts
* Persistent, append-only storage with history
* Interactive mutation over evolving instances
* Datalog-style querying over stored facts
It does **not** by itself provide the core Geolog semantics described elsewhere in these notes:
* **Existential witness generation** during the chase
* **Disjunctive branching** into multiple candidate models
* **Equality saturation / term merging**
* **Typed theories, dependent theories, and nested instances** as first-class language concepts
* Existential witness generation during the chase
* Disjunctive branching into multiple candidate models
* Equality saturation / term merging
* Typed theories, dependent theories, and nested instances as first-class language concepts
So the right mental model is:
* **Datomic stores Geolog state**
* **Geolog implements its own chase/type/equality engine above Datomic**
* Datomic stores Geolog state
* Geolog implements its own chase/type/equality engine above Datomic
---
### Why It Fits Part of the Problem
The notes describe Geolog as infrastructure with **persistent, append-only storage** and an **interactive REPL**, not just as a one-shot solver. Datomic's immutable fact model lines up well with that storage story.
The notes describe Geolog as infrastructure with persistent, append-only storage and an interactive REPL, not just as a one-shot solver. Datomic's immutable fact model lines up well with that storage story.
Good candidates to store in Datomic:
@ -72,7 +72,7 @@ Inference: Datomic is a reasonable substrate for storing models and derivation h
### Licensing and Stack Implications
As of **March 26, 2026**, Datomic's official docs say that **all editions are free** and that the **binaries are licensed under Apache 2.0**, while Datomic's own FAQ says it is **not open source** because the source is not published.
As of March 26, 2026, Datomic's official docs say that all editions are free and that the binaries are licensed under Apache 2.0, while Datomic's own FAQ says it is not open source because the source is not published.
Official sources:
@ -83,10 +83,10 @@ Official sources:
Practically, that means:
* You **can** use Datomic inside a stack whose other components are open source.
* You **can** redistribute Datomic binaries where the Apache-licensed binary terms allow it.
* Datomic does **not** force the rest of the stack to become closed-source.
* But you are still depending on a **source-unavailable vendor component**.
* You can use Datomic inside a stack whose other components are open source.
* You can redistribute Datomic binaries where the Apache-licensed binary terms allow it.
* Datomic does not force the rest of the stack to become closed-source.
* But you are still depending on a source-unavailable vendor component.
That source-unavailable dependency has real engineering consequences:
@ -98,8 +98,8 @@ That source-unavailable dependency has real engineering consequences:
So the licensing issue is not "can it legally coexist with open parts of the stack?" The answer there is mostly **yes**. The more important question is strategic:
* does Geolog want a **fully open, self-hostable, inspectable foundation**
* or is it acceptable to place the storage layer on a **free but closed-source binary**
* does Geolog want a fully open, self-hostable, inspectable foundation
* or is it acceptable to place the storage layer on a free but closed-source binary
If Geolog wants the strongest possible open-source story, Datomic is a poor fit. If Geolog mainly wants a strong immutable fact store and accepts vendor dependence, Datomic remains viable.
@ -109,10 +109,10 @@ If Geolog wants the strongest possible open-source story, Datomic is a poor fit.
For Geolog as described in these notes:
* **Yes** for storage, history, and query support
* **No** for the core reasoning engine
* **Legally workable** in a mixed stack
* **Strategically questionable** if full openness is a project goal
* Yes for storage, history, and query support
* No for the core reasoning engine
* Legally workable in a mixed stack
* Strategically questionable if full openness is a project goal
## Changelog