cozo VS datahike

I can figure parts of it out from https://github.com/cozodb/cozo/blob/main/cozo-core/tests/air_routes.rs which is enough to get started

I've been keeping an eye on https://github.com/cozodb/cozo which is pretty close to something I've wanted, a sqlite version of datalog/datomic.

Finally, the one product I was extremely impressed with and felt was genuinely impressive as a database in general was cozodb.

Take a look at cozodb. It meets most of your goals and I've been really enjoying using it. It might give you some inspiration or something to contribute to.

Sure. They're called 'partials' sometimes. Useful if you want to rerender just part of a page. This is a pattern used by HTMX, a 'js framework' that accepts fragments of html in an http response and injects it into the page. This is good because it avoids the flash and state loss of a whole page reload. See the HTMX essay on template fragments for a more complete argument [0].

This is a go template for an interactive todos app [1] that I'm experimenting with. The html content of the entire page is present in one template definition which is split into 6 inline {{block}} definitions / "fragments". The page supports 5 interactions indicated by {{define}} definitions, each of which reuse various block fragments relevant to that interaction. I'm in the process of converting it to use embedded cozodb [2] queries which act as a server side data store. The idea here is that the entire 'app', including all html fragments, styles, http requests and responses, db schema, and queries are embedded into this single 100-line file.

[0]: https://htmx.org/essays/template-fragments/

[1]: https://github.com/infogulch/go-htmx/blob/master/templates/t...

[2]: https://github.com/cozodb/cozo

If anyone wants to try a FOSS vector-relational-graph hybrid database for more complicated workloads than simple vector search, here it is: https://github.com/cozodb/cozo/

About the integrated vector search: https://docs.cozodb.org/en/latest/releases/v0.6.html

It also does duplicate detection (Minhash-LSH) and full-text search within the query language itself: https://docs.cozodb.org/en/latest/releases/v0.7.html

HN discussion a few days ago: https://news.ycombinator.com/item?id=35641164

Disclaimer: I wrote it.

You are probably talking about this cozo.

Datahike [0] provides similar functionality to datomic and is open source. It lacks some features however that Datomic does have [1].

[0]: https://github.com/replikativ/datahike

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.

Check https://github.com/replikativ/datahike

Oh 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

Having an Datomic like store backed by something like this.

https://github.com/replikativ/datahike

Is an Open Source variant of Datomic.

Lambdaforge wants to eventually have this work with CRDTs.

Using the Matrix ecosystem for this is quite interesting as it solves many problems for you already.

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.

Have a look at https://github.com/replikativ/datahike and https://github.com/replikativ/datahike-postgres

There is now a datahike linux native image preview available: https://github.com/replikativ/datahike/releases/tag/preview

And implemented as a full-on datastore queried via Datalog: https://github.com/replikativ/datahike