The whole doc.

the whole doc hits the document store each time (so there is definitely duplication in there, subject to top-level content-hashed idempotency), but the indexes on the node have things decomposed to individual EAVs such that there is almost no duplication

Thanks! Your comments helped me understand better.

Another related question, it's possible to determine that only one attribute has changed during a transaction so that I can state that an attribute started to hold a value X from time Y onwards?

> is it the same with 2.x? It is. refset, or was it jarohen stated that it is faster to have every datum reference to the new version, instead of building from multiple versions.

@U28A9C90Q: yep, same with 2.x. with our bitemporality, the second time dimension naturally makes the temporal resolution a little more complex, so if we can do it once per document rather than once per attribute it's tended to make things faster. that said, it's dependent on the use case - if you're only getting one attribute per document anyway, or the attributes within a document change at significantly different rates, YMMV 🙂

regarding your other question: not currently (within XT at least - you can pull the history back and inspect it but I guess that's not really the point 🙂). getting my crystal ball out for a moment, it could be made possible if we were to introduce SQL window functions further down the line, but that's likely a way off yet

Thanks @U050V1N74