The relational algebra is highly idealized and quite abstract from bytes of data. It is “declarative”. Underneath every relational modeled system, there is a l

The relational algebra is highly idealized and quite abstract from bytes of data. It is “declarative”. Underneath every relational modeled system, there is a lower-level, much simpler system that implements the actual data storage as bytes - and the data access APIs like “scanKeyRange”, “readKey”, “writeKey” - over a sorted data structure like a B-tree. An algebraic operation like “filter” or “selection” (σ) requires the relational layer to understand the layout of data in the storage layer if we want any kind of performance better than O(total number of tuples), right? But that adds complexity and indirection, regardless of the syntax / API used to express the relational algebra, SQL or KQL. You can think of this project as such a storage layer. It is imperative, not declarative, as a primary objective. One could build a relational layer on top, though. From the Motivation section: > I've spent way too much time in Postgres manually denormalizing data and constructing elaborate indexes that perfectly complement a complex query with the goal of EXPLAIN outputting INDEX ONLY SCAN for optimal performance. This dance is a tiresome incidental complexity for application development. How can a relational algebra system (with any form of query language or API) escape this issue? It seems inherent to the declarative nature of relational algebra.