Modern authorization systems are often graph-based. Check out ReBAC and ABAC authorization models and also implementations like apache/casbin or authzed/spicedb. These schemas often have surprisingly simple graph definitions; I bet they could be replicated in LatticeDB without much trouble.

The permissions question is interesting. I think the answer depends on context. One approach would be to create some edge types `hasAccessTo` and `accessibleBy` that connect a user to a node. Then I'd create an edge type `childOf`. The rest is business logic. Permission checks can just traverse up to the first root node with permissions. The downside is this is all business logic, so can't really look at the database and understand this is how it works. Depending on the database you could create a function that returns permissions for any node, that encapsulates this logic.

Anyways, thanks for checking it out! Really appreciate it. Good luck with your project!

Thanks, that's a great list! Might be worth mentioning our engine there too, for people who want a graph database atop SQLite and other battle-tested relational databases like MySQL, MariaDB, Postgres.

My team and I built it over the years, and it's open source (AGPL). Here is how it works: https://community.qbix.com/t/qbix-streams-as-a-graph-databas...

Our database abstraction layer (and optional ORM) has been battle tested in production for millions of users, and has 3 adapters: Sqlite, Postgres, MySQL/MariaDB. And recently it even added vector search for ranking results by similarity: https://github.com/Qbix/Platform/tree/main/platform/classes/...

Documentation for the database layer is here: https://qbix.com/platform/guide/database

PS: If you do use a relational database for storing graph data, you're going to have a lot of duplication in some public keys. I highly recommend putting ZFS underneath, to help with deduplication. ZFS uses zstd, developed at facebook, and also can encrypt your data at rest (don't use the relational database to do the encryption, otherwise deduplication doesn't work).

very cool site!

I am in the final stages of adding this based on your comment. Just wrapping up doc updates and will push a new release with hot copy functionality tonight!

Wikidata doesn't imply RDF/SPARQL. Cypher works fine too. A columnar storage engine means you get indexes and the relational goodness for free.

https://huggingface.co/datasets/ladybugdb/wikidata-20260401

Yes! This is something I've been thinking about quite a bit the past few weeks. We are going in this direction at work and I think graph storage is a natural way to think about this.

Within the same process it's enforced at the db level. After reviewing the code more I see we don't have a mechanism in place to manage safety across processes. Will add a file lock mechanism tonight. Great call out!

In general though, the goal for this was single writer multiple readers. That was a design decision to keep things simple.

I used claude extensively (as well as codex, I finding myself switching between the two every few months). How I used claude varied by the stage. I spent a lot of time initially going back and forth with claude on the idea, figuring out what exists, what would make this interesting, key features I wanted as a user and how to build something around that that made sense as a product.

The initial phases of building I would build out piece by piece. For example, building out the file system interactions I would have claude build a feature and explain how it worked in an educational manner (e.g., like it was a section in a book on latticedb internals). I would then read through the code. This was a great way to learn and build, simultaneously.

In the later stages, where the features and work was more complex, I would spend more time discussing, instructing, and verifying, but less time understanding the actual implementation. I'll give you an example. It's been a long time since I've handwritten SIMD code. I could try and review claudes output, but I am certain I'd miss any subtle bugs that may exist. I found it more productive to assume the code was right and focus on thinking about how I would verify that. Benchmarking, playing with latticedb, etc. were my primary tools for verifying the work. I could run a benchmark and see performance was great. Then I'd explore the test vectors and realize they were trivial, completely invalidating the benchmark results. So we would go back to the drawing board, create a new benchmark set, see results weren't great, and evaluate what was wrong with the implementation. Sometimes features would take days to get out just because of the iteration loop.

duckpgq is great. I'd say the tl;dr is duckpgq if you have tables you want to traverse like a graph sometimes, latticedb when graph traversal is the primary mechanism of querying.

One of the motivating use cases for me was experimenting with agentic memory. I use latticedb as the backing data store. Finding related memories is traversing the graph (kind of like graph RAG).

Thank you!