> For maximum power, you want a true graph database.
Do you have empirical validation of this claim? Anecdotally, Postgres has a pretty rich set of graph modeling features these days, and keeps getting more of them, and SQL databases are often operationally simpler than graph databases. Maybe this matters less in a client side app?
It's possible to model graphs in Postgres, but it's a lot more complex. This video compares two queries, one in SQL, and one in Datalog (the query language DataScript uses)[0]. We should probably model a knowledge graph with a graph database!
SQL databases are indeed operationally simpler but that's because they have been around for much longer and are more battle-tested.
> We should probably model a knowledge graph with a graph database!
I realize this seems intuitive, but the relational model has proven itself to be surprisingly flexible in its ability to store multiple different data models efficiently. Similar arguments were made about the suitability of document stores to social networking websites ten years ago, and I think we know how that panned out.
> SQL databases are indeed operationally simpler but that's because they have been around for much longer and are more battle-tested.
I wouldn't discount the age and battle-testing, though. They're the first choice for data storage for many good reasons. Not least of which is the flexibility and power of the relational model.
It's clear that graph query languages are more expressive for graph databases. What's not clear to me is whether there's anything fundamental about that expressiveness, or whether it will eventually be replicated in SQL. Have you tried using recursive CTEs before?
Well the other aspect of it is that DataScript is client-side. That said, we could use sqlite in browser or even IndexedDB at this point. Yes, a pure JS/TS alternative without a graph db implementation is possible. But when I started, I chose the same language and db to ensure parity would always be much more possible.
Haven't tried recursive CTEs before, maybe I should dig into it more!
> Yes, a pure JS/TS alternative without a graph db implementation is possible. But when I started, I chose the same language and db to ensure parity would always be much more possible.
To be clear, I think Datalog and Clojure are both actually really cool, I'm just a huge SQL fan too. I think the architectural decisions you made in this case make perfect sense :)
Do you have empirical validation of this claim? Anecdotally, Postgres has a pretty rich set of graph modeling features these days, and keeps getting more of them, and SQL databases are often operationally simpler than graph databases. Maybe this matters less in a client side app?