DATABASES Signal 518 2 feeds carried it
UCLA RePL's Prela tutorial demonstrates a query language based on binary relations in 11 lines of Python
↗
Illustration only Photo by Brecht Corbeel on Unsplash
A tutorial from UCLA RePL walks through building Prela, a query language that restricts data to binary relations, as a working Python prototype small enough to read at a glance.
For engineers who model relational data, the tutorial offers a different abstraction: every wide table is decomposed into two-column relations that compose like functions, with foreign-key resolution handled implicitly. The cost is visible in the prototype, more relations to keep track of, tuple-nested results from `&`, and no query planner or persistence layer. The article is a principles tutorial rather than a production release, so any claim that Prela is "better" than SQL rests on the one line-count comparison it shows.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
Prela restricts data to binary relations, so a three-column table like movies is split into separate two-column relations such as movie, title, and year.
The tutorial implements the two core operators, composition and join-on-first-column, in roughly 11 lines of Python using dict lookups, with foreign-key resolution inserted automatically.
The example query joining movies, companies, countries, and cast members is one chained expression, contrasted by the tutorial with a 20-line SQL equivalent.
THE READ
What the cluster adds up to.
The Hacker News submission links to a tutorial from UCLA RePL that introduces Prela, a query language in active development there. Rather than a release announcement, the page is itself the artifact: it builds a toy implementation of Prela in Python, sized so the entire engine can be read in one sitting. The central decision visible in the tutorial is that every table, no matter how wide, is decomposed into two-column binary relations. A movie table with ID, title, and year becomes three separate relations, with a shared row-number coordinate that lets them be joined back together later. The mechanics shown are small enough to audit line by line. Composition is implemented as a dict lookup plus a list comprehension over the source relation, and the `&` operator nests the second columns of two relations into a tuple, so `title & year` maps each row index to `(title_value, year_value)`. Foreign-key resolution is handled implicitly, when the user writes `movie.s(company).s(country)`, the language inserts the row-to-id step rather than forcing the user to write it. This is what lets the headline example read like prose: a movie's company's country, rather than a chain of explicit j
The trade-offs are visible in the same code that demonstrates the wins. Decomposing a wide table means the application has to manage many small relations rather than one coherent schema object, and `&` produces nested tuples that the caller has to unpack. The prototype shown in the tutorial is in-memory only, there is no indexing, query optimization, update path, or persistence layer visible, and the article is cut off before some later operators are introduced. Anyone trying to use this directly would have to build the runtime, planner, and storage layer on top, and the tutorial does not claim otherwise.
The framing of Prela as a "better SQL" is the tutorial's own claim, supported only by a line-count comparison on one worked example. Only Hacker News is carrying the event, and the editorial summary for that feed is just "Comments," so there is no independent reporting, benchmark, or production adoption to weigh against the tutorial's own framing. The article is a principles document, not a benchmark or release note, and an engineer evaluating it should treat the line-count comparison as a single data point rather than a general result.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER