February 15, 2026
DeLorean meets DLLs
Transforming a Clojure Database into a Library with GraalVM Native Image and FFI
From server to sidekick: a time-travel DB crammed into Rust; comments ask 'why not SQLite?'
TLDR: ChronDB was compiled with GraalVM into a plug-in library so apps like Rust and Python can use it without a separate server. Fans love the flexibility, while skeptics worry about upgrades, migrations, and ask “why not SQLite,” plus a side rant about unreadable dark-mode code blocks.
A dev just stuffed a time-travel database (ChronDB) into apps like Rust and Python by compiling its Clojure guts to a native shared library with GraalVM. Translation: no separate server, no Java process—just a drop-in library you can load. It talks across languages with FFI (a simple bridge between programs), passes around integer “handles” instead of risky memory pointers, and keeps Git-based history for easy debugging. It’s the classic “server becomes sidekick” move, and the nerds are buzzing.
And oh, the comments. The ‘DB as a library’ crowd cheered the clean API, while pragmatists rolled their eyes: “you built a rocket to cross the street—SQLite exists.” User tyushk loved the writeup but asked if there were “weird shenanigans” with FFI beyond C strings. Meanwhile, umairnadeem123 triggered the big debate: if this ships as a compiled library, are upgrades, migrations, and backwards compatibility baked into the app? Cue anxiety over versioning, and split-screen arguments about maintenance vs. control. Then a surprise subplot: half the thread roasted the site’s dark mode because code blocks were unreadable, stealing thunder from the tech itself. Memes flew—DeLorean jokes about “time-travel debugging,” and “Git as storage means you literally commit your feelings.” Verdict: ingenious, but prepare for spicy upgrade stories.
Key Points
- •ChronDB transitioned from a standalone Clojure server to an embeddable shared library using GraalVM Native Image.
- •The embedded approach enables Rust, Python, and other languages to use ChronDB via a C API without running a JVM.
- •A five-layer architecture separates language bindings, C API, Java bridge, Clojure bridge, and ChronDB core (GitStorage + LuceneIndex).
- •A handle registry pattern assigns integer handles to DB instances, simplifying cross-language FFI and avoiding pointer issues.
- •The Java bridge uses @CEntryPoint to export C-callable functions, with initialization and type conversions between C and Java.