--- title: Prela Tutorial | daily.dev description: Prela is a new query language developed at UCLA that represents an alternative to SQL, built entirely from binary relations (tables with two columns). This... canonical: https://daily.dev/posts/prela-tutorial-5qnafbvgu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Prela Tutorial | daily.dev og:description: Prela is a new query language developed at UCLA that represents an alternative to SQL, built entirely from binary relations (tables with two columns). This... og:url: https://daily.dev/posts/prela-tutorial-5qnafbvgu og:image: https://api.daily.dev/og/posts/5qNAfbVgu.png og:image:alt: Prela Tutorial og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Prela Tutorial **[Lobsters](https://daily.dev/sources/lobsters)** · 6 min read · 0 upvotes · 0 comments ## Summary Prela is a new query language developed at UCLA that represents an alternative to SQL, built entirely from binary relations (tables with two columns). This tutorial builds a toy Python implementation of Prela to explain its core operators: relation composition (.select), the & operator for pairing columns, .eq for filtering, and .where for restriction. It shows how decomposing wide tables into binary relations (akin to 6NF) lets queries compose like functions, producing dramatically shorter queries than equivalent SQL (11 lines vs 20+). A full paper and GitHub implementation are linked for further exploration. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is the Prela query language and how does it differ from SQL? Prela is a new query language from UCLA's RePL group built entirely on binary relations, tables with only two columns. Wide tables are decomposed into pairs of binary relations (similar to sixth normal form), and queries are built by composing these relations like functions using operators such as .select, &, .eq, and .where. This composability lets queries like a 20+ line SQL join collapse into roughly 11 lines. _Developers curious about alternative query paradigms can follow deep dives on database design via daily.dev._ ### How does the & operator work in Prela compared to SQL joins? The & operator joins two binary relations on the first column of both and pairs up their second columns into a tuple, producing a relation that maps each row to both attributes at once. Because the result is still a binary relation, it can be composed further, and nesting & inside a .where clause doubles as logical conjunction for combining multiple filter conditions. _Anyone comparing query language design choices can track niche database concepts like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 114 comments across lobsters, hackernews (as of 2026-08-31). **TL;DR:** Reaction is split between people intrigued by the binary-relation/composability idea (with several detailed comparisons to Datalog, Alloy's dot-join, LINQ, and 6NF) and skeptics who think the showcase SQL example is artificially bloated and that Prela isn't clearly better than well-written SQL. **Sentiment:** 25% positive · 40% mixed · 35% skeptical **The case for** - Some find the composability and algebraic foundation genuinely novel and easier to reason about than SQL for complex queries. - A few see it as a promising base for a real query optimizer since the algebra generalizes existing SQL optimization techniques. - The tiny (<100 line) reference implementation was seen as a nice educational artifact for understanding how a relational engine works. **The pushback** - Multiple commenters rewrote the benchmark SQL query far more concisely than the post's 20+ line version, undercutting the core line-count comparison. - Several argue the example isn't representative of typical SQL and that readability/maintainability matter more than line count. - Some doubt the performance comparison against DuckDB is fair, questioning whether both systems used equivalent indexing and memory setups. - One thread initially misread the project as compiling to existing SQL servers, which turned out to be incorrect. **By community** - lobsters (mixed): A brief confusion about whether it targets existing SQL servers was cleared up, followed by a demonstration that the touted SQL comparison could be written much shorter with modern syntax. - hackernews (mixed): Extensive back-and-forth covering theoretical comparisons (Datalog, Alloy, LINQ, 6NF), skepticism about the benchmark's fairness, and repeated rewrites showing the SQL example wasn't as verbose as claimed, alongside genuine interest from some in the algebraic approach. **Hottest debate:** Whether the 20+ line SQL example is a fair baseline, with multiple people rewriting it in far fewer lines and disputing that line count is even a meaningful metric. **Open questions** - How does Prela's performance advantage hold up if DuckDB were given equivalent indexing? - How does Prela fundamentally differ from Datalog, Alloy's relational algebra, or LINQ beyond terminology? - Can schema constraints (e.g., uniqueness like a movie having exactly one title) be expressed in Prela? **Highlights** > I’m not sure how they come up with the 20-line example anyway - it’s one join. Traditionally SQL uses a lot of lines because you put one thing per line, but so what? > — [kamma4434 on hackernews](https://news.ycombinator.com/item?id=49496024) > This seems harder to read than SQL, and only less verbose if you assume that an SQL database would be built with Prela's limitations in mind, which doesn't feel like a reasonable assumption. > — [Planktonne on hackernews · 1 comments](https://news.ycombinator.com/item?id=49492940) > The entire point of databases are indexes. Without indexes there is no point to keeping data in tables with rows and columns and having a special language (or even interface) for querying. > — [scotty79 on hackernews](https://news.ycombinator.com/item?id=49493587) > Their "equivalent query that spans over 20 lines" can be written more cleanly using some more modern syntax in 12 lines (excluding empty lines added for readability): ``` SELECT MIN(an.name) AS cool_actor_pseudonym, MIN(t.title) AS series_named_after_char FROM title AS t INNER JOIN movie_keyword AS mk ON mk.movie_id = t.id INNER JOIN keyword AS k ON k.id = mk.keyword_id INNER JOIN movie_companies AS mc ON mc.movie_id = t.id INNER JOIN company_name AS cn ON cn.id = mc.company_id INNER JOIN cast_info AS ci ON ci.movie_id = t.id INNER JOIN name AS n ON n.id = ci.person_id INNER JOIN aka_name AS an ON an.person_id = n.id WHERE cn.country_code ='[us]' AND k.keyword ='character-name-in-title' ``` And probably there is still a way to remove that pesky `MIN()` aggregate in cleaner way (using subquery or lateral joins. > — [hauleth on lobsters · 2 points](https://lobste.rs/s/xnljk9/better_sql_11_lines_code#c_yq8foy) **Source threads** - [lobsters](https://lobste.rs/s/xnljk9/better_sql_11_lines_code) · 21 points · 6 comments - [hackernews](https://news.ycombinator.com/item?id=49491544) · 43 points · 108 comments ## Similar posts on daily.dev - [Things I want in a modern relational query language](https://daily.dev/posts/things-i-want-in-a-modern-relational-query-language-y0qgepv3u) · Lobsters · 1 upvotes · 0 comments --- Tags: [#python](https://daily.dev/tags/python), [#sql](https://daily.dev/tags/sql), [#functional-programming](https://daily.dev/tags/functional-programming) [View this post on daily.dev](https://daily.dev/posts/prela-tutorial-5qnafbvgu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Prela Tutorial","url":"https://daily.dev/posts/prela-tutorial-5qnafbvgu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/prela-tutorial-5qnafbvgu"},"datePublished":"2026-08-31T14:30:42.678Z","dateModified":"2026-08-31T14:37:27.385Z","description":"Prela is a new query language developed at UCLA that represents an alternative to SQL, built entirely from binary relations (tables with two columns). This...","image":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","thumbnailUrl":"https://media.daily.dev/image/upload/s--1KxV4ohY--/f_auto/v1722860400/public/Placeholder%2007","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/prela-tutorial-5qnafbvgu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"python,sql,functional-programming","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"Prela Tutorial"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/prela-tutorial-5qnafbvgu#faq","mainEntity":[{"@type":"Question","name":"What is the Prela query language and how does it differ from SQL?","acceptedAnswer":{"@type":"Answer","text":"Prela is a new query language from UCLA's RePL group built entirely on binary relations, tables with only two columns. Wide tables are decomposed into pairs of binary relations (similar to sixth normal form), and queries are built by composing these relations like functions using operators such as .select, &, .eq, and .where. This composability lets queries like a 20+ line SQL join collapse into roughly 11 lines. Developers curious about alternative query paradigms can follow deep dives on database design via daily.dev."}},{"@type":"Question","name":"How does the & operator work in Prela compared to SQL joins?","acceptedAnswer":{"@type":"Answer","text":"The & operator joins two binary relations on the first column of both and pairs up their second columns into a tuple, producing a relation that maps each row to both attributes at once. Because the result is still a binary relation, it can be composed further, and nesting & inside a .where clause doubles as logical conjunction for combining multiple filter conditions. Anyone comparing query language design choices can track niche database concepts like this on daily.dev."}}]} ```