@colindresj: I use DataScript in PartsBox (https://partsbox.io/). It works well, although I am on the edge as to whether I'll keep it in the future. There are two disadvantages: 1) speed, if you have lots of data, I ended up keeping most data outside of DataScript and only using DataScript for relations and small objects, 2) query language complexity and quirks.

@colindresj: the major advantage is the capability to do complex relational queries on your data. So, I'd say it's worth using if you do have complex relations. But I think the idea of DataScript as a single source of truth inside a webapp doesn't work in practice. Maybe in the future. I tried to approach it, but it turned out there were too many limitations, some because of performance and some because of architectural reasons (such as when you have a React app, you don't want to re-render everything if something changes in the db).

But, if you have doubts as to whether it can work in a production client-facing environment with complex data and with thousands of people using it — I'm using it this way and it definitely can. It's good code.

IMO the real power in Datascript isn't the query engine, in fact I removed it entirely from my app (to save space). It's much easier to just get an entry into the database, return the entity and walk the graph DB just like you'd use clojurescript maps

I found performance to be superb for reading. For writing you have to be slightly careful, but it's very doable to just push fast changing state into a local atom first and debounce it into datascript.

I have thousands of Datoms, schema is ~100 attributes. Fully connected graph database.

@rauh: interesting — in my case, I'm using it exclusively for the query engine 🙂 — and I try to keep all the data that I never query outside of DataScript. As an example, a PartsBox part is represented in DataScript as an entity with a single :part/id attribute. All the other part data is in a Clojure map keyed by part id.

@jrychter Yeah, I found that if you connect all your entities the way it makes sense, then you don't need the query engine at all and you just pass Entities around. I keep everything in Datascript, though I'd say roughly 50% of all attributes are client only and don't exists on the server side. I wouldn't change a thing even if I had to rewrite it from scratch.

@rauh but I'm curious then — what's the advantage of using DataScript then, rather than plain Clojure maps? At the very least you pay for sorting, which you never use. How does DataScript help?

It's 100% normalized data, just datom. I don't need to normalize/denormalize like I would have to with maps/vectors. I can walk my graph in any direction I want to. I don't have to worry about inconsistencies when transacting since everything will be taken care of. @jrychter

I don't have any linear time traversal which could become slow when the app state grows. I know it's in an index and the access time will stay pretty constant.

Ok, thanks, I think I see. I have a gut feeling that a small library for managing relations between maps would go a long way towards helping in many similar cases. I certainly could use one.

I think datascript is almost perfect already. I actually have a local fork running and not vanilla datascript. I record which datoms a component accesses so I can re-render if those changes

And some other performance tweaks. Maybe I'll release it some day. But it's 95% datascript. Minus query engine, minus pull api.

Eventually if you wanted to normalize data and be most flexible you'll always eventually arrive at a EAV store with 3-4 different indices into the EAV - Datoms. There is no better way to store this kind of data

Thank you @jrychter and @rauh for your input. One of our main goals is to not have manage data normalization and de-duping across a graph-like dataset, much like @rauh. We’re considering datascript along with https://github.com/stuartsierra/mapgraph