1) availability of valid time for domain as-of queries 2) performance of ad hoc as-of queries 3) ingestion throughput (RocksDB is _fast_) 4) eviction/excisio

1) availability of valid time for domain as-of queries 2) performance of ad hoc as-of queries 3) ingestion throughput (RocksDB is _fast_) 4) eviction/excision throughput 5) a lazy query engine doesn't demand so much memory (because there is no need to hold entire intermediate result sets at the same time), and automatic join re-ordering makes the Datalog inherently more "declarative" 6) use of protocols for modularity allows you to create a massive range of possible topologies to support the non-functional requirements of your host environment 7) benefit from the RocksDB roadmap (or other embedded KV storage - see LMDB / rocksdb-cloud) 8) absence of a prescriptive data model On the flip side: 1) absence of a prescriptive data model (though transaction functions can give you equivalent power) 2) API maturity 3) lazy caching of data at peers (vs Crux' fat nodes, though again, see rocksdb-cloud for one possible resolution) 4) query features: multiple data sources, lazy entity API, other niceties There are definitely things still missing from both lists :)