Great discussion on this topic. Glad to see the community correcting misperceptions on MapReduce. Just a few points on Aster:

Re: “SQL analytics”, Aster can:
– Implement SQL analytics-like functionality using In-Database MapReduce
– Feed MapReduce results into SQL analytic functions
– Pass results from MapReduce to analytic functions

Re: “materializing intermediate result sets” and “pipelining”

Aster can avoid materializing intermediate results on disk – this is consistent with Aster’s philosophy for general SQL, as well. Similarly, In-Database MapReduce supports full pipelining of analytics/MR to avoid materialization of intermediate results on disk by passing on data from one phase to the next (we avoid multiple passes of data).

Re: “Aster support of different languages for Map and Reduce steps”

We’ll write more about this separately but it’s worth noting that Aster is not using Postgres UDFs at all in its MapReduce implementation. Instead, we can run in an arbitrary language runtime, and would rather not force the developer to choose one from PostgreSQL’s collection. This lets Aster (and the developer) support/utilize all the popular languages (Java/C/C++/Python/Perl…). It is NOT PL/R, PL/Python, etc…