The key idea behind Naiad's differential dataflow-based approach is to view every database operation as a combination of the input and computation on that input. For example, in order to implement a batch of updates on a graph, the differential dataflow approach would take as input both the current state of the graph as well as the batch of update operations. Naiad applies the batch of updates in order, and outputs the result. Differential dataflow, as the Naiad paper describes, can perform iterative processing on a stream of data. In this case, the stream comprises both the input graph as well as incoming database operations.
This approach is, of course, very different from the way traditional data stores such as Weaver manage the system state. Weaver stores the data as a distributed adjacency list, and Weaver transactions directly modify and read from the adjacency list. As the system processes more and more updates, Weaver stores all the different versions of the graph in-memory , so as to ensure that only the correct answer is observable to an external entity.
Speaking of which, McSherry's post is righteously snarky about various "different flavors of consistency" that seem to be in vogue in the distributed systems community. We share with McSherry his concern about "weird-a** consistency properties" that some systems exhibit. Indeed, we are convinced that regular programmers find it very difficult to reason about any model other than strict serializability or linearizability. First-gen NoSQL companies have used the reasonable-sounding claim that the application ought to drive the properties required of the underlying data store, in order to justify selling databases with incredibly weak consistency properties. It is an open question whether practitioners actually are able to understand custom consistency properties, whether they can formally enunciate the required properties of their applications, and whether they can match them to the interfaces provided by these weak systems. And even in cases where the practitioners can match a data store to an application at a given point in time, application requirements can evolve and change post-deployment, leading to disruptive changes. These concerns do not apply to Weaver, because it guarantees that all transactions are strictly serializable , a very strong and well-understood consistency property.