> On change, re-run query, diff with RAM results. I don't see the need for the diff. Just repaint with the current info any time the DB changes, as long as the time since last update is greater than the shortest allowed repaint time. That lower limit should probably be no smaller than about 50 ms, the smallest update rate that a human can readily notice. In specialized cases, humans can be faster, but it is also the case that too-rapid updates are hard for humans to track. Thus [DMMs][1], which rarely update more than 3 times a second. For some "dashboard" type operations, you have no choice but to recompute the displayed results from the full data set on each repaint anyway. For instance, if you're showing a running average of some parameter, you need to recompute this over the entire history back to the cutoff point when a new data point comes in. To take a simple case of a regular average, using Javascript: ``` data = [1,2,3]; data.reduce((a, b) => (a + b)) / data.length; ``` This gives the correct result 2. Now append 4 to the data array. Using a diff-based algorithm, how do you take only the 2 from the prior result and the new info (4) to get the new correct average, 2.5? You can't: you need all four data points to compute the correct answer. By the way, that 12 ms result I mentioned above? That was on a "chilled" DB: not fully cold, but not fully prepared to answer that particular query from RAM, either. Re-running it twice gave me 8 ms and then 7.2 ms. [1]: https://en.wikipedia.org/wiki/Multimeter#Digital_multimeters_.28DMM_or_DVOM.29