ZHzh217·Dec 20, 2022Submission
Cozo is a performant graph database that runs everywhere
2 points · Open discussioncozodb
cozo
Rust2022–2026
cozodb / cozo
cozo
A transactional, relational-graph-vector database that uses Datalog for query. The hippocampus for AI!
16Distinct people
22Mentions
0Explicit recommenders
4.1KGitHub stars
What to know before exploring
What it is
A transactional, relational-graph-vector database that uses Datalog for query. The hippocampus for AI!
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 10:49:33 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2022-11-08 12:25:23 UTC to 2026-10-05 17:39:59 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 7 | 2 | 5 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 2 | 0 | 2 |
What Hacker News says
5 sourcesGot it. Yeah, datalog is cool. I really like it (if that wasn't obvious from my attempt at implementing it). While not built on SQLite, this project has caught my attention recently: https://github.com/cozodb/cozo
It's built on RocksDB and has slightly different query syntax (supposedly to be more similar to Python's, as a primary target usecase is within Jupyter notebooks). Check it out!
In Asami: A flexible graph store in ClojureDid you see the Show HN post announcing cozo 10 days ago?
https://news.ycombinator.com/item?id=33518320
https://github.com/cozodb/cozo
Note: there was a fair amount of discussion about the license; the author eventually switched it to MPL2.
In Asami: A flexible graph store in ClojureIn short: yes, but not right now. See this issue: https://github.com/cozodb/cozo/issues/2. Also in this case you are not really using it as an embedded database anymore, which is our original motivation. We currently also provide a "cozoserver", but it is pretty primitive at the moment. "Big data" capabilities, when they arrive in Cozo, will probably go into the server instead of the embedded binaries.
In Show HN: Cozo – new Graph DB with Datalog, embedded like SQLiteShow HN: Cozo – new Graph DB with Datalog, embedded like SQLite
Hi HN, I have been making this Cozo database since half a year ago, and now it is ready for public release.
My initial motivation is that I want a graph database. Lightweight and easy to use, like SQLite. Powerful and performant, like Postgres. I found none of the existing solutions good enough.
Deciding to roll my own, I need to choose a query language. I am familiar with Cypher but consider it not much of an improvement over CTE in SQL (Cypher is sometimes notationally more convenient, but not more expressive). I like Gremlin but would prefer something more declarative. Experimentations with Datomic and its clones convinced me that Datalog is the way to go.
Then I need a data model. I find the property graph model (Neo4j, etc.) over-constraining, and the triple store model (Datomic, etc.) suffering from inherent performance problems. Th
Read the rest
ey also lack the most important property of the relational model: being an algebra. Non-algebraic models are not very composable: you may store data as property graphs or triples, but when you do a query, you always get back relations. So I decided to have relational algebra as the data model.
The end result, I now present to you. Let me know what you think, good or bad, and I'll do my best to address them. This is the first time that I use Rust in a significant project, and I love the experience!