March 28, 2026
Immutability: miracle or memory hog?
Joining databases across teams without copying data or running servers
No servers, no copies—just vibes? Devs cheer while skeptics warn of 'infinite bloat'
TLDR: Datahike says you can join different teams’ data without servers or copies by reading immutable snapshots straight from storage. Commenters are split: some love the simplicity and speed, while others warn about storage bloat and point out similar ideas have existed for years.
Forget spinning up more servers and glue-code pipelines—Datahike is pitching a wilder idea: treat your database like a frozen snapshot in storage, then let anyone who can read that storage query it. No API dance. No data copies. One query can join across teams like magic. Fans are calling it “Git for data” and comparing it to Datomic: immutable reads, one writer, everyone else just browses snapshots. Simple, right?
That’s where the comments go off. One camp is swooning over the calm of no coordination, safe caching, and easy parallel reads—“peace at last” energy. Another camp, led by nine_k, throws a bucket of cold water: great, until the storage bill explodes and you need heavy-duty garbage collection to clean up old stuff. And then the history buffs arrive, with readthenotes1 noting that the “new” split between fast transactions and slower analytics has been around long before 2012—cue the “nothing new under the sun” memes.
Meanwhile, jokers are out in force: “No server? Just S3 and chill,” “ETL is over, E-Z mode is in,” and a spicy “call me when ‘immutable’ also pays for storage.” Love it or side-eye it, the community agrees on one thing: if this works at scale, it’s a huge deal.
Key Points
- •Datahike treats databases as immutable values stored in a persistent index, enabling reads without running servers or coordinating APIs.
- •Dereferencing a connection returns a snapshot at a specific transaction, supporting lock-free concurrent reads and consistent views.
- •Unlike Datomic’s transactor overlay, Datahike flushes every transaction to storage, making storage authoritative for reads.
- •Indices are stored as immutable nodes in a persistent B-tree variant with structural sharing, via konserve across multiple backends (e.g., S3, JDBC, IndexedDB).
- •Reads fetch a small branch head and lazily load index nodes with local caching, allowing multi-database queries without copying data.