41 points | 3d ago | Discuss on Hacker News | Back to Radar
forgive my ignorance on such a basic concept. I read 'Embedded' as in 'for Embedded systems'
Does it mean 'Embedded in your rust application'?
It also used datalog, written in rust
Great to see tho, I'm always eagerly hoping for a successful embedded graph database. Most recently my hope was for kuzudb, but they got acquihired; though it's still open-sourcing' as LadybugDB.
Highly recommend taking inspiration from Kuzudb/Ladybugdb and cozodb.
Godspeed!
It should be possible to transpile datalog or another query language that is interesting.
Implementing storage and secondary indicies is the hard part.
Won't comment on rewriting the DB in Rust beyond what's in GitHub discussions.
Improvements welcome!
https://github.com/project-minigraf/minigraf/wiki/Comparison
LLM memory.. let's say, architecturally, its suitable for storing and processing queries - is questionable, but okay. But what real-world use case would generate such queries? It seems to me that the context for formulating and processing the results would be orders of magnitude greater than simply writing down what's needed in plain text. If my notebook took the form of a temporal multiverse of entities, I'd lose the ability to use it properly.
But maybe I'm just too old to quickly get the hang of every new type of Pokémon.
P.S. I'm using the built-in SQLite to store a graph with up to 10 million edges in an MCP app I'm developing for working with code.
Also, I could be wrong but this project sounds like it has an index optimized for bi-temporal data, useful for audit purposes, eg "what was the exact state of the db on september 12th". in neo4j you would have to add that information as indexed properties on each node and edge in addition to other indexes. not sure about the actual performance differences here but I guess one could structure the data more efficient in the first case for time sensitive data usecases.
looks like an attempt to create efficient agent memory.
Also, have you done some benchmarks, like the standard LDBC for graph databases?
This is a project we keep updated: https://github.com/ArcadeData/ldbc_graphalytics_platforms_ar...
Comments are loaded live from Hacker News and are not stored by Mid or Real.
adsharma 3d ago on HN
Existing cypher based databases which support typed properties (including timestamps) on relationship tables can handle this use case just fine.
ex1fm3ta 3d ago on HN
phoghed 3d ago on HN
ex1fm3ta 3d ago on HN
Tanjreeve 3d ago on HN
Tanjreeve 3d ago on HN
Also "because they can" seems obligatory.
baq 3d ago on HN
Tanjreeve 3d ago on HN
adityamukho (author) 3d ago on HN
baq 3d ago on HN
adsharma 3d ago on HN
Most databases have a notion of logical clock to implement MVCC/transactions. So this is just a mapping. Some in the spanner family actually use a drift limited physical clock.
The second part is using an index to answer queries about facts in the past. Like what was the capital of India in 1800?
There are existing embedded graph databases which do this.
Disclosure: I maintain one.
fizzbuzzbarbazz 2d ago on HN