4 ms·
If anyone is interested, I am attempting to revive an open source clone of Datomic called EVA. As is the original codebase works fine, its just unmaintained. M
by emccue 4y ago
If anyone is interested, I am attempting to revive an open source clone of Datomic called EVA.
As is the original codebase works fine, its just unmaintained. My hope is to clean up the code, make an HTTP layer for a remote peer, and make a Rust embedded peer so that this sort of Database can finally escape the JVM.
https://github.com/bowbahdoe/eva https://github.com/bowbahdoe/eva
If you want to use something open source today that has the same query language but a different data model, https://xtdb.com/ https://xtdb.com/ is high quality.
- panick21_ 4y agoOh really interesting. I didn't know about that. I was actually going threw the old Mendat code base and was considering using that. I would really like a pure Rust version of Datomic for embed use cases. There is all also Datahike, that is going in that direction too. It is maintained and actively developed. https://github.com/replikativ/datahike https://github.com/replikativ/datahike
- emccue 4y agoFeel free to reach out via any of the contact info on my github. The more the merrier chasing this magic dragon.
- den1k 4y agoif you don't need history, have a look at https://github.com/juji-io/datalevin https://github.com/juji-io/datalevin
- emccue 4y agoDatalevin is good, but its more useful in the same realm as sqlite
- huahaiy 4y agoNot exactly. My goal of developing Datalevin is to replace our use of both Datomic and Postgres, so we have a single DB. The aim is to provide a versatile database that meets data needs of most use cases. I mention Sqlite in README because I have not finished the query engine rewrite of Datalevin, so the query performance is not up to my standard of being competitive with relational databases for large data sets. However, even at the current state, Datalevin is already faster than the alternative Datalog stores in the Clojure world for the most part. Finally, since you seems to want to go into this space, I will mention that: without some new tricks in query algorithms, triple stores would be always slower than standard relational DBs. This is not a solved problem. Just be aware what you are getting yourself into.