A better SQL in 11 lines of code

prathje

Interesting concept which reminds of the operations available in pandas. I disagree though with the statement of SQL needing 20 lines. The given query feels verbose and has lots of redundant conditions. Not saying that it is short but a better analogy could look like this: SELECT DISTINCT an.name, t.title FROM keyword k JOIN movie_keyword mk ON mk.keyword_id = k.id JOIN title t ON t.id = mk.movie_id JOIN movie_companies mc ON mc.movie_id = t.id JOIN company_name cn ON cn.id = mc.company_id JOIN cast_info ci ON ci.movie_id = t.id JOIN aka_name an ON an.person_id = ci.person_id WHERE k.keyword = 'character-name-in-title' AND cn.country_code = '[us]';

kscarlet

Cool language! I thought dplyr and datalog are both local optima (forget about the three-letter abomination) but I now declare this language the global optimum of query language. > In contrast, Prela can be implemented extremely close to the metal. The Rust implementation inlines operators and compiles them into tight fused loops over raw arrays, running several times faster than DuckDB even without a query optimizer. This will be true in Common Lisp as well. Now someone just have to implement it. Or maybe I should steal the syntax and compile to SQL first, just so people can use existing DBMS.

bradleyy

I'm afraid I'm in the "uses column store" and not "understands the actual storage mechanisms", but this feels like something that's essentially the same thing? Yes, I could ask my local AI, I'm just curious if anyone here's wondering the same thing.

trueno

am i the only one who's not afraid of sql taking up lines? sql thats formatted well is beautiful to read my brain enjoys it. it's way easier to read sql in terms of "what resultset is this trying to build" then it is to pick apart some fluent api lookin orm on top of sql

mwcremer

Looks a lot like 6NF ( https://en.wikipedia.org/wiki/Sixth_normal_form )

slowcache

I think an important benefit of a good ORM is to reduce the translations that you have to do between your mental model of the data and what you are trying to do with the data. Before I started working a lot with SQL, ORMs fit my mental model better since I was more used to imperative programming languages and I thought they were easier to work with. Now that I am very comfortable with SQL, I have to translate an ORM into the SQL that it would produce. So now they just add another step in between me and the data

tabith

this is utterly fascinating. thinking of LLM usage... it's so close to how LLMs think anyway, vector similarity also being a binary relation. LLM stops blindly guessing SQL and instead starts navigating data straight away.

andai

At the bottom is the actual code for the "language", which is only 79 lines. I found it helpful to read it first and then go back to the article. (On my initial reading I was like, "okay, but what is a Rel?") https://github.com/remysucre/prela/blob/main/tutorial/prela....

bvrmn

Examples don't show much more composability comparing to SQL. Even more Prela is heavily based on tuples and has same operation semantics as SQL. Shameless plug: https://github.com/baverman/sqlbind-t

kurtis_reed

People don't use SQL because it's a good language

andai

Very interesting. I'm not very fluent in SQL, so it would have been helpful to see some more side by side examples. (Since Prela seems a lot more ergonomic!) Though maybe a reader fluent in SQL can compare them mentally on the fly?

Planktonne

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.

Someone

FTA: “The motivation for focusing on binary relations is that they generalize functions. Functions are powerful because they compose, making them the building blocks of programs. A function maps every input to a unique output, where as a relation can map an input to multiple different outputs. In a sense, a relation can be viewed as a nondeterministic function” If “A function maps every input to a unique output, where as a relation can map an input to multiple different outputs”, wouldn’t a binary relation have the same problem? I know they mean to say a binary relation isn’t a relation in that sense, but that text could do with better terminology. Also, and more importantly, I don’t see how “binary” is essential here. What is essential is the uniqueness constraint. Compare Relational Algebra ( https://en.wikipedia.org/wiki/Relational_algebra ) with SQL.

remywang

Author here, I will be at VLDB in Boston this coming week and will be very happy to chat about Prela. Unrelated, we also have a tutorial on instance-optimal join algorithms: https://www.vldb.org/2026/program.html#tut-2

drob518

Seems to be sort of triple store / datalog-ish.

grebc

You’ve got do a better job selling the title sorry. I feel like the separation between a query & the query execution plan is one of the benefits of SQL. I trust the database system to do the right thing 99% of the time, and I don’t want to think about that either really.

scotty79

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.

wbadart

The core relation composition operator reminds me of Alloy's dot-join operator [1]. Wondering if anyone can comment on the differences, theoretical or practical? [1]: https://practicalalloy.github.io/chapters/structural-topics/...

Archelaos

How does it compare to Linq?

petilon

The example is not particularly impressive. The SQL equivalent is much easier to understand, which means it is easier to maintain. Number of lines is not an interesting metric; understandability and maintainability are more important.