| Author here! Surprised to see this on the front page again (hello fellow pottery enthusiasts?), but figured this could be a good chance to address some of the comments from the recent discussion [0] since I missed it last time :P The most common feedback seemed to be, "this is dumb, just use SQLite", which is definitely valid. This was actually how I initially started building the app (using SQLite), and it worked pretty well. There were a couple reasons I abandoned this approach though: one, whenever I had to uninstall and reinstall the app, the data would get wiped; two, I still had to deal with migrations and other annoying boilerplate; and three, I wanted to be able to share my results with my friends in a read-only web view. (That being said, I'm also curious to explore how tools like ElectricSQL [1], PowerSync [2], TinyBase [3], etc. play with SQlite to handle some of these issues. At a glance, it just seemed like these would require more time to setup compared to InstantDB [4].) Another similar comment that popped up a few times was the idea that if I'm trying to model _relational_ data, it would be ridiculous to use anything other than a _relational_ database. I think that's fair, but I also think it's fair to say a graph database is also "relational" in some sense, or at least "relationship-centric" [5] :) Either way, I had a lot of fun with this. And I was definitely optimizing more for speed/scrappiness than for doing it The Right Way, so if anyone has any thoughts on how to build stuff faster, I'd love to hear it! [0] https://news.ycombinator.com/item?id=40860116 [1] https://electric-sql.com/ [2] https://www.powersync.com/ [3] https://tinybase.org/ [4] https://www.instantdb.com/ [5] https://aws.amazon.com/compare/the-difference-between-graph-... |
* 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/