Why it ended up being SQLite

For our OSPO work we needed a place where knowledge about our open-source usage comes together: packages, licences, SBOMs – and who knows their way around what. That sounded like a knowledge graph, and therefore like a graph database.

The comparison

I took a closer look at ArcadeDB and Neo4j, and asked along the way whether RDF and SPARQL or a property graph would fit better. Both databases can do considerably more than we need. That was exactly the problem: every capability we do not use still wants to be operated, updated and understood.

The smaller answer

For the amount of data this is actually about, SQLite is enough: FTS5 for full-text search, sqlite-vec for semantic similarity and a few ordinary tables for the relations. One file, no service, nothing to operate.

CREATE VIRTUAL TABLE docs_fts USING fts5(title, body);
CREATE VIRTUAL TABLE docs_vec USING vec0(embedding float[768]);

-- Relations stay perfectly ordinary tables
CREATE TABLE edges (src TEXT, rel TEXT, dst TEXT);

What I take away

Recommending a file feels less impressive than recommending a graph database. But good developer experience also means not having to operate anything you do not need. If we outgrow it, we will move – and we will know a great deal more precisely where to.