Before I reply let me clarify that I don&#x27;t work there anymore and my thoughts could have diverged since leaving their corporate hive-mind collective of the sort that employees often claim not to represent.<p>&gt; Why couldn&#x27;t it just be a document flavored SQL? Having a DSL for writing in-database procedures is fine. But tying all external queries to a Builder is, from a purely aesthetic POV, pretty ugly IMO.<p>Having raw SQL in an application is insane.  Being able to connect directly to a database and hand-rolling a query in SQL to look at stuff directly is not.  But building such a query in Javascript like you do in the admin UI is fine too (actually, it&#x27;s way more annoying than the Python or Ruby API&#x27;s), with the benefit that you have only one way to learn to write queries, instead of two, and with the downside of not having infix operators and having to close many more parentheses and such.  There might also be training costs if you have a semi-technical role that would have involved making SQL queries.<p>I don&#x27;t believe in an aesthetic POV.  Unless ease-of-use is the aesthetic.<p>&gt; Yes, I realize the Builder supports map&#x2F;reduce as well. In practice I&#x27;m skeptical how well that works in an on-demand fashion.<p>SQL databases already have aggregation queries, so there&#x27;s nothing going on that they wouldn&#x27;t already do.  Map&#x2F;reduce isn&#x27;t, like, a big deal, other than in the mundane way that a table scan is generally a big deal.