Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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/...
by wbadart - They are exactly the same!by remywang
- 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.by scotty79
- 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.
by kscarlet - On second thought, some skepticism on performance comparison:
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?
by kscarlet - 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.
by Someone - Ah, that's not what I meant to say. You're talking about bag vs set semantics. Prela implements bag semantics just like 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!
by remywang - "Binary" applied to a relation just means it links pairs of elements, (left, right) for example. Functions are special cases of binary relations, in that each "left" element is linked to at most one "right" element. But the general case of a relation can have multiple right elements for a single left element. So TFA's correct.by thrance
- 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....
by andai - 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]';
by prathje - I would go one step farther: the SQL is awkward and long because the SQL language not at all optimized for data that is normalized all the way to binary relations.
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.)
by amluto - Looks a lot like 6NF (https://en.wikipedia.org/wiki/Sixth_normal_form)by mwcremer
- See first footnoteby frizlab
- 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.by Planktonne
- With some syntax sugar it looks almost exactly like SQL [1]. Here I’m showing the unsweetened edition for didactic purposes.by remywang
- 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.by petilon
- 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?
by kamma4434 - 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.
by grebc - I feel the opposite way. I very rarely trust the database system to do the right thing. Any query more complex than a basic lookup by primary key requires me to look at query plans and validate that indexes are in place and are being used. Otherwise we risk the production server grinding to a halt.
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.)
by wavemode - The remaining 1% is usually uncomfortable if not down right painful.
But yes, I agree a query optimizer is valuable. Luckily there’s nothing stopping us from implementing one, as Prela is algebraic and all optimization techniques for SQL carry over.
by 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
by remywang - 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
by slowcache - There is no good ORM -like it says here https://github.com/l3nz/ObjectiveSync “Bad practice - if you hide the database, you may get something done quickly, but it's a bad idea. If yor Java code expects to have a collection of one million objects as an array, it does not matter if they are lazily loaded or not - some code somewhere might want to iterate over them, and this will kill the process. You cannot really forget that there is a database somewhere, and you should not do it.”by kamma4434
- The point of Prela is exactly to remove that step of indirection, it gives you ORM ergonomics but compiles directly to operations on the physical columns, skipping SQL. At least for me I find it easier to think in Prela than to think in SQL, especially for complex queries, and I believe you’ll feel the same with some practice.by remywang