HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
replikativ
datahike
Clojure2018–2026
replikativ / datahike

datahike

Versioned, fast, distributed Datalog engine for everyone.

24Distinct people
31Mentions
0Explicit recommenders
1.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Versioned, fast, distributed Datalog engine for everyone.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year31 dated mentions

Observed mentions: 2018-04-03 07:03:58 UTC to 2026-09-14 11:45:40 UTC.

02468102018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 8 mentions; 5 submissions, 3 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 9 mentions; 1 submissions, 8 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC853
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC404
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC918
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC505

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Branch databases, not just code. Datahike is a durable Datalog database with Datomic-compatible APIs and git-like semantics. Built on persistent data structures and structural sharing, database snapshots are immutable values that can be held, shared, and queried anywhere—without locks or copying. Key capabilities: 🌐 Distributed Index Space: Read scaling without database connections—readers access persistent indices directly 🗄️ Flexible storage: File, LMDB, S3, JDBC, Redis, IndexedDB via konserve 🌍 Cross-platform: JVM, Node.js, Browser (Clojure, ClojureScript, JavaScript, Java APIs) ⚡ Real-time sync: WebSocket streaming with Kabel for browser ↔ server 🕰️ Time-travel: Query any historical state, full transaction audit trail 🔒 GDPR-ready: Complete data excision for regulatory compliance 🚀 Production-proven: Tested with billions of datoms, deployed in government services Distributed by design: Datahike is part of the replikativ ecosystem for decentralized data architectures. Why Datalog? Modern applications model increasingly complex relationships—social networks, organizational hierarchies, supply chains, knowledge graphs. Traditional SQL forces you to express graph queries through explicit joins, accumulating complexity as relationships grow. Datalog uses pattern matching over relationships: describe what you're looking for, not how to join tables. As systems evolve, SQL schemas accumulate join complexity. What starts as simple tables becomes nested subqueries and ad-hoc graph features. Datalog treats relationships as first-class: transitive queries, recursive rules, and multi-database joins are natural to express. The result is maintainable queries that scale with relationship complexity. See Why Datalog? for detailed comparisons. Time is fundamental to information: Most value derives from how facts evolve over time. Datahike's immutable design treats the database as an append-only log of facts—queryable at any point in history, enabling audit trails, debugging through time-travel, and GDPR-compliant data excision. Immutability also powers Distributed Index Space: database snapshots are values that can be shared, cached, and queried without locks. You can find API documentation on cljdoc and articles on Datahike on our company's blog page. We presented Datahike also at meetups,for example at: 2021 Bay Area Clojure meetup 2019 scicloj online meetup. 2019 Vancouver Meetup. 2018 Dutch clojure meetup. Usage Add to your dependencies: We provide a stable API for the JVM that we extend by first providing experimental/beta features that then get merged into the API over time. (require '[datahike.api :as d]) ;; use the filesystem as storage medium (def cfg {:store {:backend :file :id #uuid "550e8400-e29b-41d4-a716-446655440000" :path "/tmp/example"}}) ;; create a database at this place, per default configuration we enforce a strict ;; schema and keep all historical data (d/create-database cfg) (def conn (d/connect cfg)) ;; the first transaction will be the schema we are using ;; you may also add this within database creation by adding :initial-tx ;; to the configuration (d/transact conn [{:db/ident :name :db/valueType :db.type/string :db/cardinality :db.cardinality/one } {:db/ident :age :db/valueType :db.type/long :db/cardinality :db.cardinality/one }]) ;; lets add some data and wait for the transaction (d/transact conn [{:name "Alice", :age 20 } {:name "Bob", :age 30 } {:name "Charlie", :age 40 } {:age 15 }]) ;; search the data (d/q '[:find ?e ?n ?a :where [?e :name ?n] [?e :age ?a]] @conn) ;; => #{[3 "Alice" 20] [4 "Bob" 30] [5 "Charlie" 40]} ;; add new entity data using a hash map (d/transact conn {:tx-data [{:db/id 3 :age 25}]}) ;; if you want to work with queries like in ;; https://grishaev.me/en/datomic-query/, ;; you may use a hashmap (d/q {:query '{:find [?e ?n ?a ] :where [[?e :name ?n] [?e :age ?a]]} :args [@conn]}) ;; => #{[5 "Charlie" 40] [4 "Bob" 30] [3 "Alice" 25]} ;; query the history of the data (d/q '[:find ?a :where [?e :name "Alice"] [?e :age ?a]] (d/history @conn)) ;; => #{[20] [25]} ;; you might need to release the connection for specific stores (d/release conn) ;; clean up the database if it is not need any more (d/delete-database cfg) The API namespace provides compatibility to a subset of Datomic functionality and should work as a drop-in replacement on the JVM. The rest of Datahike will be ported to core.async to coordinate IO in a platform-neutral manner. Documentation 📖 Complete Documentation Index - Organized by topic and skill level Quick links: Configuration - Database setup and backend options Why Datalog? - Query comparisons and when to use Datalog Language Bindings - Java, JavaScript, Python, CLI, and more (beta) Time Variance - Time-travel queries and GDPR-compliant purging Cross-database references - Value-level dh:// references across databases, living vs record (as-of pinned) For simple examples have a look at the projects in the examples folder. Example Projects Applications Beleg - Invoice and CRM system with web UI, LaTeX PDF generation, and Datahike persistence. Works as both an example project demonstrating Datahike patterns and a practical solution for contractors and small businesses. Features customers, tasks, offers, and invoices. Successor to the original Datahike invoice demo from Dutch Clojure Meetup 2018. ClojureScript & JavaScript Support Datahike has beta ClojureScript support for both Node.js (file backend) and browsers (IndexedDB with TieredStore for memory hierarchies). JavaScript API (beta): Install from npm: npm install datahike@next Example usage: const d = require('datahike'); const config = { store: { backend: ':memory', id: d.
Read the full README on GitHub

What Hacker News says

31 sources
https://github.com/theronic/eacl – EACL: Enterprise Access ControL is a situated ReBAC authorization library inspired by SpiceDB, built in Clojure and backed by Datomic Pro, Datahike, Datalevin or DataScript. "Situated" here means that permissions are just data that co-exist with your application data. This has several advantages: reduced network latency, strong local consistency and opportunities for real-time view maintenance. - EACL Performance Demo: https://demo.eacl.dev/ (1M permissioned entities, 3.8M Relationships) - A toy Google Drive clone (runs in-browser): https://drive.eacl.dev/ (4-minute screen recording here: https://x.com/BraaiEngineer/status/2099284919532896675?s=20) - Rationale: https://eacl.dev/#rationale EACL V8 RC was released to Clojars on 12 September 2026: https://clojars.org/dev.eacl/eacl EACL handles authorization
Read the rest
In Ask HN: What are you working on? (September 2026)
It is! And also it has inspired a few other clojure datalog databases, so there is much more choice: * https://github.com/datalevin/datalevin * https://github.com/replikativ/datahike * https://github.com/threatgrid/asami There is also xtdb, but it abandoned datalog and is going in another (albeit interesting direction) https://xtdb.com/ here is a comparison website, but it is somewhat out of date: https://clojurelog.github.io/
In Official Clojure Documentary page with Video, Shownotes, and Links
> The syntax argument is such a tired argument. It's repeated a lot because it's true. The collective developer world has decided that LISP syntax is not the preference. Good if you prefer it, but you're the in the overwhelming minority. Random example i just found via github explore: https://github.com/replikativ/datahike/blob/main/src/datahik... You probably love it but to me it looks like a wall of text. Sure I can figure out what it does, but it gives me a headache.
In Bringing Clojure programming to Enterprise (2021)
Hey. Hybrid in which sense? I have integrated Stratum's columnar indices as a secondary index in the new query engine of https://github.com/replikativ/datahike itself, so for numerical data you will be able to use Datalog/SQL to have combined (OLTP, OLAP, ...) processing. Same for proximum (persistent HNSW vector index) and scriptum (persistent Lucene). Stratum already can be copy-on-write updated online with better write throughput than purely columnar alternatives (Stratum uses a persistent B-tree over column chunks) as far as I tested. I have not compared it in benchmarks yet though, DuckDB recommends to not update it online for instance. But it depends on the workload, if you do random access writes the columnar layout overhead will still be a slow-down compared to OLTP/Datahike's row/entity-wise indices. Also storing fully variable
Read the rest
strings in a column is inefficient, for this you want the entity-wise indices.
In Show HN: Stratum – SQL that branches and beats DuckDB on 35/46 1T benchmarks
Is the datalog engine exposed? Is there any way to cache parsed queries? Other datalog engines support recursive queries, which makes my life so much easier. Can I do that now with this? Or is it on the roadmap? I have fairly large and overlapping rules/queries. Is there any way to store parsed queries and combine them? Also, why the same name as the (Lutris) Enhydra java database? Your domain is currently listed as a "failed company" from 1997-2000 (actual usage of the Java InstantDB was much longer) https://dbdb.io/db/instantdb Given that it's implemented clojure and some other datalog engines are in clojure, can you say anything about antecedents? Some other Clojure datalog implementations, most in open source - Datomic is the long-standing market leader - XTDB (MPL): https://github.com/xtdb/xtdb - Datascript (EPL): https://gi
Read the rest
thub.com/tonsky/datascript - Datalevin ((forking datascript, EPL): https://github.com/juji-io/datalevin - datahike (forking datascript, EPL): https://github.com/replikativ/datahike - Naga (EPL): https://github.com/quoll/naga
In Show HN: InstantDB – A Modern Firebase
It's not either or as you mentioned! Plan to have user data stored in plain files as well. Roam's performance suffers mainly on first-load because they are server-first, and they load the entire db into memory at the beginning (such that it's quite fast thereafter). Once we have true local-first data structures with something like https://github.com/replikativ/datahike, we could still have fast in-memory, but also fast initial load.
In Launch HN: Athens Research (YC W21) – Open-Source Roam Research
Hey, one of the core architects of Datahike here. As a Clojure company we are also super happy that Nubank made Clojure and Datomic much more credible with this move. While Datomic is obviously much more mature, it is important to understand that we have a different scope in our goals than Datomic. Datomic is mostly built as a more convenient backend database for corporate environments and is highly tailored towards AWS and a business environment where the costs of operating and depending on these cloud services is acceptable, which is only the most profitable, but small, slice of the whole market. Even when Datomic gets open-sourced it will not be automatically built with other than these design goals in mind. Our goals on the other hand go even beyond thinking about this backend market; we want to use Datalog really as a distributed sys
Read the rest
tems environment and extend Datahike to all endpoints including the browser and IOT development: https://www.youtube.com/watch?v=A2CZwOHOb6U Our main intention was never to just build an open-source Datomic. But it made too much sense not to do it as a first step. In fact we also really hope that Datomic will be open-sourced such that we can merge our efforts. But given the current governance model of Clojure and Datomic we do not yet foresee that open-sourcing Datomic alone would address a large section of our plans. We are ahead of Datomic already in a few areas: We have funded development for ClojureScript support going for instance and in comparison to Datomic all our efforts where from the beginning aimed at this, we in fact provide more a set of libraries and abstractions that can stand on their own and that you can compose in different ways than having a top-down design that we then unbundle into libraries. This made it much easier for us to evolve and reuse our stack despite the pivot we did from replikativ to Datahike. Regarding maturity we have worked hard during quarantine to address some of our pain points: 1. We significantly improved our write throughput and Datomic performance is in reach (close to release), https://github.com/replikativ/datahike/pull/201 2. We have a first version of our server API available and will extend this in the next months to provide Datomic-style local querying https://github.com/replikativ/datahike-server/ 3. We recently provided Java bindings https://lambdaforge.io/2020/05/25/java-api.html Over the last year we also built a cooperative that has more than 5 people working on this full-time and we aim to grow even faster next year and really bring Datalog to the community and the masses. If Datomic gets properly open-sourced, we will get there even faster.
In Datahike: Durable Datalog database powered by an efficient Datalog query engine
Disclaimer: Not exactly what you are looking for but very close and might suit your needs or spark your interest anyways. I've been playing around with datahike[0] a lot recently. It is a Clojure Datalog based DB like Datomic[1] and in fact mimics its API and behavior, but will by default just write to a directory (not a single file last time I checked) and (will?) support other back-ends such as PostgreSQL. Checkout the repo for more information on the differences. These DBs are not exactly graph DBs (like for example Neo4j) but modelling and (recursively) querying graph data is very much a straight-forward use-case. Schemas are attribute based rather than record/collection based, so you get the kind of schema flexibility you are used to from graph DBs. Another interesting fact is that these are 'immutable' or rather value oriented by de
Read the rest
fault. In simple terms: transactions are additions of facts rather than mutations. Datalog is the primary query language which has really interesting/nice properties. It is worth checking out just for that fact. In Clojure these queries are just normal Clojure data-structures. One of the Clojure linters clj-kondo[2] even ships with static analysis for the soundness of these queries. [0] https://github.com/replikativ/datahike [1] https://www.datomic.com/ [2] https://github.com/borkdude/clj-kondo
In Ask HN: What is the sqlite of graph databases?

Showing the 15 most recent of 31 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.