The Weekly Edge: Independent Ladybugs, Hamburg Graphs, DataFusion Hacks & more

[Blog]: LadybugDB Flying Solo

Not so long ago, I wrote about LadybugDB‘s previous big update, v.0.17.0, in a previous Weekly Edge. Clearly I couldn’t keep up with how quickly this bug is evolving though, because almost immediately after I wrote that, v.0.17.1 was already online, and now v.0.18.0 is here. Rather than me simply running to catch up once again on all the new updates yet again, however, let’s talk about a new blog post that accompanied the update : “LadybugDB flying solo”.

As Arthur wrote about recently, LadybugDB began as a fork of the now-defunct project, Kuzu. The message “LadybugDB flying solo” is clear: Kuzu is in the past, and the team feel it’s time to crystallize the LadybugDB identity into something new.

To demonstrate all the ways in which LadybugDB has evolved from Kuzu, the blog post runs through all kinds of evidence, particularly tied to the v.0.18.0 update. They highlight a demo you can run against a compressed database, along with notes on indexing, their stable storage format, addition of non-native graph formats via (e.g. via ADBC connectors) and NaviX implementation. They hope that all these updates mean LadybugDB will soon replace Kuzu in search results moving forward.

Remember, LadybugDB is compatible with gdotv, and be sure to check out v.0.18.0!

(P.S. Narratively, I’ve all but guaranteed LadybugDB v.0.19.0 will come out tomorrow and render this immediately out-of-date once again, but like Sisyphus I shall always be here to push another Weekly Edge up the mountain to you.)

[Blog]: Sem Sinchenko Sings Praises for Apache DataFusion

When you love big graphs as much as gdotv does, the saddest thing is not having the hardware to process them. That’s why this week we’re following a recent blog post by Serbia-based data engineer Sem Sinchenko titled: Algorithms on billion-scale graph using 10GB RAM: I love DataFusion!

The post is about a recent change of heart Sinchenko has had about Apache DataFusion, the in-memory query engine based on Apache Arrow. In contrast to his old opinion: “I still don’t fully understand DataFusion’s place in the world of graphs”, Sinchenko has re-evaluated the framework and now whole-heartedly approves of the project.

The pivot comes from a recent test he implemented, using the PageRank algorithm and Weak Component Identification, computed on data from the Graphalytics dataset. By running these against the `graph500-26 (1 billion edges) and twitter_mpi` (2 billion edges) graphs, he found they only required 5GB and 10GB of memory respectively. By moving processes to disk rather than random access memory, it seems DataFusion can make truly colossal projects runnable on small, local hardware.

You can read Sinchenko’s own code on his GitHub, and let us know if you try it out and experience the same impressive results!

[Paper]: pykci – Python Knowledge Graph for Cities

Researchers working at HafenCity University Hamburg have announced the release of pykci (pronounced like “pixie”, which is adorable), or Python Knowledge Graph for Cities.

So what’s pykci exactly? The idea – turning cities into knowledge graphs – starts with CityGML. If you’re not familiar, CityGML is a standard developed by the Open Geospatial Consortium or OGC for modelling cities in 3D. The ‘GML’ in the name refers to the fact CityGML leverages Geography Markup Language, a grammar for XML.

Because CityGML datasets are implemented in XML, these researchers point out that makes it difficult to query projects (cities) directly. Their solution, pykci, claims to be a two-fold solution: first, they provide a system that converts CityGML datasets to knowledge graphs, then they use a large-language model to provide an interface for natural language querying.

In the paper, they apply their pykci implementation to a dataset close to home: 3D renderings of Hamburg, Germany. The resulting knowledge graphs are hosted in Neo4j, and then they try to deduce some information from the graph via natural language questions, like “How many buildings are in the dataset, how tall are they on average, and how many storeys does a typical Hamburg building have?” Naturally, the performance of the natural language interface is strongly tied to the LLM used, so they try both locally hosted and a larger commercial models to generate Cypher queries. They compare their Python pipeline to the similar projects 3DCityKG (XML-to-graph) and 3DCityDB (XML-to-relational) implemented in Java and provide some benchmarking statistics.

If you’d like to check it out for yourself, the project is available at Github, and if you create a Neo4j instance, remember you can always interface Neo4j with gdotv.

[Blog]: ActiveGraph Implements FalkorDB Functionality

This one is an update from FalkorDB. They’ve published a recent blog post titled “Beyond In-Memory Graphs”, which talks about a bit of a code collaboration between FalkorDB and ActiveGraph. The blog post discusses `FalkorDBGraphStore`, a FalkorDB-centric contribution to ActiveGraph framework implemented in Pull Request #39.

So what’s going on here? Well, ActiveGraph itself is an open source framework for multi-agent systems. The idea of ActiveGraph is to provide a framework which tracks agent activity, storing the information in a shared graph, which the subsequent agents can query as they go. That project is built by Yohei Nakajima of the early-stage venture capital firm Untapped Capital. Collaboration between the two is unsurprising, as Untapped Capital are themselves investors in FalkorDB.

FalkorDB’s update to the ActiveGraph repository is to switch the ActiveGraph from using an in-memory graph store to a FalkorDB store directly. They suggest three main benefits to this change, namely the addition of Cypher querying, access to the graph across multiple processes, and removing the graph’s in-memory requirement. In effect, this is a complete integration of FalkorDB into ActiveGraph, making FalkorDB the new fundamental data store for the project. This signals commitment to a technical collaboration between the FalkorDB team and Nakajima, not just a financial one.

If you use FalkorDB for any projects, don’t forget to check out how you can use gdotv to get the most out of your FalkorDB database.

[News]: Substantial Pre-Seed Funding Announced for Tentris

Big news for graph database Tentris. As they recently announced on LinkedIn, the company has successfully received €2 million in seed funding to further develop Tentris databases.

If you’re not already familiar with Tentris, they’re an RDF-specific database developed in Germany, arising from research at Paderborn University. The name arises from the underlying technology: “A Tensor-Based Triple Store”. More information about the technical side, particularly the data structure that makes Tentris unique, can be found here. But ultimately, TentrisDB is investigating radical new ideas in triplestore architecture. The technology is designed to be both scalable and multi-lingual, allowing queries in either SPARQL or GraphQL.

Since 2024, Tentris have been funded directly by the German government, but this marks a new and exciting stage in development for the company. They name Bloomhaus Ventures AG, Vanagon, āltitude, 10x Value Partners, Dr. Pascal Wichmann, and exist as contributors to this pre-seed (early stage) round of funding. This means that we’ll hopefully see some rapid development from Tentris, definitely one to watch in the near future.

If you’d like to get started with a Tentris database, you can see a live demo of the functionality and join the waitlist to get access to Tentris version 1.0. Check out the Github and don’t forget to check out all the ways gdotv is compatible with Tentris.