# Performant node versioning **URL:** \ **Category:** Dgraph\ **Tags:** kind:question\ **Created:** [December 21, 2020, 11:58pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018 "2020-12-21T23:58:51Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![vinaypillai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/vinaypillai/32/5766_2.png) [@vinaypillai](https://discuss.dgraph.io/u/vinaypillai)\ **Post date:** [December 21, 2020, 11:58pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/1 "2020-12-21T23:58:51Z")
Hi! I was interested in implementing some form of versioning for node details, and was wondering if it would be more performant to store deltas or snapshots of each node upon a change. In the context of user profiles, for instance, let’s say we have an initial profile: ```auto { "profileID":"1000", "details":[ { "name":"Jake", "favorite-color":"blue", "DOB":"11/1/2000", "timestamp":"100000" } ] } ``` If the user changes their favorite color from blue to red, we could store the changes with a new snapshot of the profile: ```auto { "profileID":"1000", "details":[ { "name":"Jake", "favorite-color":"blue", "DOB":"11/1/2000", "timestamp":"100000" }, { "name":"Jake", "favorite-color":"red", "DOB":"11/1/2000", "timestamp":"100023" } ] } ``` However, that results in a high storage cost as the database expands. It would be preferable to just store the changes that were made: ```auto { "profileID":"1000", "details":[ { "name":"Jake", "favorite-color":"blue", "DOB":"11/1/2000", "timestamp":"100000" }, { "favorite-color":"red", "timestamp":"100023" } ] } ``` Is there a performant way to query the state of a user’s profile at a given point of time that would coalesce these deltas into a single node? Alternatively, is there a preferred way of tracking a node’s historical data? ---
**Author:** ![anand](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/anand/32/5674_2.png) [@anand](https://discuss.dgraph.io/u/anand)\ **Post date:** [December 22, 2020, 9:36am UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/2 "2020-12-22T09:36:00Z")
Hi @vinaypillai, IMO the problem of managing changes to master data like profiles has a strong process orientation. In this [demo](http://discuss.hypermode.com/t/demo-a-master-data-management-use-case-with-graphql/10572), I provide a GraphQL based approach to tracking lineage of master data. By handling both process and data aspects in one solution, Dgraph can certainly give you an economy of scale. Please review. ---
**Author:** ![vinaypillai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/vinaypillai/32/5766_2.png) [@vinaypillai](https://discuss.dgraph.io/u/vinaypillai)\ **Post date:** [December 22, 2020, 4:11pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/3 "2020-12-22T16:11:58Z")
Hi @anand, I took a look at the demo you linked and it seems like you have a good method for storing the deltas to customer states. For my particular use case, it is necessary to be able to query the state of a large number of profiles at a given point in time. As a result, I was wondering if you would happen to have a good way to query for prior states without having to manually revert deltas at the application level. ---
**Author:** ![anand](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/anand/32/5674_2.png) [@anand](https://discuss.dgraph.io/u/anand)\ **Post date:** [December 22, 2020, 4:16pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/4 "2020-12-22T16:16:58Z")
Hi @vinaypillai, > [@vinaypillai](#): > > I was wondering if you would happen to have a good way to query for prior states without having to manually revert deltas at the application level. I did not get this. What does “manually revert to deltas” mean? I suggest you express all the data in some kind of graph structure and let DQL traverse through it. DQL is quite versatile. ---
**Author:** ![vinaypillai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/vinaypillai/32/5766_2.png) [@vinaypillai](https://discuss.dgraph.io/u/vinaypillai)\ **Post date:** [December 22, 2020, 4:27pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/5 "2020-12-22T16:27:21Z")
Hi @anand, I guess I’m a bit uncertain as to what the DQL query for a customer’s details will return. I was assuming that the query would return the current customer state, along with the history list of things that were changed, so if one were to try to reach a prior state, they would have to traverse the history list to the target state and undo all those changes. Is there a more performant way to do this with DQL? Thanks! ---
**Author:** ![anand](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/anand/32/5674_2.png) [@anand](https://discuss.dgraph.io/u/anand)\ **Post date:** [December 22, 2020, 4:41pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/6 "2020-12-22T16:41:24Z")
It sounds like a log replay mechanism à la Kafka replay. IMO, capturing the whole state might be expensive storage wise, but computationally cheaper and maintainable solution in the long run. Not sure DQL alone can be of much help for this scenario. ---
**Author:** ![vinaypillai](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/vinaypillai/32/5766_2.png) [@vinaypillai](https://discuss.dgraph.io/u/vinaypillai)\ **Post date:** [December 22, 2020, 4:51pm UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/7 "2020-12-22T16:51:44Z")
Thanks! Just wanted to make sure there wasn’t a better option before I started heading down that route. ---
**Author:** ![amaster507](https://yyz1.discourse-cdn.com/flex007/user_avatar/discuss.dgraph.io/amaster507/32/4123_2.png) [@amaster507](https://discuss.dgraph.io/u/amaster507)\ **Post date:** [December 23, 2020, 3:50am UTC](https://discuss.dgraph.io/t/performant-node-versioning/12018/8 "2020-12-23T03:50:46Z")
@anand when we were building our own graphql api pre-Dgraph. We were working on implementing versions with arrays and the last in the array was the most recent. Unfortunately I can’t do this with Dgraph because arrays are sets instead of arrays. Having orderable, duplicate entries in arrays would help provide a better flow for handling versioning use cases.