[1]: https://practicalalloy.github.io/chapters/structural-topics/...
Unrelated, we also have a tutorial on instance-optimal join algorithms: https://www.vldb.org/2026/program.html#tut-2
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.
Personally I'd love a more explicit form of SQL that allowed specifying things like "select via scan" or "select via index lookup". (I don't think this HN submission is that - I'm just saying generally.)
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
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.
That sentence should say "a binary relation can map an input to multiple different outputs", and that's not a bad thing. It's exactly how binary relations generalize functions, and we want that because that lets us compose binary relations like how we compose functions!
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....
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]';
And if you’re trying to benchmark one of these binary relationship query tools against DuckDB, keep in mind that DuckDB is heavily optimized for wide tables and is really not heavily optimized for point queries.
(Also, I, personally, would be a bit unhappy with a DBMS that cannot express, as part of the schema, that a movie has at most one or exactly one title.)
movie.with(
company.s(country).eq("[us]"
)
.and(
keyword.eq("character-name-in-title")
)
.select(
title
.and(
cast.s(person).s(alias).s(text)
)
)> 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.
1. do both systems access everything from memory?
2. do both systems have the same kind of indices?
3. do either system tradeoff scan performance for faster/acceptably fast updates?
2. No. Prela’s speedup is largely due to indexing. We tried to port the same indexing tricks back to duckdb but it wouldn’t let us. See the paper [1] for details
3. Prela focuses on analytical queries at least for now
Shameless plug: https://github.com/baverman/sqlbind-t
If anyone can point me to a huge SQL query, I’ll take it up as a challenge to rewrite in Prela!
Prela’s semantics is based on an algebra of binary relations (unfortunately called relation algebra [1]), not the standard relational algebra.
Though maybe a reader fluent in SQL can compare them mentally on the fly?
This is in rust and we’re still tweaking the language, so the syntax is slightly different from the post.
Yes, I could ask my local AI, I'm just curious if anyone here's wondering the same thing.
I am sure there are many projects like it, I suspect it is like static site generators and notekeeping apps, easy enough that everybody just makes their own. But this one is mine, and I have grown quite fond of it and use it in all my scripts. It is a little more magic than I am normally comfortable with. dynamic function generation is a bit of a black art, but having each query as it's own callable unit is super handy.
Think on this: You imagine yourself writing a regular website with ONLy sql? no, because SQL is not a "programming language" for developers.
Is possible you could think in various ideas about why is "nonsensical" to make an app with a relational language (that SQL clearly is not) but is the same as with OOP or functional: there is not reason to be a problem, and there is a lot of things that will be far easier if a proper relational language is used, like for example, is unnecessary and ORM and/or is not complicated and confusing to make one.
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.