That is one possible solution. But, for queries we will need some kind of JOIN at runtime. I do store the entity data separately in a transactional row store.

That is one possible solution. But, for queries we will need some kind of JOIN at runtime. I do store the entity data separately in a transactional row store. For analytical queries, we use a column store. For this, I have to include the entity data (context) for each fired event. The whole Compute & Storage semantics are different. If only, we had a persistent data-aware compute & storage graph engine that supported transactional & analytical workloads.