Peloton – a relational database designed for autonomous operation

OP here. Peloton has been posted here before, but didn&#x27;t get any attention.<p>I think this database is very interesting even if you don&#x27;t care about the time saving part of it, since it claims to be a hybrid (OLAP and OLTP), it implements postgres&#x27; wire protocol and it claims to compile queries to machine code using LLVM [1].<p>[1]: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=mzMnyYdO8jk" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=mzMnyYdO8jk</a> (slideshow: <a href="http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~pavlo&#x2F;slides&#x2F;selfdriving-nov2016.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~pavlo&#x2F;slides&#x2F;selfdriving-nov2016.pdf</a>)

Side note, but I really dislike the current trend (in in-memory databases, to be clear) of not bothering to include any real provisions for durability and justifying it by saying &quot;NVRAM exists.&quot; It effectively doesn&#x27;t for anyone who need to be able to deploy to off-the-shelf environments, and it&#x27;s super expensive (and if you&#x27;re going for performance, like most of the research projects are, countering by using the database in a clustered configuration would be counterproductive). Are there <i>any</i> cloud providers who provide NVRAM in any configuration?

The idea of write-behind logging is slick.<p><a href="http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~pavlo&#x2F;papers&#x2F;p337-arulraj.pdf" rel="nofollow">http:&#x2F;&#x2F;www.cs.cmu.edu&#x2F;~pavlo&#x2F;papers&#x2F;p337-arulraj.pdf</a>

Does anyone know what happens after the query plan is generated in most database? I&#x27;m assuming individual step, like index scan, hashjoin are coded already and the plan steps are iterated and respective methods are called? So the execution steps are already compiled but the step traversal is kind of interpreted. With Peloton LLVM engine everything is merged together in a single sequence of machine code?<p>How much advantage does this give you? Is there really so many steps in the execution plan (the visible steps are usually &lt; 50) but what about the internal actual compiled steps? Unless this is allowing merging and further simplification steps identifying redundant operation that gets trimmed of not sure where 100x performance improvement comes from.<p>Though I remember seeing the scala based in-memory query engine that was sort of doing simplification of the actual steps and doing very well in benchmark, maybe this is similar.

I wonder why they try to support both OLTP and OLAP workloads. Supporting both of these workloads requires too much work (both row and columnar storage types, different algorithms for both storage and querying etc) and they didn&#x27;t even prove that autonomous systems (which is the main point of the project) can replace the existing databases.

This sure has a lot to live up to: trying to do two thing and do them Well isn&#x27;t very unix-y. There&#x27;s a reason relational database are set up to have oltp schemas (highly notmalized tables for supporting transactions etc.) and olap schemas (star schemas for example, large sometimes flat fact and dimension tables etc.). Also I&#x27;m not sure about the learning part: any decent database these days will cache frequently used data and tables can be built as in-memory ones.

How old is this project? I wouldn&#x27;t be surprised to see a cease and desist from the maker of the exercise bike.