I haven't used RethinkDB in ages, but when I did, I used it exclusively for a year.

It took a few weeks for ReQL to really sink in, but once it did, I much preferred it to SQL. As my sibling comment says, its very linear: do this then this then this then this. It also feels very much like sequence processing in functional languages (and I was using Clojure at the time, so it really meshed very well).

I also found it much easier (than SQL, at least in my limited experience) to reason about performance because I knew what it was doing. Is this looked up by index? Yes, because that's the command I used.

So, yeah, ReQL actually ended up being one of the things I liked most about RethinkDB.

Especially the "known performance" bit. One of the things I fight with constantly in SQL Server is never getting consistent performance from a more complicated SQL query. The query plan could change from one day to the next if the plan falls out of cache.

With ReQL you new exactly how indexes were being used, and how the data was being accessed. No trying to guess what the query optimizer was doing in the background.

Exactly. I didn't appreciate this as much as I perhaps should have while working with RethinkDB, but I've been working on optimising SQL queries lately and... man I wish I were working in ReQL. It really made me appreciate how easy (compared to SQL) ReQL is to mentally estimate performance.

The queries are fluent if you are used to libraries like lodash. I've been writing SQL for 20+ years. Not only did ReQL feel very natural to write, but it integrated beautifully with my node projects. The trouble I had was with indexing for performance, since I was more used to RDBMS index and query dualities.

I have much love for the Rethink team. I am glad to see they are doing their best to support the community during this difficult time.

In general, I don't like those X-to-Y translation pages, when the underlying concepts fundamentally change. You can't use your existing sql mindset to translate to their query language, but instead try to learn from scratch.

I don't know. I think they're useful if you consider them as a "I want to do X in languages A and B" showcase rather than a literal translation guide. It can certainly help getting a feel for "how much more difficult/easier is this in A vs B?".

We have a similar page at ArangoDB to help developers used to SQL to understand the general differences in AQL: https://www.arangodb.com/why-arangodb/sql-aql-comparison/

Very. The linear flow of data from left to right made it very easy to reason about complex queries.

I've wondered how it is not always chains of command from left to right like you mentioned, instead it encapsulates another expression starting from "r." here and there, which pretty much made me feel unintuitive at that time but regarding people's comment, I guess it will start to make sense well later on.