[emmanueloga_]

If I understand correctly, you have a single user and a very small dataset (a few hundred KB?) Wouldn't it make sense to keep the entire dataset in memory?

* You can serialize and store the data elsewhere for backups.

* You could allow opening data dumps in read-only mode for sharing, or even generate static HTML for sharing without requiring the app.

When working with in-memory data, it's still helpful to keep the conceptual model of "tables" and ensure the data is as flat as possible, even if you are modeling something like a bare-bones property-graph. Avoid circular references, give things IDs to handle relationships, etc.

re: Graph vs SQL; The distinction between relational and graph databases is most relevant when dealing with larger datasets and lots of many-to-many, recursive or even cyclic join queries. The query language of a graph DB will be a lot nicer to navigate those joins than the equivalent SQL. But if you peek at a modern graph DB like Kuzu, the DDL the statements to create "Node" and "Rel" _tables_ look suspiciously similar to their SQL counterparts :-) [2].

--

1: https://en.wikipedia.org/wiki/Property_graphs

2: https://docs.kuzudb.com/cypher/data-definition/create-table/