datascript
datalevin
datascript | datalevin | |
---|---|---|
24 | 15 | |
5,352 | 1,030 | |
- | 3.0% | |
7.7 | 9.6 | |
7 days ago | 6 days ago | |
Clojure | Clojure | |
Eclipse Public License 1.0 | Eclipse Public License 1.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
datascript
-
Datalog in 100 lines of JavaScript (2022)
Hi pests, I don't think the criticism in the comments gives a full picture.
I wrote about a particular flavor of datalog, in common use today. [1] [2]. The earliest representation I know, which matches the syntax of my essay, was in SICP [3]
There's another, more academic form of datalog, which looks a lot more like prolog. Both have lots of similarities: both systems have a set of facts and rules. Both systems have can take a partially filled fact or rule, and find all matching facts. The more academic flavors of Datalog are useful for general logic, and particularly powerful for recursive questions. The variant I showed is more tailed for database queries.
[1] https://github.com/tonsky/datascript
-
XTDB on Mobile Possible?
There is also datascript as a similar option.
- FoundationDB: A Distributed Key-Value Store
-
wotbrew/relic: FRP for Clojure(Script)
What's the use case for relic? Sounds similar to https://github.com/tonsky/datascript ?
- Introduction to Datalog
- Clojure Turns 15 panel discussion video
-
Show HN: Cozo – new Graph DB with Datalog, embedded like SQLite, written in Rust
This look nice !
Datascript seems to be another Datalog engine (in memory only)
https://github.com/tonsky/datascript
-
Ergonomic inline SQL as a Python library
Inspired by past work: LINQ, inline-python, crepe, DataScript, Riffle.
-
Working with large maps
An in-memory database like Datascript may be worth looking into. Otherwise you could take an indexing approach: put all the data into one big map indexed by some unique key, and have a bunch of supplementary indexes that are updated on insertion.
- Obsidian Dataview: Turn Obsidian Vault into a database which you can query from
datalevin
- Datalevin: A simple, fast and versatile Datalog database
-
Is Datomic right for my use case?
You can also consider other durable Datalog options like datahike or datalevin which can work either as lib (SQLite style) or in a client-server setup; if you want to play with bi-temporality XTDB is a rock solid option with very good support and documentation.
- Datomic is free
-
benefits of clojure for web development over Haskell
There are some Clojure-ecosystems things that are pretty cool, too, that you'd probably miss going into Haskell. lacinia is an extremely cool GraphQL library, and there are a variety of interesting datalog-based datastores which are spiritual descendents of Datomic, notably xtdb (formerly crux) and datalevin. Also as noted, you can write the front-end in ClojureScript if you want to, and there are a lot of cool libraries for that as well.
- SQLite Internals: Pages and B-trees
-
Call for Help - Open Source Datom/EAV/Fact database in Rust.
There are plenty of open source Datomic Inspired databases. Check out https://github.com/juji-io/datalevin and scroll down all the way down to “Alternatives”. There was even the beginning of a rust one by Mozilla: https://github.com/mozilla/mentat
- Datalevin ships performant fulltext search for its KV and Datalog stores
-
T-Wand: Beat Lucene in Less Than 600 Lines of Code
The benchmarks in question have several implementation issues, I reported them on GitHub.
https://github.com/juji-io/datalevin/issues/created_by/caval...
-
Choice of NoSQL database: XTDB vs MongoDB
Highly recommend you give https://github.com/juji-io/datalevin a chance. You can use it both as a key-value and/or relational datalog store (like datomic) but it’s very simple to set up and blazing fast!
-
Ask HN: Why are relational DBs are the standard instead of graph-based DBs?
Unlike some other commenters, I agree that graph models are usually a better fit for most data than relational models. There's been some interesting work in recent years developing this idea: in the Clojure world there's Datomic, XTDB, and a host of competitors, all of which build on work from Semantic Web/SPARQL/triplestores and logic programming. Some are even intended to be used as primary datastores: they support some amount of schema and constraints, have well-defined consistency and ACID guarantees, etc. This makes them unlike graph databases like Neo4J and others, which fill an architectural role more like Elasticsearch as a read-optimization tool. Here's an interesting talk making a case for triple-based databases.
What are some alternatives?
asami - A graph store for Clojure and ClojureScript
xtdb - An immutable database for application development and time-travel data compliance, with SQL and XTQL. Developed by @juxt
datahike - A durable Datalog implementation adaptable for distribution.
10000-markdown-files - 10,000 markdown files. Useful for stress testing note-taking tools.
Apache AGE - Graph database optimized for fast analysis and real-time data processing. It is provided as an extension to PostgreSQL. [Moved to: https://github.com/apache/age]
grakn - TypeDB: the polymorphic database powered by types
Neo4j - Graphs for Everyone
indradb - A graph database written in rust