You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi there, this is a great project. I really like the fact that it supports duckdb right off the bat for a number of operations.
My goal is to eventually get this working with Kùzu, an embedded graph DB that's very similar to DuckDB in its internals, as well as LanceDB for the vector store, which is also an embedded vector DB. In fact, Kùzu has modeled itself along the lines of DuckDB, and uses a lot of similar ideas in terms of how it integrates with other systems, and its query processor (which supports efficient OLAP operations on large graphs). Embedded databases, in general, seem to be a very good fit for the scenarios that cognee is built for, and I'd love to contribute some functionality to this project on all these fronts.
As an initial idea, I was looking through the render_graphmethod and it's immediately obvious to me how Kùzu is useful here: it's lightweight, requires no servers, and it implements the Cypher query language, so it's really easy to get data in and out (via Cypher, which is declarative just like SQL). In addition, it's really easy to output a Kùzu database to either NetworkX or Pandas DataFrames, both of which are used as intermediate data structures here (for example, to graphistry and for interop between relational and graph formats).
I see that Neo4j is chosen as the default graph database backend for this project, presumably due to the ease of representing the query logic in Cypher. Considering that DuckDB/SQLite are used as the default backends for the relational data, I was wondering how it might be possible to provide Kùzu as an alternative graph backend.
Thanks for putting this up, and looking forward to getting more involved!
The text was updated successfully, but these errors were encountered:
Hey, great suggestions.
We have lancedb on our roadmap, and if kuzu supports cypher, we will add it as we extend neo4j in the next iteration.
Will keep you posted on this one
Great. Kùzu does indeed support Cypher (it's the only query language supported), and it also offers an RDF graph layer that's itself queryable in Cypher-like syntax. I'd be happy to help/test/document things and get the word out as this project evolves. Looking forward to it!
Hi there, this is a great project. I really like the fact that it supports duckdb right off the bat for a number of operations.
My goal is to eventually get this working with Kùzu, an embedded graph DB that's very similar to DuckDB in its internals, as well as LanceDB for the vector store, which is also an embedded vector DB. In fact, Kùzu has modeled itself along the lines of DuckDB, and uses a lot of similar ideas in terms of how it integrates with other systems, and its query processor (which supports efficient OLAP operations on large graphs). Embedded databases, in general, seem to be a very good fit for the scenarios that cognee is built for, and I'd love to contribute some functionality to this project on all these fronts.
As an initial idea, I was looking through the
render_graph
method and it's immediately obvious to me how Kùzu is useful here: it's lightweight, requires no servers, and it implements the Cypher query language, so it's really easy to get data in and out (via Cypher, which is declarative just like SQL). In addition, it's really easy to output a Kùzu database to either NetworkX or Pandas DataFrames, both of which are used as intermediate data structures here (for example, to graphistry and for interop between relational and graph formats).I see that Neo4j is chosen as the default graph database backend for this project, presumably due to the ease of representing the query logic in Cypher. Considering that DuckDB/SQLite are used as the default backends for the relational data, I was wondering how it might be possible to provide Kùzu as an alternative graph backend.
Thanks for putting this up, and looking forward to getting more involved!
The text was updated successfully, but these errors were encountered: